Cetus безпекові проблеми: на що команді DeFi слід звернути увагу?

Команди з чисто технічним фоном серйозно страждають від відсутності базового «фінансового чуття».

Автор: Haotian

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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