Анализ инцидента с хакером Cetus: уязвимость безопасности выявила системные недостатки проектов Децентрализованные финансы

Протокол Cetus недавно опубликовал отчет о безопасности после хакерской атаки, что вызвало широкое внимание в отрасли. Этот отчет подробно раскрывает технические детали и процесс экстренного реагирования, что можно назвать учебным примером. Однако, объясняя причины атаки, отчет выглядит уклончиво.

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

Однако, после тщательного анализа выясняется, что успешная атака Хакер требует одновременного выполнения нескольких условий: неправильная проверка переполнения, значительные сдвиги, правила округления вверх и отсутствие проверки экономической целесообразности. Удивительно, но в каждом из этапов Cetus есть очевидные недочеты.

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

Это событие выявило недостатки команды Cetus в нескольких аспектах:

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

2. Нехватка специалистов по финансовому управлению рисками: разрешение ввода неразумных астрономических цифр показывает, что команде не хватает интуиции в управлении рисками.

3. Чрезмерная зависимость от аудита безопасности: передача ответственности за безопасность аудиторским компаниям игнорирует собственные основные обязанности в области безопасности.

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

Чтобы справиться с этими вызовами, командам проектов DeFi следует:

• Вовлечь экспертов в области финансового риска, чтобы восполнить пробелы в знаниях технической команды.
• Создание многостороннего механизма аудита и проверки, который не только следует за аудитом кода, но и придает значение аудиту экономической модели.
• Развивайте "финансовое чутье", моделируйте различные сценарии атак и разрабатывайте соответствующие меры, оставайтесь в высокой степени бдительности к аномальным действиям.

С развитием отрасли чистые технические уязвимости на уровне кода будут постепенно уменьшаться, в то время как нечеткие границы и неопределенные обязанности в бизнес-логике "осознания уязвимостей" станут наибольшей проблемой. Аудиторские компании могут гарантировать отсутствие ошибок в коде, но то, как добиться "логических границ", требует от проектной команды более глубокого понимания и контроля над сущностью бизнеса.

В будущем успех в индустрии DeFi будет принадлежать тем командам, которые одновременно владеют кодовыми технологиями и глубоко понимают бизнес-логику.