Огляд хакерської атаки на Cetus: вразливості безпеки виявили системні недоліки проєктів Децентралізовані фінанси

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

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

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

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

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

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

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

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

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

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

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

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

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