Атакующий вывел $6 млн из хранилища в децентрализованных финансах (DeFi), несмотря на то что протокол использовал белый список одобренных адресов — механизм контроля безопасности, предназначенный для ограничения перемещения средств заранее авторизованными направлениями. Платформа Immunefi, специализирующаяся на программах по поиску уязвимостей, раскрыла инцидент и подтвердила потерю $6 млн. Это нарушение обнажает критический пробел в том, как авторизация на основе белых списков реализуется и аудируется в контрактах хранилищ. Контракты хранилищ концентрируют депозиты множества пользователей за одним набором разрешений контракта, поэтому сбой даже одной проверки авторизации может обернуться крупными и мгновенными потерями для вкладчиков.

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

Чего не смог предотвратить белый список одобренных адресов

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

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

Почему одного белого списка недостаточно для безопасности хранилища

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

Вкладчикам, оценивающим хранилища с белыми списками, следует проверить, кто контролирует административный ключ, позволяющий обновлять белый список; какова задержка таймлока при добавлении адресов в список; находится ли контракт хранилища за обновляемым прокси; и проводил ли независимый аудит специальную проверку пути авторизации. Хранилище, рекламируемое как « whitelisted », без раскрытия этих деталей обеспечивает более слабые гарантии, чем подразумевает этот ярлык. Эта модель напоминает проблемы пути авторизации, наблюдавшиеся в инцидентах с мультичейн-протоколами, где исправленные уязвимости заново вводили уязвимое состояние.

Немедленные проверки для вкладчиков и операторов

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

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

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