Рефлексия по поводу инцидента с хакером Cetus: безопасность Децентрализованных финансов должна выйти за рамки чисто технического мышления

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

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

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

Удивительно, но Cetus допустил упущение по каждому из условий "срабатывания". Например, система приняла астрономическое число, использовала крайне опасные операции с большими смещениями и полностью доверилась механизму проверки внешней библиотеки. Самое фатальное, что когда система вычислила абсурдный результат "1 токен за баснословную долю", она даже не выполнила никакой проверки экономической целесообразности и просто исполнила его.

Таким образом, настоящие вопросы, над которыми Cetus должен задуматься, включают в себя:

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

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

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

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

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

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

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

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

CETUS-7.56%
DEFI-4.29%
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
  • Награда
  • 6
  • Поделиться
комментарий
0/400
GasWhisperervip
· 07-17 18:44
мемпул patterns never lie... integer-mate был просто Gateway, а не основной уязвимость, честно говоря
Посмотреть ОригиналОтветить0
DataOnlookervip
· 07-17 15:56
Мастер сбрасывания вины, этот Cetus
Посмотреть ОригиналОтветить0
ImpermanentLossEnjoyervip
· 07-15 05:30
Потери можно восстановить, Шан Хао
Посмотреть ОригиналОтветить0
DegenApeSurfervip
· 07-15 05:30
Кто жив, тот и отвечает.
Посмотреть ОригиналОтветить0
SatoshiLegendvip
· 07-15 05:30
Почему проекты DeFi часто сталкиваются с такими ошибками переполнения целых чисел? Прежде чем углубляться в суть, нужно сначала понять алгоритм pow.
Посмотреть ОригиналОтветить0
GasOptimizervip
· 07-15 05:28
Сброс blame, действительно, это ошибка, что не проверили.
Посмотреть ОригиналОтветить0
  • Закрепить