Размышления и выводы о нападении Хакера на Протокол Cetus

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

Отчет подробно объясняет ошибки проверки функции checked_shlw в библиотеке integer-mate (должно быть ≤2^192, на самом деле ≤2^256) и квалифицирует это как "семантическое недоразумение". Хотя такое изложение с технической точки зрения не вызывает нареканий, оно ловко смещает акцент на внешнюю ответственность, как будто протокол сам является невинной жертвой этого технического недостатка.

Однако стоит задуматься: если integer-mate — это широко используемая открытая математическая библиотека, почему же в этом Протоколе возникла такая абсурдная ошибка, из-за которой всего лишь 1 токен может получить баснословную долю ликвидности?

Анализируя путь атаки Хакера, можно обнаружить, что для успешной реализации атаки необходимо одновременно выполнить четыре условия: неверная проверка на переполнение, большие операции сдвига, правила округления вверх и отсутствие проверки экономической обоснованности. Удивительно, но Протокол проявил "беспечность" по каждому из условий "срабатывания": принятие пользовательского ввода таких астрономических чисел, как 2^200, использование крайне опасных больших операций сдвига, полное доверие механизму проверки внешних библиотек. Наиболее фатальным стало то, что когда система вычислила "1 токен за баснословную долю" — явно неразумный результат, это было выполнено без какой-либо проверки на экономическую целесообразность.

Таким образом, вопросы, которые действительно необходимо переосмыслить в этом Протоколе, включают:

1. Почему при использовании общих внешних библиотек не проводилось достаточного тестирования на безопасность? Хотя библиотека integer-mate обладает такими характеристиками, как открытость, популярность и широкое использование, при управлении активами на сумму в сотни миллионов долларов протокол явно не имеет глубокого понимания безопасных границ этой библиотеки и резервных вариантов на случай сбоя функций библиотеки. Это подчеркивает недостаток осведомленности протокола о безопасности цепочки поставок.

2. Почему разрешено вводить астрономические числа без установки разумных границ? Хотя децентрализованные финансовые Протоколы стремятся к открытости, чем более зрелая финансовая система, тем больше ей нужны четкие границы. Разрешение на ввод таких экстравагантных значений указывает на то, что команде не хватает специалистов по управлению рисками с финансовой интуицией.

3. Почему после нескольких раундов безопасности аудита все еще не удалось заранее обнаружить проблемы? Это отражает смертельное когнитивное искажение: команда проекта полностью делегировала ответственность за безопасность сторонним компаниям, рассматривая аудит как золотую медаль освобождения от ответственности. Однако инженеры по безопасности в основном специализируются на выявлении уязвимостей в коде и редко учитывают возможные проблемы, когда тестовая система вычисляет крайне неразумные обменные коэффициенты.

Такое верификация, пересекающая границы математики, криптографии и экономики, является самой большой слепой зоной в области безопасности современного децентрализованного финансов. Аудиторские компании могут считать это недостатком проектирования экономической модели, а не проблемой логики кода; команда проекта может жаловаться, что аудит не выявил проблемы; а в конечном итоге страдают активы пользователей.

Это событие выявило системные недостатки безопасности в индустрии децентрализованных финансов: команды с чисто техническим фоном часто серьезно лишены базового "финансового риск-ощущения".

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

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

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

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

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