Прочитавши звіт про безпеку "ревізії" хакерської атаки від @CetusProtocol, ви помітите "цікавий" феномен: технічні деталі розкриті досить прозоро, а реагування на надзвичайні ситуації можна вважати підручниковим, але на найважливішому запитанні "чому це сталося" відповідь виглядає ухильно:
У звіті багато місця приділено поясненню помилки перевірки функції 'checked_shlw' у бібліотеці 'integer-mate' (яка повинна ≤ 2^192, але насправді ≤2^256) і характеризує це як "семантичне непорозуміння". Цей наратив, хоч і технічно обґрунтований, спритно спрямовує фокус на зовнішню відповідальність, ніби Кит також був невинною жертвою цього технологічного недоліку.
Постає питання: якщо integer-mate є відкритою та широко використовуваною математичною бібліотекою, чому ж у вас сталася абсурдна помилка, що дозволяє отримати величезну частку ліквідності всього за 1 токен?
Аналізуючи шляхи хакерських атак, можна виявити, що для досягнення ідеальної атаки хакер повинен одночасно виконати чотири умови: неправильна перевірка переповнення, значне зсування, правила округлення вгору, відсутність перевірки економічної доцільності.
Cetus «недбалий» у кожній умові «спрацьовування», таких як: прийняття астрономічного числа, такого як введення користувачем 2^200, використання надзвичайно небезпечних обчислень великого переміщення, повна довіра механізму перевірки зовнішніх бібліотек, і найфатальніше - коли система обчислює абсурдний результат «1 токен за захмарну цінову частку», це безпосередньо виконується без будь-якої економічної перевірки здорового глузду.
Отже, ось основні моменти, над якими Cetus дійсно має задуматися:
Чому я не проводжу тестування безпеки, коли використовую звичайні зовнішні бібліотеки? Незважаючи на те, що бібліотека є бібліотекою з відкритим вихідним кодом, популярною та широко використовуваною, Cetus використовує її для управління активами на сотні мільйонів доларів без повного розуміння того, де проходять межі безпеки бібліотеки, чи є відповідні альтернативи, якщо бібліотека вийде з ладу тощо. Очевидно, що Cetus не вистачає базової обізнаності про безпеку ланцюга поставок;
Чому дозволяється вводити астрономічні цифри без встановлення меж? Хоча протоколи DeFi мають прагнути до децентралізації, зрілий фінансовий система, чим більше вона відкрита, тим більше потребує чітких меж.
Коли система дозволяє вводити астрономічні числа, ретельно сконструйовані зловмисником, команда очевидно не подумала, чи є така потреба в ліквідності обґрунтованою? Навіть найбільші хедж-фонди світу не можуть потребувати таких екстравагантних часток ліквідності. Очевидно, що команда Cetus не має кваліфікованих фахівців з управління ризиками, які володіють фінансовою інтуїцією;
Чому після кількох раундів аудиту безпеки досі не виявлено проблему заздалегідь? Це речення ненавмисно викриває фатальне когнітивне непорозуміння: команда проекту передає відповідальність за безпеку охоронній компанії на аутсорсинг, а аудит розглядає як золоту медаль за звільнення. Але реальність сувора: інженери з аудиту безпеки добре знаходять помилки в коді, і хто б міг подумати, що може бути неправильно тестувати систему, щоб розрахувати фантастичний коефіцієнт обміну?
Ця перевірка на межі між математикою, криптографією та економікою є найбільшою сліпою зоною безпеки сучасного DeFi. Аудиторські компанії кажуть: «Це недолік дизайну економічної моделі, а не проблема логіки коду»; команди проекту скаржаться: «Аудит не виявив проблем»; а користувачі просто знають, що їхні гроші зникли!
Ви бачите, це в кінцевому підсумку виявляє системні недоліки безпеки в індустрії DeFi: команди з чисто технічним бекграундом серйозно не вистачає основного «фінансового чуття ризику».
А з цього звіту Cetus видно, що команда явно не провела належного самоаналізу.
На мій погляд, починаючи з Cetus, всі команди DeFi повинні відмовитися від обмеженого технічного мислення, яке стосується лише технічних недоліків, пов'язаних із цим хакерським нападом, і справді виховувати свідомість про безпеку ризиків «фінансових інженерів».
Наприклад: залучення експертів з фінансового ризику, щоб заповнити прогалини в знаннях технічної команди; впровадження багатосторонньої системи аудиту, яка включає не лише аудит коду, але й необхідний аудит економічних моделей; розвиток «фінансового чуття», моделювання різних сценаріїв атак та відповідних заходів реагування, постійна чутливість до аномальних операцій тощо.
Це нагадує мені мій попередній досвід роботи в охоронних компаніях, включаючи гігантів індустрії безпеки @evilcos, @chiachih_wu, @yajinzhou та @mikelee205.
Зі зростанням зрілості галузі проблеми технологічних багів на рівні коду будуть зменшуватися, тоді як «усвідомлені баги» бізнес-логіки з нечіткими межами та невизначеними обов'язками стануть найбільшим викликом.
Аудиторські компанії можуть лише забезпечити, що в коді немає помилок, але для того, щоб досягти «логічних меж», команді проекту необхідно мати глибше розуміння суті бізнесу та здатність контролювати ці межі. (Основна причина багатьох випадків, коли після безпеки аудиту все ще відбувались хакерські атаки, полягає в цьому.)
Майбутнє DeFi належить командам, які мають міцні технічні навички програмування та глибоке розуміння бізнес-логіки!
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Безпека Cetus: на що команді DeFi слід звернути увагу?
Автор: Haotian
Прочитавши звіт про безпеку "ревізії" хакерської атаки від @CetusProtocol, ви помітите "цікавий" феномен: технічні деталі розкриті досить прозоро, а реагування на надзвичайні ситуації можна вважати підручниковим, але на найважливішому запитанні "чому це сталося" відповідь виглядає ухильно:
У звіті багато місця приділено поясненню помилки перевірки функції 'checked_shlw' у бібліотеці 'integer-mate' (яка повинна ≤ 2^192, але насправді ≤2^256) і характеризує це як "семантичне непорозуміння". Цей наратив, хоч і технічно обґрунтований, спритно спрямовує фокус на зовнішню відповідальність, ніби Кит також був невинною жертвою цього технологічного недоліку.
Постає питання: якщо
integer-mateє відкритою та широко використовуваною математичною бібліотекою, чому ж у вас сталася абсурдна помилка, що дозволяє отримати величезну частку ліквідності всього за 1 токен?Аналізуючи шляхи хакерських атак, можна виявити, що для досягнення ідеальної атаки хакер повинен одночасно виконати чотири умови: неправильна перевірка переповнення, значне зсування, правила округлення вгору, відсутність перевірки економічної доцільності.
Cetus «недбалий» у кожній умові «спрацьовування», таких як: прийняття астрономічного числа, такого як введення користувачем 2^200, використання надзвичайно небезпечних обчислень великого переміщення, повна довіра механізму перевірки зовнішніх бібліотек, і найфатальніше - коли система обчислює абсурдний результат «1 токен за захмарну цінову частку», це безпосередньо виконується без будь-якої економічної перевірки здорового глузду.
Отже, ось основні моменти, над якими Cetus дійсно має задуматися:
Чому я не проводжу тестування безпеки, коли використовую звичайні зовнішні бібліотеки? Незважаючи на те, що бібліотека є бібліотекою з відкритим вихідним кодом, популярною та широко використовуваною, Cetus використовує її для управління активами на сотні мільйонів доларів без повного розуміння того, де проходять межі безпеки бібліотеки, чи є відповідні альтернативи, якщо бібліотека вийде з ладу тощо. Очевидно, що Cetus не вистачає базової обізнаності про безпеку ланцюга поставок;
Чому дозволяється вводити астрономічні цифри без встановлення меж? Хоча протоколи DeFi мають прагнути до децентралізації, зрілий фінансовий система, чим більше вона відкрита, тим більше потребує чітких меж.
Коли система дозволяє вводити астрономічні числа, ретельно сконструйовані зловмисником, команда очевидно не подумала, чи є така потреба в ліквідності обґрунтованою? Навіть найбільші хедж-фонди світу не можуть потребувати таких екстравагантних часток ліквідності. Очевидно, що команда Cetus не має кваліфікованих фахівців з управління ризиками, які володіють фінансовою інтуїцією;
Ця перевірка на межі між математикою, криптографією та економікою є найбільшою сліпою зоною безпеки сучасного DeFi. Аудиторські компанії кажуть: «Це недолік дизайну економічної моделі, а не проблема логіки коду»; команди проекту скаржаться: «Аудит не виявив проблем»; а користувачі просто знають, що їхні гроші зникли!
Ви бачите, це в кінцевому підсумку виявляє системні недоліки безпеки в індустрії DeFi: команди з чисто технічним бекграундом серйозно не вистачає основного «фінансового чуття ризику».
А з цього звіту Cetus видно, що команда явно не провела належного самоаналізу.
На мій погляд, починаючи з Cetus, всі команди DeFi повинні відмовитися від обмеженого технічного мислення, яке стосується лише технічних недоліків, пов'язаних із цим хакерським нападом, і справді виховувати свідомість про безпеку ризиків «фінансових інженерів».
Наприклад: залучення експертів з фінансового ризику, щоб заповнити прогалини в знаннях технічної команди; впровадження багатосторонньої системи аудиту, яка включає не лише аудит коду, але й необхідний аудит економічних моделей; розвиток «фінансового чуття», моделювання різних сценаріїв атак та відповідних заходів реагування, постійна чутливість до аномальних операцій тощо.
Це нагадує мені мій попередній досвід роботи в охоронних компаніях, включаючи гігантів індустрії безпеки @evilcos, @chiachih_wu, @yajinzhou та @mikelee205.
Зі зростанням зрілості галузі проблеми технологічних багів на рівні коду будуть зменшуватися, тоді як «усвідомлені баги» бізнес-логіки з нечіткими межами та невизначеними обов'язками стануть найбільшим викликом.
Аудиторські компанії можуть лише забезпечити, що в коді немає помилок, але для того, щоб досягти «логічних меж», команді проекту необхідно мати глибше розуміння суті бізнесу та здатність контролювати ці межі. (Основна причина багатьох випадків, коли після безпеки аудиту все ще відбувались хакерські атаки, полягає в цьому.)
Майбутнє DeFi належить командам, які мають міцні технічні навички програмування та глибоке розуміння бізнес-логіки!