Звіт про викрадення від Cetus: розкрито хронологію та деталі атаки

Джерело: Cetus; переклад: AIMan@Золотий фінанс

22 травня 2025 року Cetus зазнав складної атаки на смарт-контракти CLMM пулу. Ми негайно вжили заходів для пом'якшення наслідків, цей звіт має на меті прозоро розкрити хронологію подій, аналіз причин, стан коштів та подальші плани, а також спільно сприяти подальшим справам.

Хронологія подій

UTC час 10:30:50 – Атака була запущена через аномальні транзакції.

UTC час 10:40:00 – система моніторингу виявила аномальну поведінку фонду.

UTC час 10:53:00 – команда Cetus виявила джерело атаки та надіслала попередження членам екосистеми Sui.

UTC час 10:57:47 – основний CLMM пул було деактивовано, щоб запобігти подальшим збиткам.

11:20:00 UTC – Усі пов'язані смарт-контракти глобально вимкнені.

UTC час 12:50:00 – Верифікатори Sui починають голосування за відмову в обробці транзакцій, підписаних адресами атакуючого, і коли ставлення stake перевищує поріг у 33%, верифікатори ефективно "заморожують" ці адреси.

UTC час 18:04:07 – Надсилаємо повідомлення про переговори в мережі зловмиснику.

UTC час 18:15:28 – Вразливий контракт було виправлено та оновлено (ще не перезавантажено).

Аналіз атаки

Зловмисники скористалися вразливістю в відкритій бібліотеці inter\_mate контракту CLMM, процес атаки наступний:

a. Атакуючий ініціює миттєвий обмін (flash_swap), тимчасово знижуючи ціну в ліквідностному пулі.

b. Відкриття позиції в більш високому ціновому діапазоні.

c. Використання логіки додавання ліквідності (add\_liquidity) для помилкового переповнення перевірки, щоб інжектувати надвисоку ліквідність за допомогою дуже малої кількості токенів.

d. Виведення ліквідності (remove_liquidity) через кілька раундів для виснаження резервів токенів.

e. Використовуючи неконтрольовані обчислення (такі як overflowing\_sub, get\_liquidity\_from\_a), повторіть вищезазначений процес за допомогою ретельно сконструйованих значень ліквідності.

! QMMrVAgV6mADob3pTQWzYV2CYasT2LS81Xa5Skj4.png

Цю уразливість не виявили під час попереднього аудиту безпеки.

Основна причина

Ураза виникла через неправильне розуміння семантики операції зсуву вліво в відкритій бібліотеці integer-mate, на яку покладається контракт CLMM. У його методі checked\_shlw фактична перевірка повинна бути "значення вводу ≤ 2^192", але в атакованій версії помилково перевіряється як "≤ 2^256", що призводить до несправності перевірки переповнення. Це є єдиною реальною причиною нещодавніх атак.

Зловмисники використовують вищезгадану вразливість, маніпулюючи ціною в пулі ліквідності (tick) та механізмом ліквідності, успішно викрадаючи значні активи під час багаторазових атак.

Щоб уточнити, деякі люди в соціальних мережах нещодавно помилково вважали, що атака виникла через помилку «арифметичної перевірки MAX_U64», позначену в попередньому звіті про аудит, яка ввела в оману багатьох користувачів, які не знали правди. Хочемо заявити, що це питання не пов'язане з цією атакою. Ця проблема сама по собі є лише інформаційною пропозицією щодо оптимізації, яка призводить до відкату транзакції лише в крайніх випадках, а виправлення оптимізації було завершено в попередніх випусках.

Адреса атакуючого (на ланцюгу Sui):

0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06

Стан фінансів

Для захисту спільних інтересів всієї екосистеми, за підтримки більшості валідаторів Sui, два гаманці Sui адреси нападника були терміново заморожені. Заморожені гаманці містять основну частину вкрадених коштів:

Атакуючий гаманець Sui 1 (заморожений): 0xcd8962dad278d8b50fa0f9eb0186bfa4cbdecc6d59377214c88d0286a0ac9562

Атакуючий гаманець Sui 2 (заморожений): 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06

Залишкові вкрадені кошти були повністю обміняні зловмисниками та перенесені на ETH, наразі вони знаходяться у наступних двох гаманцях Ethereum:

Атакуючий Ethereum гаманця 1: 0x0251536bfcf144b88e1afa8fe60184ffdb4caf16

Атакуючий Ethereum гаманець 2: 0x89012a55cd6b88e407c9d4ae9b3425f55924919b

Подальші плани

Перегляд контрактів та зміцнення безпеки

Ми співпрацюємо з командою безпеки Sui та кількома партнерами з аудиту для повторної перевірки оновленого контракту та проведення спільного аудиту. Тільки після повної перевірки буде поступово відновлено активацію CLMM пулу та супутніх послуг.

Ми плануємо негайно розпочати додатковий аудит і публікувати регулярні звіти про аудит на основі TVL (загальна заблокована вартість). Водночас буде продовжено посилення моніторингу в мережі, оптимізацію управління ризиками та впровадження контрольованих обмежень швидкості для ліквідності активів.

Відновлення LP-активів

Ми активно співпрацюємо з ключовими партнерами екосистеми для розробки планів відновлення для постраждалих ліквідних пулів та LP, прагнучи якомога швидше відновити функціональність вилучення ліквідності та всі послуги постраждалих пулів.

Щоб досягти остаточної мети повернення всіх втрат користувачів, ми щиро закликаємо всіх валідаторів Sui підтримати нещодавно ініційоване нами голосування в мережі. Це голосування дозволить користувачам швидко повернути більшу частину активів. Завдяки вашій підтримці, ми якнайшвидше просунемось у відшкодуванні втрат користувачів та відновленні довіри в спільноті.

Право та переговорна робота

Під час просування юридичних та правоохоронних процедур ми також надаємо зловмисникам можливість стати білими шоломами. Незабаром буде надіслано фінальне повідомлення зловмисникам, всі досягнення будуть прозоро розкриті спільноті.

Висновок

Ми щиро дякуємо користувачам, фонду Sui та екологічним партнерам за швидку реакцію та потужну підтримку, що дозволило нам швидко заморозити понад 160 мільйонів доларів США та передати ключову інформацію постраждалим сторонам. Водночас ми усвідомлюємо, що повне відновлення все ще потребує часу, і активно вживаємо заходів для прискорення цього процесу.

З моменту свого заснування Cetus була однією з команд DeFi, яка найбільше інвестувала в аудит смарт-контрактів і захист системи в Sui Chain. Однак реальність не така хороша, як мала б бути: базові контракти та бібліотеки з відкритим вихідним кодом, на які вони покладаються, пройшли кілька раундів аудитів і широко використовуються розробниками екосистем, що змушує нас помилково вважати, що вони достатньо безпечні. Озираючись назад, можна сказати, що нам не вистачило пильності. Цей важкий урок навчив нас, що потрібно зробити більше.

В майбутньому ми посилимо систему безпеки та контроль за ризиками за допомогою наступних заходів:

  1. Використовуючи інструменти, такі як Blockaid, для реалізації моніторингу в реальному часі, своєчасно виявляти та реагувати на загрози і вразливості

  2. Оптимізувати розподіл ризиків в управлінні та впровадити контрольоване обмеження швидкості потоку активів

  3. Підвищення покриття тестами вихідного коду смарт-контрактів

  4. Публічний показник покриття коду

  5. Провести аудит перед офіційним випуском, після значних змін коду та досягнення ключового рубежу TVL.

  6. Оновлення програми винагороди за вразливості білих капелюхів, великі винагороди за цінні звіти про вразливості

Вищезазначені кілька заходів вже впроваджуються, і ми будемо продовжувати їх поглиблення.

Крім того, ми усвідомлюємо, що захист DeFi-протоколу не може покладатися лише на зусилля команди та аудиторів; потрібна сила всієї екосистеми — від розробників до активних білих капелюхів — для спільного моніторингу, захисту та вдосконалення. Ми прагнемо об'єднати всі доступні сили для побудови сталевої та стійкої інфраструктури для всього екосистеми, яка витримає випробування часом.

Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
  • Нагородити
  • Прокоментувати
  • Поділіться
Прокоментувати
0/400
Немає коментарів
  • Закріпити