Аналіз події зламу протоколу Cetus: подвійний виклик технологій та фінансового ризик-менеджменту

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

Звіт зосереджується на обговоренні помилок перевірки функції checked_shlw в бібліотеці integer-mate, відносячи їх до "семантичного непорозуміння". Хоча така формулювання технічно коректна, вона, здається, навмисно або ненавмисно перекладає відповідальність на зовнішні фактори.

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

Ще більш варто задуматися, чому широко використовувана відкрита математична бібліотека викликала такі серйозні вразливості в застосуванні Cetus? Чому система дозволяє вводити такі абсурдні астрономічні числа? Чому після багаторазових перевірок безпеки ці проблеми досі не були виявлені?

Ці питання відображають недоліки команди Cetus у кількох аспектах:

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

2. Брак професійних кадрів у управлінні фінансовими ризиками: дозволяючи вводити нерозумні астрономічні числа, команда демонструє нестачу базових знань про фінансову систему.

3. Надмірна залежність від зовнішніх аудиторів безпеки: повна делегування відповідальності за безпеку аудиторським компаніям і ігнорування власних постійних обов'язків з управління безпекою.

Ця подія виявила системні недоліки безпеки, які існують у сфері DeFi: багато команд надто зосереджені на технологічному аспекті, ігноруючи важливість управління фінансовими ризиками.

Щоб впоратися з цими викликами, проекти DeFi повинні:

1. Запросити експертів з фінансового ризику, щоб заповнити знання технічної команди.
2. Встановлення багатостороннього механізму аудиту, який не лише зосереджується на аудиті коду, але й надає значення аудиту економічної моделі.
3. Виховувати "фінансовий нюх", моделювати різні сценарії атак і розробляти відповідні стратегії реагування.

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

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