Протокол Цетус нещодавно опублікував звіт про безпеку щодо інциденту з хакерським нападом. Цей звіт у плані технічних деталей і реагування на надзвичайні ситуації є досить прозорим, його можна назвати підручниковим. Проте, в поясненні "чому стали жертвою хакерів" у звіті позиція виглядає дещо ухильно.
Звіт акцентує увагу на перевірці помилок функції checked_shlw у бібліотеці integer-mate, кваліфікуючи їх як "семантичне непорозуміння". Хоча це твердження технічно правильне, воно, здається, зосереджує увагу на зовнішній відповідальності, ніби Cetus також є жертвою цього технічного дефекту.
Однак варто замислитися, чому, якщо integer-mate є широко використовуваною відкритою математичною бібліотекою, саме в Cetus виявився настільки серйозний недолік? Аналізуючи шлях атаки, можна виявити, що для ідеальної атаки хакер повинен одночасно виконати чотири умови: помилкова перевірка переповнення, значні зсуви, правила округлення вверх та відсутність перевірки економічної доцільності.
Дивно, але Cetus проігнорував кожну умову "спрацьовування". Наприклад, система прийняла астрономічні числа, використовуючи вкрай небезпечні великі обчислення зміщення, повністю довіряючи механізму перевірки зовнішньої бібліотеки. Найсмертоносніше те, що коли система обчислила абсурдний результат "1 токен на захмарну частку", вона без жодної економічної перевірки виконала його.
Отже, справжні питання, які повинні бути розглянуті Cetus, включають:
Чому було обрано універсальну зовнішню бібліотеку, але не проведено належне тестування на безпеку? Хоча бібліотека integer-mate має такі характеристики, як відкритий код, популярність та широке використання, але, здається, Cetus не повністю усвідомлював межі безпеки цієї бібліотеки при управлінні такими величезними активами, а також не розглянув альтернативи на випадок виходу бібліотеки з ладу. Це відображає недостатню свідомість Cetus щодо захисту безпеки в ланцюзі постачання.
Чому дозволяється вводити астрономічні числа без встановлення меж? Хоча DeFi-протоколи прагнуть до децентралізації, зрілі фінансові системи в умовах відкритості також потребують чітких меж. Дозволяючи вводити такі надмірні числа, це свідчить про те, що команді, можливо, бракує ризик-менеджерів з фінансовою інтуїцією.
Чому, незважаючи на багаторазові перевірки безпеки, проблеми все ще не були виявлені заздалегідь? Це виявляє фатальне помилкове уявлення: команда проекту повністю делегує відповідальність за безпеку компанії з безпеки, вважаючи аудит своєрідною медаллю безвідповідальності. Однак інженери з аудиту безпеки спеціалізуються на виявленні помилок у коді, але можуть не подумати протестувати, як система поводиться в екстремальних умовах.
Ця перевірка, що охоплює межі математики, криптографії та економіки, є найбільшою сліпою плямою сучасної безпеки DeFi. Аудиторські компанії можуть вважати це недоліком у дизайні економічної моделі, а не проблемою логіки коду, тоді як розробники проекту можуть скаржитися, що аудит не виявив проблеми, в результаті чого збитки несе користувач.
Ця подія виявила системні недоліки безпеки в індустрії DeFi: команди з чисто технічним фоном часто не мають базового "фінансового чуття". З огляду на звіт Cetus, команда, схоже, не усвідомлює цього повністю.
Для Cetus та всього сектору DeFi важливо вийти за межі обмежень чисто технічного мислення та виховувати справжню свідомість безпеки ризиків "фінансових інженерів". Можна розглянути можливість залучення експертів з фінансового ризику, щоб заповнити знання технічної команди; створити механізм багатостороннього аудиту, який не тільки зосереджується на аудиті коду, але й надає значення аудиту економічних моделей; виховувати "фінансовий нюх", моделюючи різні сценарії атак та розробляючи відповідні заходи реагування, зберігаючи високу обізнаність щодо аномальних операцій.
З розвитком галузі технічні помилки на рівні коду можуть поступово зменшуватися, але "свідомі помилки" в бізнес-логіці з нечіткими межами та розмитими обов'язками стануть найбільшим викликом. Аудиторські компанії можуть забезпечити відсутність помилок у коді, але для того, щоб досягти "логічних меж", команді проекту потрібно мати глибше розуміння суті бізнесу та здатність контролювати межі.
Майбутнє DeFi належить тим командам, які не лише відрізняються високою технічною майстерністю в програмуванні, але й глибоко розуміють бізнес-логіку. Лише команди, які мають обидва ці аспекти, зможуть справді закріпитися та досягти успіху в цій складній галузі.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
20 лайків
Нагородити
20
6
Поділіться
Прокоментувати
0/400
GasWhisperer
· 07-17 18:44
пул пам'яті patterns never lie... integer-mate був лише Gate, а не основна вразливість, якщо чесно
Переглянути оригіналвідповісти на0
DataOnlooker
· 07-17 15:56
Майстер скидання провини, а цей Cetus
Переглянути оригіналвідповісти на0
ImpermanentLossEnjoyer
· 07-15 05:30
Втрата може бути проаналізована ще раз 香嗷
Переглянути оригіналвідповісти на0
DegenApeSurfer
· 07-15 05:30
Хто живий, той і несе відповідальність.
Переглянути оригіналвідповісти на0
SatoshiLegend
· 07-15 05:30
Чому проекти DeFi часто стикаються з такими помилками переповнення цілих чисел? Перш ніж шукати причини, потрібно спочатку зрозуміти алгоритм pow.
Переглянути оригіналвідповісти на0
GasOptimizer
· 07-15 05:28
Звинувачення в інших, дійсно, це помилка, що не перевірили.
Роздуми про хакерську атаку на Cetus: безпека DeFi повинна виходити за межі чисто технічного мислення
Протокол Цетус нещодавно опублікував звіт про безпеку щодо інциденту з хакерським нападом. Цей звіт у плані технічних деталей і реагування на надзвичайні ситуації є досить прозорим, його можна назвати підручниковим. Проте, в поясненні "чому стали жертвою хакерів" у звіті позиція виглядає дещо ухильно.
Звіт акцентує увагу на перевірці помилок функції checked_shlw у бібліотеці integer-mate, кваліфікуючи їх як "семантичне непорозуміння". Хоча це твердження технічно правильне, воно, здається, зосереджує увагу на зовнішній відповідальності, ніби Cetus також є жертвою цього технічного дефекту.
Однак варто замислитися, чому, якщо integer-mate є широко використовуваною відкритою математичною бібліотекою, саме в Cetus виявився настільки серйозний недолік? Аналізуючи шлях атаки, можна виявити, що для ідеальної атаки хакер повинен одночасно виконати чотири умови: помилкова перевірка переповнення, значні зсуви, правила округлення вверх та відсутність перевірки економічної доцільності.
Дивно, але Cetus проігнорував кожну умову "спрацьовування". Наприклад, система прийняла астрономічні числа, використовуючи вкрай небезпечні великі обчислення зміщення, повністю довіряючи механізму перевірки зовнішньої бібліотеки. Найсмертоносніше те, що коли система обчислила абсурдний результат "1 токен на захмарну частку", вона без жодної економічної перевірки виконала його.
Отже, справжні питання, які повинні бути розглянуті Cetus, включають:
Чому було обрано універсальну зовнішню бібліотеку, але не проведено належне тестування на безпеку? Хоча бібліотека integer-mate має такі характеристики, як відкритий код, популярність та широке використання, але, здається, Cetus не повністю усвідомлював межі безпеки цієї бібліотеки при управлінні такими величезними активами, а також не розглянув альтернативи на випадок виходу бібліотеки з ладу. Це відображає недостатню свідомість Cetus щодо захисту безпеки в ланцюзі постачання.
Чому дозволяється вводити астрономічні числа без встановлення меж? Хоча DeFi-протоколи прагнуть до децентралізації, зрілі фінансові системи в умовах відкритості також потребують чітких меж. Дозволяючи вводити такі надмірні числа, це свідчить про те, що команді, можливо, бракує ризик-менеджерів з фінансовою інтуїцією.
Чому, незважаючи на багаторазові перевірки безпеки, проблеми все ще не були виявлені заздалегідь? Це виявляє фатальне помилкове уявлення: команда проекту повністю делегує відповідальність за безпеку компанії з безпеки, вважаючи аудит своєрідною медаллю безвідповідальності. Однак інженери з аудиту безпеки спеціалізуються на виявленні помилок у коді, але можуть не подумати протестувати, як система поводиться в екстремальних умовах.
Ця перевірка, що охоплює межі математики, криптографії та економіки, є найбільшою сліпою плямою сучасної безпеки DeFi. Аудиторські компанії можуть вважати це недоліком у дизайні економічної моделі, а не проблемою логіки коду, тоді як розробники проекту можуть скаржитися, що аудит не виявив проблеми, в результаті чого збитки несе користувач.
Ця подія виявила системні недоліки безпеки в індустрії DeFi: команди з чисто технічним фоном часто не мають базового "фінансового чуття". З огляду на звіт Cetus, команда, схоже, не усвідомлює цього повністю.
Для Cetus та всього сектору DeFi важливо вийти за межі обмежень чисто технічного мислення та виховувати справжню свідомість безпеки ризиків "фінансових інженерів". Можна розглянути можливість залучення експертів з фінансового ризику, щоб заповнити знання технічної команди; створити механізм багатостороннього аудиту, який не тільки зосереджується на аудиті коду, але й надає значення аудиту економічних моделей; виховувати "фінансовий нюх", моделюючи різні сценарії атак та розробляючи відповідні заходи реагування, зберігаючи високу обізнаність щодо аномальних операцій.
З розвитком галузі технічні помилки на рівні коду можуть поступово зменшуватися, але "свідомі помилки" в бізнес-логіці з нечіткими межами та розмитими обов'язками стануть найбільшим викликом. Аудиторські компанії можуть забезпечити відсутність помилок у коді, але для того, щоб досягти "логічних меж", команді проекту потрібно мати глибше розуміння суті бізнесу та здатність контролювати межі.
Майбутнє DeFi належить тим командам, які не лише відрізняються високою технічною майстерністю в програмуванні, але й глибоко розуміють бізнес-логіку. Лише команди, які мають обидва ці аспекти, зможуть справді закріпитися та досягти успіху в цій складній галузі.