Вкрадено понад 200 мільйонів доларів, які висновки можна зробити з безпекової події Cetus?

Прочитавши звіт про безпеку «аналітику» атаки хакерів @CetusProtocol, ви помітите «цікавий» феномен: технічні деталі розкриті досить прозоро, а реагування на надзвичайні ситуації можна вважати підручниковим, але у найважливішому питанні «чому вони були зламані» це душевне запитання виглядає так, ніби намагається уникнути суті:

Звіт великою мірою пояснює функцію checked\_shlw бібліотеки integer-mate, яка перевіряє помилки (повинно бути ≤2^192, фактично ≤2^256), і кваліфікує це як «семантичне непорозуміння». Хоча цей опис технічно правильний, він хитро зосереджує увагу на зовнішній відповідальності, наче Cetus також є невинною жертвою цього технічного дефекту.

Питання виникає: якщо integer-mate є відкритою та широко використовуваною математичною бібліотекою, чому ж у вас сталася абсурдна помилка, коли за 1 токен можна отримати захмарну частку ліквідності?

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

Cetus абсолютно «помилувався» у кожній умові «тригера», наприклад: приймаючи введення користувача 2^200 такого астрономічного числа, використовуючи екстремально небезпечні великі зсуви, повністю довіряючи механізмам перевірки зовнішньої бібліотеки, найфатальніше те, що — коли система вирахувала «1 токен за захмарну частку» такий абсурдний результат, вона не провела жодної перевірки економічної доцільності і просто виконала його.

Отже, справжніми моментами, над якими Cetus має задуматися, є такі:

1. Чому я не проводжу тестування безпеки, коли використовую звичайні зовнішні бібліотеки? Незважаючи на те, що бібліотека є бібліотекою з відкритим вихідним кодом, популярною та широко використовуваною, Cetus використовує її для управління активами на сотні мільйонів доларів без повного розуміння того, де проходять межі безпеки бібліотеки, чи є відповідні альтернативи, якщо бібліотека вийде з ладу тощо. Очевидно, що Cetus не вистачає базової обізнаності про безпеку ланцюга поставок;

2. Чому дозволяється вводити астрономічні цифри без встановлення меж? Хоча DeFi протоколи повинні прагнути до децентралізації, зрілий фінансовий система, чим більше вона відкрита, тим більше потребує чітких меж.

Коли система дозволяє вводити астрономічні числа, ретельно створені зловмисником, команда явно не подумала, чи є така потреба в ліквідності розумною? Навіть найбільші хедж-фонди у світі не можуть потребувати таких надмірних часток ліквідності. Очевидно, що команді Cetus бракує фахівців з управління ризиками, які мають фінансову інтуїцію;

3. Чому після кількох раундів аудиту безпеки досі не виявлено проблему заздалегідь? Це речення ненавмисно викриває фатальне когнітивне непорозуміння: команда проекту передає відповідальність за безпеку охоронній компанії на аутсорсинг, а аудит розглядає як золоту медаль за звільнення. Але реальність сувора: інженери з аудиту безпеки добре знаходять помилки в коді, і хто б міг подумати, що може бути неправильно тестувати систему, щоб розрахувати фантастичний коефіцієнт обміну?

Такий перетин меж математичної, криптографічної та економічної верифікації є найбільшим сліпим місцем сучасної безпеки DeFi. Аудиторські компанії кажуть: «Це дефект проектування економічної моделі, а не проблема логіки коду»; команда проекту скаржиться: «Аудит не виявив проблем»; а користувачі лише знають, що їхні гроші зникли!

Ти бачиш, це врешті-решт виявляє системні проблеми безпеки в індустрії DeFi: команди з чисто технічним фоном серйозно страждають від нестачі базового "фінансового ризикового чуття".

А з цього звіту Cetus видно, що команда явно не провела належного самоаналізу.

Порівняно з чистими технічними недоліками, пов'язаними з цією хакерською атакою, я вважаю, що з Cetus всі команди DeFi повинні відмовитися від обмеженості чисто технічного мислення і справді виховувати у «фінансових інженерів» усвідомлення ризиків безпеки.

Наприклад: залучити експертів з фінансового ризик-менеджменту, щоб заповнити знання команди технологій; впровадити механізм багатостороннього аудиту, який включає не тільки аудит коду, але й необхідний аудит економічних моделей; виховувати «фінансовий нюх», моделювати різні сценарії атак та відповідні заходи реагування, бути чутливими до аномальних операцій тощо.

Це нагадує мені про попередній досвід роботи в компаніях з безпеки, зокрема про спілкування з великими фахівцями галузі @evilcos, @chiachih_wu, @yajinzhou, @mikelee205, у яких також є така спільна думка:

Зі зростанням зрілості галузі, технічні проблеми з кодом зменшаться, а «свідомі баги» в бізнес-логіці з неясними межами та розмитими обов'язками стануть найбільшим викликом.

Аудиторські компанії можуть забезпечити лише відсутність помилок у коді, але для того, щоб забезпечити «логічні межі», команді проєкту необхідно глибше розуміти суть бізнесу та мати здатність контролювати межі. (Основна причина багатьох «звалювань провини» після безпекових аудитів, які все ще піддаються атакам хакерів, полягає саме в цьому.)

Майбутнє DeFi належить тим командам, які мають міцні навички програмування та глибоке розуміння бізнес-логіки!