DeFi. Безопасность. Разбор взлома Radiant Capital
… и хотя по меркам IT-мира, а тем более - мира Web 3.0 & Web3 (WW3) это всё было давно, в деле много важных деталей, на которых стоит поучиться: чего стоит хотя бы “взлом” SAFE, который многие используют как холодный кошелёк, а то и основное хранилище казны (трежери) ДАО?
Итак, история, её разбор и последствия.
Перевод первоисточника
У нас есть важное обновление по инциденту от 16 октября 2024 года, когда Radiant Capital стал целью высококвалифицированной кибератаки, приведшей к утрате активов на сумму около 50 миллионов долларов США.
17 октября 2024 года Radiant опубликовал отчёт о произошедшем и впоследствии привлёк Mandiant, ведущую компанию в сфере кибербезопасности, для помощи в расследовании, в частности в области анализа устройств.
Параллельно DAO Radiant Capital наняла zeroShadow и Hypernative для отслеживания активов в блокчейне и привлекла SEAL 911 для дополнительной поддержки.
Этот обзор включает дополнительные выводы, сделанные Mandiant в ходе продолжающегося расследования, детализирует сложные методы, использованные атакующими, и подчеркивает острую необходимость в улучшении отраслевых практик проверки транзакций.
Обзор инцидента
11 сентября 2024 года разработчик Radiant получил сообщение в Telegram от якобы бывшего подрядчика, заслуживающего доверия.
В сообщении говорилось, что подрядчик развивает новую карьеру, связанную с аудитом смарт-контрактов. В нём содержалась ссылка на архивированный PDF-файл с описанием предполагаемой новой деятельности и просьбой оставить отзыв о работе.
Запросы на проверку PDF-файлов являются рутиной в профессиональной среде — юристы, аудиторы смарт-контрактов и партнёры часто делятся документами в этом формате.
Учитывая привычность таких взаимодействий и то, что сообщение пришло от бывшего подрядчика, файл не вызвал подозрений и был передан другим разработчикам для проверки.
Кроме того, домен, связанный с ZIP-файлом, убедительно имитировал легитимный сайт подрядчика, что ещё больше снижало подозрения. [Прим. Menaskop: скажу честно, все эти обтекаемые формулировки, навроде - “привычность таких действий” или “имитировал легитимный сайт” - вызывают ещё большие подозрения, т.к. нет пруфов - нет ничего].
При более детальном рассмотрении стало понятно, что это сообщение, вероятно, было отправлено злоумышленником, связанным с КНДР, который выдавал себя за бывшего подрядчика.
Этот ZIP-файл, переданный для проверки другим разработчикам, в итоге содержал вредоносное ПО, ставшее основой последующего вторжения.
Внутри ZIP-файла злоумышленники разместили сложное вредоносное ПО — INLETDRIFT, находившееся в архиве с именем Penpie_Hacking_Analysis_Report.zip.
Оно создавало постоянный бэкдор на устройствах macOS, отображая при этом пользователю PDF-документ, выглядящий как легитимный. Для связи с доменом atokyonews[.]com использовался вредоносный AppleScript. [Прим. Menaskop: как видим, уже несколько практик нарушено, но главное, что нападающие - тоже не лыком шиты].
Эта уловка была настолько мастерски проведена, что даже при стандартных лучших практиках Radiant, таких как симуляция транзакций в Tenderly, проверка данных payload и соблюдение стандартных операционных процедур (SOP), атакующим удалось взломать устройства нескольких разработчиков.
Интерфейсы фронтенда отображали безобидные данные транзакций, в то время как в фоновом режиме подписывались вредоносные транзакции.
Традиционные проверки и симуляции не выявляли очевидных расхождений, делая угрозу практически незаметной на этапе стандартного анализа. [Прим. Menaskop: рекомендую поэтому изучить и случай, описанный мною ранее].
Обзор Penpie_Hacking_Analysis_Report.zip внутри INLETDRIFT
Сам файл: Penpie_Hacking_Analysis_Report.zip/Penpie_Hacking_Analysis_Report/Penpie_Hacking_Analysis_Report.app/Contents/Resources/Scripts/main.scpt. (MD5: FF15427D45B84E79B2E81199613041BB).
Penpie_Hacking_Analysis_Report.zip
├── Penpie_Hacking_Analysis_Report.app
Отображаемое имя: com.atokyo.News. Сеть: hxxps://atokyonews[.]com/CloudCheck.php. Демон: LaunchDaemons/com.apple.systemextensions.cache.plist.
После запуска пользователю отображался легитимный PDF-файл, как показано ниже:
Что было дальше?
В предшествующие ограблению недели злоумышленники тщательно подготовили вредоносные смарт-контракты на платформах Arbitrum, Binance Smart Chain, Base и Ethereum, как было подробно описано в предыдущем отчёте о произошедшем. (Прим. Menaskop: см. об этом ниже).
Через три минуты после совершения кражи 16 октября 2024 года они быстро удалили следы бэкдора и связанных с ним расширений для браузера.
Mandiant приписывает эту атаку группе UNC4736, также известной как AppleJeus или Citrine Sleet.
С высокой степенью уверенности Mandiant оценивает, что UNC4736 имеет связь с Корейской Народно-Демократической Республикой (КНДР). В частности, эта группа связана с Генеральным разведывательным управлением (GRU) КНДР и тесно сотрудничает с TEMP.Hermit.
Хотя расследование продолжается, Mandiant с высокой уверенностью утверждает, что эта атака была проведена группой, имеющей связь с КНДР. (Прим. Menaskop: как и всегда - козёл отпущения найден и явно - не в собственных рядах).
Широкие отраслевые выводы
Данный инцидент демонстрирует, что даже строгие стандартные операционные процедуры (SOP), аппаратные кошельки, инструменты для симуляции, такие как Tenderly, и тщательная проверка могут быть обойдены “высокоразвитыми угрозоносными акторами”.
Зависимость от "слепой" подписи и фронтенд-верификаций, которые могут быть подделаны, требует разработки более надёжных решений на уровне аппаратного обеспечения для декодирования и проверки payload транзакций.
С развитием индустрии DeFi ей необходимо двигаться от поверхностных проверок к внедрению прозрачности на уровне устройств, чтобы защититься от всё более сложных атак.
(Прим. Menaskop: как по мне - кота за … уши притянули: виноваты не мы, а “общеотраслевые стандарты”: а то, что сайт - фишинговый, файл - pdf, лицо, его выславшее, не верифицировано даже по голосу, это ок?)...
Но, как по мне - это всё туфта, т.к. деньги украли явно не самым сложным образом: нет, я не хочу сказать, что хакеры плохи, но я хочу подчеркнуть, что и команда протокола - не лучшим образом поступила.
Впрочем, давайте разбираться дальше…
Отчёт №01 по взлому
Конечно, логично было его сначала дать вам, но это только на 1-й взгляд: в отчёте выше изложена суть позиции, а она - самое важное в этом деле. А с фактологией попробуем разобраться сейчас.
Обстоятельства дела
16 октября 2024 года Radiant Capital столкнулся с утечкой (в) безопасности, приведшей к потере около 50 миллионов долларов США.
Атака затронула трёх разработчиков Radiant, каждый из которых является давним и заслуживающим доверия участником DAO. Эти разработчики использовали аппаратные кошельки и находились в разных географических регионах, что снижает вероятность скоординированной физической атаки.
Злоумышленникам удалось скомпрометировать устройства как минимум этих трёх ключевых участников с помощью сложной инъекции вредоносного ПО. Эти устройства использовались для подписания вредоносных транзакций.
Хотя подтверждено, что три устройства были скомпрометированы, вероятно, что атака затронула и другие устройства — способ их компрометации пока неизвестен и остаётся предметом расследования. [Прим. Menaskop: поэтому и дал сразу итоговый отчёт, где написано, что способ был далеко не самый сложный применён].
Устройства были скомпрометированы таким образом, что фронтенд Safe{Wallet} (ранее Gnosis Safe) отображал легитимные данные транзакций, в то время как вредоносные транзакции подписывались и выполнялись в фоновом режиме.
Нарушение произошло в ходе рутинного процесса корректировки эмиссий в мульти-подписи, который периодически проводится для адаптации к рыночным условиям и уровню использования. [Прим. Menaskop: а вот это то, что меня по-настоящему интересует, т.к. SAFE - не самописный скрипт, склеенный из г. и палок за 15 минут, а добротное ПО: хочется понять его роль в инциденте].
Участники DAO строго следовали стандартным операционным процедурам (SOP) на протяжении всего процесса.
Каждая транзакция была симулирована для проверки на Tenderly и индивидуально проверялась несколькими разработчиками на каждом этапе подписания. Проверки на фронтенде - как Tenderly, так и Safe - не выявили аномалий во время этих проверок.
Важно отметить, что компрометация осталась полностью незаметной во время ручной проверки интерфейса Gnosis Safe и этапов симуляции на Tenderly. Это было подтверждено внешними командами по безопасности, включая SEAL911 и Hypernative.
Фронтенд-проверка всех трех мультисиг-транзакций не показала признаков взлома, за исключением повторной отправки транзакций через Safe App из-за сбоев.
Следует отметить, что повторная отправка транзакций через Safe из-за сбоев является обычным и ожидаемым явлением. Транзакции в Safe могут завершаться неудачей по множеству причин, включая колебания цены на газ, несоответствие nonce, сетевую перегрузку, недостаточный лимит газа, ошибки выполнения смарт-контрактов, нехватку токенов, незавершённые транзакции, проблемы с синхронизацией фронтенда, таймауты или ошибки разрешений/подписей в настройках. [Прим. Menaskop: всё описанное никак не влияет на то, что всегда надо точно разобраться в том, а почему случился revert, иначе это лишь отписки].
По этой причине подобное поведение не вызвало немедленных подозрений.
Злоумышленники воспользовались этой “нормальностью”, чтобы собрать несколько скомпрометированных подписей за несколько попыток, при этом имитируя видимость обычных сбоев транзакций.
Впоследствии злоумышленники вывели около 50 миллионов долларов США из ключевых рынков на Arbitrum и BSC.
Кроме того, они воспользовались открытыми аппрувами, чтобы вывести средства с пользовательских счетов. [Прим. Menaskop: ещё один пример, что аппрувы надо отзывать всегда, а Permit-разрешения - так себе практика].
Всем пользователям платформы Radiant настоятельно рекомендовалось отозвать любые разрешения на ВСЕХ цепочках — Arbitrum, BSC, Ethereum и Base.
DAO тесно сотрудничает с правоохранительными органами США и ZeroShadow, поддерживая отличные отношения с обеими сторонами. Все стороны полностью проинформированы о нарушении и активно работают над заморозкой украденных активов.
DAO глубоко потрясено этой атакой и продолжит оставаться доступным круглосуточно, чтобы оказывать помощь соответствующим органам в процессе идентификации злоумышленника и как можно более быстрого возврата украденных средств.
Вектор атаки и его методология
Цель злоумышленников заключалась в получении трех подписей в мультисиге с аппаратных кошельков для авторизации действия transfer Ownership (смена владельца).
Им удалось скомпрометировать устройства нескольких разработчиков — подтверждено как минимум три случая, однако точное число пока остаётся неизвестным. Способ компрометации устройств также пока не установлен. [Прим. Menaskop: см. выше - установлен].
В рамках атаки использовалась сложная методология, при которой разработчики, использовавшие Safe{Wallet} для проверки транзакций, видели на фронтенде транзакции, выглядевшие легитимно.
Когда они одобряли транзакцию, скомпрометированные устройства перехватывали это одобрение и вместо этого отправляли вредоносную транзакцию на аппаратные кошельки для подписи.
После этого интерфейс Safe отображал сообщение об ошибке, побуждая пользователей попытаться выполнить подпись снова. Этот процесс позволил злоумышленникам получить три действительных, но вредоносных подписи.
Несмотря на использование нескольких уровней проверки, включая симуляцию транзакций через Tenderly и другие инструменты аудита, подписанные транзакции выглядели нормальными в интерфейсе.
Слепые подписи, отображаемые на аппаратных кошельках Ledger, также выглядели корректными, что ещё больше усложняло обнаружение атаки. Эти тактики позволили злоумышленникам незаметно выполнить действие transferOwnership.
Последствия для безопасности
Наиболее тревожный аспект этой атаки — высокий уровень её сложности.
Скомпрометированные устройства не демонстрировали явных признаков взлома, за исключением мелких сбоев и сообщений об ошибках во время процесса подписания — проблем, которые часто возникают при взаимодействии с аппаратными кошельками и Safe. [Прим. Menaskop: как по мне - это явная ложь: ошибки - показываются, да ещё не один раз, но разработчики, да ещё ведущие, на них не реагируют и даже не пробуют разобраться, а что именно не так].
Эти рутинные сообщения об ошибках оказались единственными индикаторами более глубокой проблемы, которые при нормальных обстоятельствах не вызвали бы немедленного подозрения.
Рекомендации по предотвращению
Эксперты, анализирующие эксплойт, считают эту атаку одной из самых сложных в истории DeFi, а многие протоколы остаются уязвимыми. Для предотвращения подобных атак в будущем рекомендуется:
- Многоуровневая проверка подписей: Внедрить слой управления, при котором, если хотя бы один из подписантов сталкивается с проблемами или аномалиями, процесс приостанавливается для дополнительной проверки. Это должно срабатывать, даже если ошибка кажется незначительной (например, транзакция, которая должна была быть одобрена, не проходит).
- Независимое устройство для проверки: Использовать независимое устройство для проверки данных транзакции перед подписанием. Оно должно генерировать код проверки подписи, который соответствует данным, представленным на аппаратном кошельке.
- Усиленная безопасность Ledger/Trezor: Избегать слепой подписи для критически важных транзакций. Если это неизбежно, обеспечить наличие отдельного уровня видимой проверки, например, отображения данных транзакции в читаемом формате непосредственно на аппаратном кошельке.
- Аудит при повторяющихся ошибках: Интегрировать механизм, при котором повторяющиеся ошибки или сбои транзакций автоматически запускают полный аудит транзакции перед выполнением дополнительных попыток подписания.
- Ручная проверка данных транзакции: При выводе запроса на подпись из провайдера кошелька (например, Metamask, Rabby), выгружать данные транзакции и декодировать их через [Etherscan Input Data Decoder]. Убедиться, что вызываемая функция и адрес совпадают с ожидаемым поведением. Если устройство было скомпрометировано, данные могут не декодироваться, вызывать другую функцию или содержать некорректный адрес владельца.
- Также рекомендуется дважды подтверждать каждый хэш сообщения на аппаратных кошельках с использованием Gnosis [Инструкция по проверке транзакций на аппаратном кошельке].
Заключение после инцидента
В результате атаки были скомпрометированы устройства трёх разработчиков Radiant, каждый из которых является проверенным (?) и надёжным (??) участником DAO.
Злоумышленники использовали вредоносное ПО для манипуляции данными транзакций на уровне устройств, обходя ручные проверки и симуляции в Tenderly, которые показывали нормальные результаты.
Скомпрометированные устройства позволили злоумышленникам собрать несколько "заражённых" подписей через поддельные транзакции, которые выглядели легитимными для подписантов.
Хотя аппаратные кошельки обычно считаются безопасными, использование слепой подписи, особенно в среде DeFi, создаёт значительные риски. Атакующие воспользовались этим, показывая нормальные транзакции в интерфейсе Gnosis Safe без явных аномалий, за исключением рутинных сбоев транзакций — что является обычным явлением и затрудняет обнаружение. [Прим. Menaskop: сбой - по определению не может быть рутинным].
Меры, принятые после инцидента
- Создание новых адресов и кошельков: все члены Safe создали новые холодные кошельки на новых, не заражённых устройствах, чтобы устранить любые оставшиеся уязвимости.
- Ужесточение безопасности мультисига: Число подписантов было сокращено до 7, а порог подписей установлен на уровне 4 из 7. Это гарантирует, что для выполнения транзакции потребуется одобрение почти 60% подписантов.
- Дополнительная проверка данных транзакций: Теперь каждый участник будет дважды проверять данные транзакции с использованием декодера данных ввода на [Etherscan], добавляя дополнительный уровень точности перед подписанием.
- Восстановление (торгов): Предполагается, что DAO сможет возобновить работу рынков Base и Ethereum в течение нескольких дней.
- Создание новых Safe для RIZ-рынков: Будут созданы новые Safe для RIZ-рынков, а владение контрактами RizRegistry будет передано этим безопасным Safe. Это обеспечит разделение от основных рынков.
- Внедрение таймлок-контрактов: Все обновления контрактов и передачи прав собственности будут проходить с минимальной задержкой в 72 часа, что обеспечит сообществу и разработчикам достаточно времени для проверки изменений. Однако такая задержка может замедлить реакцию на критические уязвимости, и неизвестно, смогли бы таймлоки предотвратить эту атаку, учитывая компрометацию устройств трёх подписантов.
- Разделение ролей: В ключевых контрактах разрешённые роли были разделены, чтобы ни одна роль не обладала «супер» полномочиями. Это снижает риск получения избыточного контроля одним человеком или группой.
- Развёртывание Aave V2 Lending Suite: Для восстановления основных рынков на Arbitrum и BSC DAO развернёт весь комплект контрактов Aave V2 Lending Suite, включая: LendingPoolAddressesProvider, LendingPoolAddressesProviderRegistry, LendingPool, LendingPoolConfigurator, LendingPoolCollateralManager, LendingRateOracle, AaveOracle, AaveProtocolDataProvider.
Детализированная временная шкала событий
2024-10-02
Был развёрнут вредоносный контракт через транзакцию: arbiscan.io/tx/0x149bd3b684cf63decffbdd1865a20fddf131fb59469d093b2b6d9aa57a0ce4c2
Контракт предназначался для вредоносных целей и был активирован через несколько дней.
Контракт: arbiscan.io/address/0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5
08:22:46 UTC — Binance Smart Chain (BSC)
Похожий вредоносный контракт был развернут в сети BSC через транзакцию: bscscan.com/tx/0x65419cd822bb616f2d9dacbcfacf81714761f9815cc26b9451cd70f0348232fa
Контракт: bscscan.com/address/0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5
Аналогичные вредоносные контракты были развернуты в сетях Base и Ethereum Mainnet, однако их выполнение не было успешным:
- Base: basescan.org/address/0x57ba8957ed2ff2e7AE38F4935451E81Ce1eEFbf5
- Ethereum: etherscan.io/address/0x57ba8957ed2ff2e7AE38F4935451E81Ce1eEFbf5
2024-10-16
Разработчик "C1" предложил транзакцию с ARB Nonce 230 для обновления лимитов предложения и займа. В процессе выполнения подпись транзакции несколько раз не удалась (как минимум три раза), что изначально объяснялось проблемами с RPC. [Прим. Menaskop: 3 раза и не было доп. проверки?].
Для устранения проблемы "C1" заменил RPC-сервер Arbitrum, выбрав первый доступный вариант сchainlist.org. После этого подпись транзакции успешно завершилась.
Согласно стандартным операционным процедурам (SOP), эта транзакция была объявлена в #admin-канале группы Telegram "RADIANT — Multisig". В Telegram была размещена следующая публикация:
Это была исходная транзакция с Nonce 230, созданная разработчиком C1:
Однако Nonce 230 в сети ARB был впоследствии перезаписан в 17:09 UTC (см. запись ниже) и заменён на вредоносную транзакцию, которая вызывала функцию transferOwnership:
Один странный момент, который стоит отметить: на момент публикации, при просмотре URL, ссылающегося на отменённую транзакцию ARB Nonce 230, временная метка в интерфейсе отображается как текущее время. Поэтому временная метка "менее минуты назад" отображается, несмотря на то, что это хронологически неверно.
Разработчик C2 предложил изменения для Ethereum Mainnet через ETH Nonce 127, Arbitrum и BSC Chain для обновления ставки распределения токенов RDNT. Однако Nonce 127 был заменён для передачи прав собственности и выполнения вредоносного кода. C2 отметил, что его кошелек Rabby испытывал проблемы в это время. [Прим. Menaskop: проще говоря - всё ломалось по дороге, но никаких трудностей продвинутые разработчики не испытывали?].
Упомянутая вредоносная транзакция заменила ARB Nonce 230, передав право собственности на LendingPoolAddressesProvider новому владельцу.
Транзакция: arbiscan.io/tx/0x7856552db409fe51e17339ab1e0e1ce9c85d68bf0f4de4c110fc4e372ea02fb1
Автоматическая пауза была активирована на Ethereum.
Транзакция: etherscan.io/tx/0xa5dc1b97d72d11940d186596cb7478dedc27c8812c9d3bdf78eba5e8cf4f1006
Автоматическая пауза была активирована на BSC Chain.
Транзакция: bscscan.com/tx/0x873c2382689cad921427e30f16a814ffb2c1e2550e316e767e66759f7abf4a34
Право собственности на LendingPoolAddressesProvider на BSC Chain было передано на адрес 0x57ba8957ed2ff2e7AE38F4935451E81Ce1eEFbf5, что обошло паузу и обновило реализацию.
Транзакция: bscscan.com/tx/0xd97b93f633aee356d992b49193e60a571b8c466bf46aaf072368f975dc11841c
Система оповещений Hypernative отметила подозрительную активность. Разработчик C2 уведомил команду в Telegram. [Прим. Menaskop: и это уже, минимум, 3-й признак взлома, но до сих пор разработчики на него не реагируют]:
Команда пыталась разобраться в ситуации и инициировала первый звонок в "war room" (ситуационный центр).
Была выполнена транзакция для приостановки LendingPool на Base.
Транзакция: basescan.org/tx/0xdeee13d47eca82c8a774ec792f823360013f001e93b5abc17cb939f25187d00e
Учитывая возможную угрозу атаки "man-in-the-middle", команда безопасности решила, что любые последующие действия для удаления скомпрометированных кошельков должны быть выполнены только после должной оценки рисков.
Были выполнены транзакции для удаления скомпрометированных кошельков на
Были выполнены транзакции для удаления скомпрометированных кошельков на Base:
- basescan.org/tx/0x9e9eb36b2e2f221b5a04dc378d04518abcaab3a46d612cfffc5583a97b669c26
- basescan.org/tx/0x4e72bb1d48666d732f2e091cecd20b3c34db484bf197ff197e49252069d1d465
- basescan.org/tx/0xe71188ce592464b3f680a54f014f61b1eece403f261d39cfbfa0f67ab1d424ed
Были выполнены транзакции для удаления скомпрометированных кошельков на BSC:
- bscscan.com/tx/0x511e05be6caf926d755ddd13747f193328af5835557c453d91861cfa46eadd77
- bscscan.com/tx/0x84ab76d7a5b8bb4b9b6656f85fe4fec3fc07eab48199c895548324de9c78e725
- bscscan.com/tx/0x722a4557c11f1684f13ff03d4e9d97a89b955088e935e0f3ed7d71e3d2ae0281
Примечания
Некоторые разработчики сообщили о проблемах с подписанием транзакций в приложении Safe{Wallet}. Разработчик C3 упомянул: "За последние недели мне приходилось подписывать транзакции дважды в Rabby. C2 также отметил проблемы с RPC. После взлома мой кошелек Rabby перестал работать и исчез, подобно тому, что произошло с C2."
C1 также сообщил, что ему пришлось повторно подписывать транзакции после первоначальных неудач.
Рутинные обновления в протоколе Radiant требуют транзакций от Admin multisig, который обладает наиболее критичными правами в системе.
Скомпроментированные кошельки:
- 0x20340c2a71055FD2887D9A71054100FF7F425BE5 (Ledger hardware wallet managed via Rabby)
- 0x83434627e72d977af18F8D2F26203895050eF9Ce (Ledger hardware wallet managed via Rabby)
- 0xbB67c265e7197A7c3Cd458F8F7C1d79a2fb04d57 (Trezor hardware wallet managed via Frame)
- Ethereum: 0x0235a22a38Dd09291800e097bD2ebE6e3b4d5F04 (3/9)
- BSC Chain: 0xE4714D6BD9a6c0F6194C1aa8602850b0a1cE1416 (3/11)
- Base: 0xBBf7eDF92926b775A434f9DF15860f4CD268B0A0 (3/9)
- Arbitrum: 0x111CEEee040739fD91D29C34C33E6B3E112F2177 (3/11)
- 0x0629b1048298AE9deff0F4100A31967Fb3f98962 (Main attacker)
- 0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5 (Main attack contract)
- 0x911215CF312a64C128817Af3c24B9fDF66B7Ac95 (Testing address)
- 0x97a05becc2e7891d07f382457cd5d57fd242e4e8 (Laundering address)
- 0x9c5939AAC4f65A0eA233E657507C7b54acDE2841 (Laundering address)
- 0x8B75E47976C3C500D0148463931717001F620887 (Funds consolidated on Arb + Eth)
- 0xcF47c058CC4818CE90f9315B478EB2f2d588Cc78 (Funds consolidated on BSC)
- 0xa0e768a68ba1bfffb9f4366dfc8d9195ee7217d1 (GMX interactions / swaps)
- 0xc24927Bd40Bab67CcfB2ca0A90d6cbB8Edb21302 (Approvals drainer on Arbitrum)
- 0x579145D6d1F26a460d9BDD3040C37517dac379ac (Approvals drainer on BSC)
- 0xC4173a794122644870C8fd07c226acF992507897 (Approvals drainer on BSC + ARB)
- 0x3D4C56cdB97355807157F5C7d4F54957f0E9af44 (Contract created on 17th October)
- 0x3c09Ae8571db07a3347c1D577BB9a54F96bFfa24 (Contract created on 17th October)
- 0xbc20e84d80a684dAEa4468be6F199a233A3d2363 (Test contract)
- 0x5eb63694A18B618C4EbDd9CA3333fa7f9b8B9cB4 (Related to test contract)
- 0xD899F3d8ff2A723642d5C55eD1998713C530b7b3 (Related to test contract)
Визуализация атаки
Источники данных
- Описание в блоге проекта
- Апдейт в блоге проекта
- Краткое описание (аннотация)
- Описание в твиттере
- Описание в новости
- Альтернативное описание
- Описание на русском на Forklog
Выводы
Считаю, что несмотря на сложность атаки, примерно 80% её успешности - это не реагирование на угрозы со стороны проекта, а лишь 20% - мастерство хакеров.
Но, конечно же, выставлено всё как раз ровно наоборот. Это плохо.