Роздуми та уроки з інциденту атаки Хакера на протокол Cetus

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

Звіт велику частину пояснює помилку перевірки функції checked_shlw у бібліотеці integer-mate (повинно бути ≤2^192, насправді ≤2^256) і кваліфікує її як "семантичне непорозуміння". Це формулювання, хоча й технічно бездоганне, хитро переводить фокус на зовнішню відповідальність, ніби протокол сам є безневинною жертвою цього технічного дефекту.

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

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

Тому справжніми питаннями для роздумів щодо цього протоколу є:

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

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

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

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

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

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

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

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

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

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