Команды с чисто техническим фоном серьезно не хватает базового «финансового риск-ощущения».
Автор: Haotian
Прочитав отчет о «разборе» хакерской атаки на @CetusProtocol, вы обнаружите «забавное» явление: технические детали раскрыты довольно прозрачно, а реагирование на чрезвычайные ситуации можно считать образцовым, но на самый важный вопрос «почему произошла атака» они, кажется, уклоняются от ответа.
Отчет в значительной степени объясняет функцию checked\_shlw библиотеки integer-mate, которая проверяет ошибки (должно быть ≤2^192, на самом деле ≤2^256) и квалифицирует это как «семантическое недоразумение». Хотя такое утверждение технически верно, оно искусно смещает фокус на внешнюю ответственность, как будто Cetus также является невиновной жертвой этого технического недостатка.
Вопрос в том, как так получается, что integer-mate является открытой и широко используемой математической библиотекой, но при этом у вас произошла абсурдная ошибка, при которой за 1 токен можно получить огромную долю ликвидности?
Анализируя пути хакерских атак, можно обнаружить, что для осуществления идеальной атаки хакеры должны одновременно выполнить четыре условия: ошибки в проверке переполнения, значительные операции сдвига, правила округления вверх и отсутствие проверки экономической целесообразности.
Cetus в каждом случае «триггера» проявил «неосторожность», например: прием пользовательского ввода 2^200 таких астрономических чисел, использование крайне опасных операций с большими смещениями, полная доверие к механизмам проверки внешних библиотек, и самое смертельное — когда система вычислила абсурдный результат «1 токен за баснословную долю», она даже не выполнила никаких проверок экономической логики и сразу же исполнила.
Таким образом, вот основные моменты, над которыми Cetus действительно должен задуматься:
Почему использование универсальных внешних библиотек не прошло должного тестирования на безопасность? Хотя библиотека integer-mate имеет такие характеристики, как открытость, популярность и широкое использование, Cetus использует ее для управления активами на сумму более ста миллионов долларов, но не понимает, где находятся границы безопасности этой библиотеки, есть ли подходящие альтернативы в случае неэффективности библиотеки и так далее. Очевидно, что у Cetus отсутствует самая базовая осведомленность о безопасности цепочки поставок;
2)Почему разрешено вводить астрономические цифры без установления границ? Хотя DeFi протоколы должны стремиться к децентрализации, чем более открыта зрелая финансовая система, тем больше ей нужны четкие границы.
Когда система позволяет вводить астрономические числа, тщательно сконструированные злоумышленником, команда, очевидно, не задумывалась над тем, разумен ли такой спрос на ликвидность? Даже крупнейшие хедж-фонды в мире не могут нуждаться в таких exaggerated долях ликвидности. Очевидно, что у команды Cetus не хватает специалистов по управлению рисками с финансовым чутьем;
Почему, несмотря на многоуровневые аудиты безопасности, проблемы все равно не были обнаружены заранее? Эта фраза невольно указывает на смертельное заблуждение: команда проекта передает ответственность за безопасность специализированным компаниям, рассматривая аудит как некое освобождение от ответственности. Но реальность жестока: инженеры по аудиту безопасности хорошо разбираются в поиске ошибок в коде, кто бы мог подумать, что при тестировании системы расчет обменного курса может быть неправильным?
Валидация на границе математики, криптографии и экономики является самой большой слепой зоной безопасности современного DeFi. Аудиторские компании говорят: «Это недостаток в проектировании экономической модели, а не проблема логики кода»; разработчики проекта жалуются: «Аудит не выявил проблем»; а пользователи просто знают, что их деньги пропали!
Смотри, в конечном итоге это раскрывает системные недостатки безопасности в индустрии DeFi: команды с чисто техническим опытом серьезно испытывают нехватку базового «финансового риска».
Согласно этому отчету Cetus, команда явно не сделала должных выводов.
По сравнению с чисто техническими недостатками, связанными с этой хакерской атакой, я считаю, что начиная с Cetus, всем командам DeFi следует избавиться от ограничений чисто технического мышления и действительно развивать осознание рисков безопасности как «финансовые инженеры».
Например: привлечь экспертов по финансовым рискам, чтобы восполнить пробелы в знаниях технической команды; провести многосторонний механизм аудита, который включает не только аудит кода, но и необходимый аудит экономических моделей; развивать «финансовое чутье», моделируя различные сценарии атак и соответствующие меры реагирования, оставаться чувствительными к аномальным операциям и так далее.
Это напоминает мне о предыдущем опыте работы в безопасности, включая общение с такими гигантами отрасли, как @evilcos, @chiachih_wu, @yajinzhou, @mikelee205, которые также пришли к такому мнению:
С учетом того, что отрасль становится все более зрелой, проблемы с технологическими ошибками на уровне кода будут постепенно уменьшаться, тогда как «осознанные ошибки» в бизнес-логике с нечеткими границами и неясными обязанностями станут самой большой проблемой.
Аудиторская компания может лишь гарантировать, что в коде нет ошибок, но для того, чтобы обеспечить «логические границы», команде проекта необходимо более глубокое понимание сути бизнеса и способность контролировать границы. (Основная причина многих инцидентов, когда после аудита безопасности все равно происходили атаки хакеров, заключается именно в этом)
Будущее DeFi принадлежит тем командам, которые обладают сильными навыками программирования и глубоким пониманием бизнес-логики!
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Безопасностные проблемы Cetus: на что команде Децентрализованные финансы стоит обратить внимание?
Автор: Haotian
Прочитав отчет о «разборе» хакерской атаки на @CetusProtocol, вы обнаружите «забавное» явление: технические детали раскрыты довольно прозрачно, а реагирование на чрезвычайные ситуации можно считать образцовым, но на самый важный вопрос «почему произошла атака» они, кажется, уклоняются от ответа.
Отчет в значительной степени объясняет функцию
checked\_shlw
библиотекиinteger-mate
, которая проверяет ошибки (должно быть ≤2^192, на самом деле ≤2^256) и квалифицирует это как «семантическое недоразумение». Хотя такое утверждение технически верно, оно искусно смещает фокус на внешнюю ответственность, как будто Cetus также является невиновной жертвой этого технического недостатка.Вопрос в том, как так получается, что
integer-mate
является открытой и широко используемой математической библиотекой, но при этом у вас произошла абсурдная ошибка, при которой за 1 токен можно получить огромную долю ликвидности?Анализируя пути хакерских атак, можно обнаружить, что для осуществления идеальной атаки хакеры должны одновременно выполнить четыре условия: ошибки в проверке переполнения, значительные операции сдвига, правила округления вверх и отсутствие проверки экономической целесообразности.
Cetus в каждом случае «триггера» проявил «неосторожность», например: прием пользовательского ввода 2^200 таких астрономических чисел, использование крайне опасных операций с большими смещениями, полная доверие к механизмам проверки внешних библиотек, и самое смертельное — когда система вычислила абсурдный результат «1 токен за баснословную долю», она даже не выполнила никаких проверок экономической логики и сразу же исполнила.
Таким образом, вот основные моменты, над которыми Cetus действительно должен задуматься:
integer-mate
имеет такие характеристики, как открытость, популярность и широкое использование, Cetus использует ее для управления активами на сумму более ста миллионов долларов, но не понимает, где находятся границы безопасности этой библиотеки, есть ли подходящие альтернативы в случае неэффективности библиотеки и так далее. Очевидно, что у Cetus отсутствует самая базовая осведомленность о безопасности цепочки поставок;2)Почему разрешено вводить астрономические цифры без установления границ? Хотя DeFi протоколы должны стремиться к децентрализации, чем более открыта зрелая финансовая система, тем больше ей нужны четкие границы.
Когда система позволяет вводить астрономические числа, тщательно сконструированные злоумышленником, команда, очевидно, не задумывалась над тем, разумен ли такой спрос на ликвидность? Даже крупнейшие хедж-фонды в мире не могут нуждаться в таких exaggerated долях ликвидности. Очевидно, что у команды Cetus не хватает специалистов по управлению рисками с финансовым чутьем;
Валидация на границе математики, криптографии и экономики является самой большой слепой зоной безопасности современного DeFi. Аудиторские компании говорят: «Это недостаток в проектировании экономической модели, а не проблема логики кода»; разработчики проекта жалуются: «Аудит не выявил проблем»; а пользователи просто знают, что их деньги пропали!
Смотри, в конечном итоге это раскрывает системные недостатки безопасности в индустрии DeFi: команды с чисто техническим опытом серьезно испытывают нехватку базового «финансового риска».
Согласно этому отчету Cetus, команда явно не сделала должных выводов.
По сравнению с чисто техническими недостатками, связанными с этой хакерской атакой, я считаю, что начиная с Cetus, всем командам DeFi следует избавиться от ограничений чисто технического мышления и действительно развивать осознание рисков безопасности как «финансовые инженеры».
Например: привлечь экспертов по финансовым рискам, чтобы восполнить пробелы в знаниях технической команды; провести многосторонний механизм аудита, который включает не только аудит кода, но и необходимый аудит экономических моделей; развивать «финансовое чутье», моделируя различные сценарии атак и соответствующие меры реагирования, оставаться чувствительными к аномальным операциям и так далее.
Это напоминает мне о предыдущем опыте работы в безопасности, включая общение с такими гигантами отрасли, как @evilcos, @chiachih_wu, @yajinzhou, @mikelee205, которые также пришли к такому мнению:
С учетом того, что отрасль становится все более зрелой, проблемы с технологическими ошибками на уровне кода будут постепенно уменьшаться, тогда как «осознанные ошибки» в бизнес-логике с нечеткими границами и неясными обязанностями станут самой большой проблемой.
Аудиторская компания может лишь гарантировать, что в коде нет ошибок, но для того, чтобы обеспечить «логические границы», команде проекта необходимо более глубокое понимание сути бизнеса и способность контролировать границы. (Основная причина многих инцидентов, когда после аудита безопасности все равно происходили атаки хакеров, заключается именно в этом)
Будущее DeFi принадлежит тем командам, которые обладают сильными навыками программирования и глубоким пониманием бизнес-логики!