Более 200 миллионов долларов были украдены, какие уроки принесло событие безопасности Cetus?

Прочитав отчет о безопасности «анализ» атаки на @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, команда явно не провела должного анализа.

В отличие от чисто технических недостатков, связанных с этой хакерской атакой, я считаю, что с Cetus все команды DeFi должны избавиться от ограничений чисто технического мышления и действительно развивать сознание о рисках безопасности как «финансовые инженеры».

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

Это напоминает мне о предыдущем опыте работы в компании по безопасности, включая согласие таких больших игроков в отрасли, как @evilcos, @chiachih_wu, @yajinzhou, @mikelee205.

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

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

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