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