фон
Blast — это сеть Ethereum Layer 2, запущенная Пакманом (Тиешун Рокерр, он же Тиешун), основателем Blur. Он запустил основную сеть 29 февраля. В настоящее время в основной сети Blast заложено около 19 500 ETH и 640 000 stETH.
Атакованный проект Munchables — качественный проект, победивший в конкурсе Bigbang, организованном Blast.
Должностные лица Blast будут выдавать обычные баллы пользователям, которые вкладывают ETH в сеть Blast:
Чтобы побудить пользователей участвовать в проектах DeFi в экосистеме Blast, официальные лица Blast будут выбирать высококачественные проекты для рекомендаций и поощрять пользователей вкладывать ETH во второй раз в DeFi, чтобы получить более быстрое увеличение количества очков и золотых очков. Несколько пользователей передали ETH, выделенный в основной сети Blast, недавно созданному проекту DeFi.
Зрелость и безопасность этих проектов DeFi еще предстоит изучить, а также то, имеют ли эти контракты достаточные соображения безопасности, чтобы защитить десятки миллионов или даже сотни миллионов долларов пользователей.
Обзор мероприятия
Менее чем через месяц после выхода в сеть основной сети Blast 21 марта 2024 года произошла атака на SSS Token (Super Sushi Samurai). В контракте Token была обнаружена логическая ошибка передачи, которая позволила злоумышленнику увеличить SSS Token указанный счет из воздуха.баланс, проект в конечном итоге потерял более 1310 ETH (около $4,6 млн).
Менее чем через неделю после атаки SSS Token на Blast произошла еще одна более крупная атака: проект Munchables был уничтожен злоумышленниками с 17413,96 ETH, на общую сумму около 62,5 миллионов долларов США.
Через полчаса после того, как произошла атака, 73,49 WETH в контракте проекта также были украдены хакером с другого адреса.
В настоящее время на адресе контракта участника проекта еще хранятся 7276 WETH, 7758267 USDB и 4 ETH, которые в любой момент попадут в руки хакеров.Хакер имеет право забрать все средства Весь проект на общую сумму около 97 миллионов долларов США Подвергнут риску.
Сразу после инцидента известный онлайн-детектив X (Twitter) zachXBT отметил, что основной причиной этой атаки был найм хакеров из определенной страны.
Давайте подробнее рассмотрим, как «хакер из одной страны» осуществил атаку стоимостью почти 100 миллионов долларов.
Восстановление на месте
Жертвы высказываются
[UTC+ 0 ] В 21:37 26 марта 2024 года (через 5 минут после атаки) Munchables официально разместил в X (Twitter) сообщение о том, что он подвергся атаке.
По данным расследования онлайн-детектива Зака Злоумышленник пришел заняться разработкой игр. Он был очень груб и действительно выглядел как китайский хакер. Мы уволили его в течение месяца. Он также пытался заставить нас нанять одного из своих друзья, который, вероятно, тоже был хакером. хакером».
Поскольку эта атака нанесла огромный ущерб пользователям в сообществе, мы немедленно начали расследование в сети.Давайте подробно рассмотрим детали атаки этого «хакера из определенной страны».
Первая сцена
[UTC+0 ] В 21:32 26 марта 2024 года произошла атака с использованием 17413,96 ETH.
С помощью Blastscan мы можем увидеть эту транзакцию атаки:
Поврежденный контракт (0x 29…1 F) представляет собой прокси-контракт, в котором хранятся заложенные средства пользователя. Мы видим, что злоумышленник вызвал функцию разблокировки контракта залога, прошел все проверки разрешений и перевел их. Весь ETH в контракт переходит на адрес злоумышленника 1 (0x 6 E…c 5).
Похоже, что злоумышленник вызвал функцию разблокировки с поведением, похожим на вывод средств, и забрал большую часть ETH из скомпрометированного контракта (0x 29…1 F).
Участники проекта забыли запереть хранилище?
В поврежденном контракте есть две связанные проверки на разблокировку (0x 29…1 F), рассмотрим их поочередно.
Во-первых, мы обнаружили, что в процессе проверки разрешений вызывался метод контракта isRegistered (0x 16…A 0), чтобы проверить, является ли текущий msg.sender, то есть хакерский адрес 1 (0x 6 E…c 5) Уже зарегистрировано:
Ответ: прошел проверку.
Это включает в себя контракт (0x 16…A 0) и соответствующий ему последний логический контракт (0x e 7…f 1).
[UTC+ 0 ] В 08:39 24 марта 2024 года (за 2 дня до атаки) был обновлен логический контракт, соответствующий контракту (0x 16…A 0).
Логическая транзакция обновления контракта:
Логический контракт обновляется до 0x e 7…f 1 .
Здесь можно увидеть исходный логический адрес контракта: 0x 9 e…CD.
В настоящее время мы подозреваем, что хакер обновляет контракт реализации логики контракта агента, который быть 0x 9 e… CD становится вредоносным 0x e 7…f 1 , завершая обход разрешений проверки.
Это правда?
В Web3.0 вам никогда не придется гадать или слушать других, вам нужно лишь освоить технологию, чтобы получить ответ самостоятельно.
Сравнивая два контракта (не контракты с открытым исходным кодом), можно обнаружить некоторые очевидные различия между исходным контрактом 0x 9 e…CD и обновленным 0x e 7…f 1:
Функциональная часть инициализации 0x e 7…f 1 реализована следующим образом:
Функциональная часть инициализации 0x 9 e…CD реализована следующим образом:
Видно, что злоумышленник установил адрес злоумышленника (0x 6 e…c 5) в качестве регистра в исходном логическом контракте (0x 9 e…CD), а также есть два других адреса злоумышленника 0x c 5 …0. d, 0x bf…87 также регистрируются, и во время инициализации в их поле 0 устанавливается время блока. Использование поля 0 будет объяснено позже.
На самом деле, вопреки тому, что мы предполагали, настоящий логический контракт с бэкдором существовал с самого начала, и последующие обновления были нормальными!
Подождите, это обновление появилось в 08:39 24 марта 2024 года [UTC+0] (за 2 дня до атаки).То есть до этого инцидента логический контракт стал контрактом без бэкдоров.Почему?Может ли злоумышленник еще выполнить атака?
Это происходит из-за вызова делегата, поэтому фактическое обновление хранилища состояния находится в контракте (0x 16…A 0), что приводит к тому, что даже если логический контракт позже обновляется до логического контракта без бэкдора 0x e 7… f 1 измененный слот в контракте (0x 16…A 0) все равно не будет восстановлен.
Давайте проверим это:
Как видите, соответствующий слот в контракте (0x 16…A 0) имеет числовое значение.
Это позволяет злоумышленнику пройти проверку метода isRegistered:
Позже злоумышленник меняет контракт бэкдора на обычный контракт, чтобы скрыть тот факт, что бэкдор уже установлен.
Кроме того, процесс разблокировки также предполагает повторную проверку:
Что касается проверки времени блокировки, эта часть призвана гарантировать, что заблокированные активы не будут переданы до истечения срока действия.
Злоумышленнику необходимо убедиться, что время блокировки при вызове разблокировки превышает необходимое время истечения срока действия блокировки (поле 3).
Эта часть проверки включает в себя поврежденный контракт (0x 29…1 F) и соответствующий логический контракт 0x f 5…cd.
В транзакции в 11:54 21 марта 2024 г. [UTC+0] (за 5 дней до атаки):
Мы видим, что исходный логический контракт поврежденного контракта (0x 29…1 F) был 0x 91…11, и всего четыре минуты спустя, в
Обновлен до 0x f 5…cd.
Мы также сравниваем два контракта и видим, что злоумышленник, как и раньше, также использовал трюки в функции инициализации.
Частичная реализация функции инициализации 0x f 5…cd:
Частичная реализация функции инициализации 0x 91…11:
Видно, что очевидно, что тот же метод был использован снова, чтобы изменить количество ETH и время разблокировки, а затем заменил его обычным контрактом, чтобы обмануть других.Когда команда проекта и исследователи безопасности занимались отладкой, все видимые логические контракты являются нормальными, а поскольку все контракты являются контрактами с закрытым исходным кодом, еще труднее ясно увидеть суть проблемы.
На данный момент мы понимаем эту транзакцию с участием 17413 ETH и то, как злоумышленник это сделал, но стоит ли за этим инцидентом столько информации?
В приведенном выше анализе мы фактически увидели, что хакер встроил в контракт 3 адреса:
0x 6 e…c 5 (адрес злоумышленника 1)
0x c 5…0 d (адрес злоумышленника 2)
0x bf…87 (адрес злоумышленника 3)
Однако в транзакции атаки, которую мы нашли выше, мы видели только 0x 6 e…c 5. Что делали два других адреса? А какие секреты скрываются в адресе(0), _dodoApproveAddress, _uniswapV3Factorty?
Вторая сцена
Давайте сначала взглянем на адрес злоумышленника 3 (0x bf…87), который похитил 73,49 WETH тем же методом:
Атакуйте исходный адрес газа (0x 97…de) и предоставьте комиссию за обработку как 0x c 5…0 d (адрес злоумышленника 2), так и 0x bf…87 (адрес злоумышленника 3).
Источником 0,1 ETH, который атакует адрес источника газа (0x 97…de), является owlto.finance (мост между цепочками).
0x c 5…0 d (адрес злоумышленника 2) после получения платы за обработку не осуществил никакой атаки, но на самом деле взял на себя скрытый план. Давайте продолжим его рассматривать.
На самом деле, согласно официальной спасательной транзакции, исходный адрес поврежденного контракта (0x 29…1 F) был не просто 73,49 WETH: до конца атаки все еще оставалось 7276,5 WETH и 7758267 USDB.
Спасательная сделка:
Злоумышленник изначально планировал украсть эти активы.Вы можете видеть, что адрес 0x c 5…0 d (адрес злоумышленника 2) изначально использовался для кражи USDB.
_dodoApproveAddress здесь равен 0x0000000000000000000000004300000000000000000000000000000000000003
это адрес usdb
0x bf…87 (адрес злоумышленника 3). Этот адрес используется для кражи данных:
Фабрика _uniswap V3 здесь: 0x000000000000000000000000430000000000000000000000000000000000004
это адрес Wet
А 0x 6 e…c 5 (адрес злоумышленника 1) отвечает за кражу адреса (0), который является собственным активом ETH.
Установив поле 0, злоумышленник может украсть соответствующие активы с помощью следующей логики:
вопрос
Почему злоумышленник не украл все активы?
Теоретически он может украсть все активы, а именно оставшиеся WETH и USDB.
0x bf…87 (адрес злоумышленника 3) украл только 73,49 WETH. 0x bf…87 (адрес злоумышленника 3) фактически может забрать все 7350 WETH, или вы можете использовать 0x c 5…0 d (адрес злоумышленника 2) взял прочь все 7758267 USDB. Почему он остановился после того, как взял немного WETH? Мы не знаем. Возможно, потребуется известный сетевой детектив для проведения углубленного внутреннего расследования.
Почему злоумышленник не перевел 17413 ETH в сеть Ethereum?
Как мы все знаем, основная сеть Blast может перехватить эти ETH централизованным методом и оставить их здесь навсегда, не вызывая существенных потерь пользователей. Однако, как только эти ETH попадут в основную сеть Ethereum, способа перехватить не будет. это.
Мы оценили текущие перекрестные мосты Blast. Ограничений на количество официальных перекрестных мостов нет, но для их выхода требуется 14 дней, чего чиновникам Blast достаточно для подготовки плана перехвата.
Сторонний кросс-чейн мост может быть зачислен почти в реальном времени, как и источник комиссий злоумышленника, и может быстро завершить кросс-чейн. Почему злоумышленник не выполнил кросс-чейн сразу?
Фактически злоумышленник осуществил перекрестную цепочку в первый момент (в течение 2 минут после атаки):
Более того, для поступления средств в основную сеть Ethereum потребовалось 20 секунд.Теоретически злоумышленник может продолжать перекрестную цепочку и передавать большое количество ETH между цепочками до ручного вмешательства с помощью межцепочного моста.
Что касается того, почему одновременно может быть только 3 ETH, то причина в лимите ликвидности кроссчейн-моста, от Blast до ETH:
Другой кросс-чейн мост, поддерживающий Blast, поддерживает еще меньше:
После этой кроссчейн транзакции злоумышленник не продолжил другие кроссчейн операции. Причина нам неизвестна. Судя по всему, “хакер из определенной страны” не провел должной подготовки к выводу средств из Blast.
Развитие событий после атаки
Основываясь на отзывах пользователя сообщества Nearisbuilding, он нашел дополнительную информацию о личности злоумышленника и нашел способы побудить злоумышленника вернуть средства.
В конце концов, благодаря вниманию и усилиям сообщества шифрования, «хакер из определенной страны», возможно, потому, что он боялся раскрыть свою личность, предоставил участникам проекта закрытые ключи трех вышеупомянутых адресов злоумышленников и вернул все Сторона проекта также провела спасательную транзакцию: перевела все средства из поврежденного контракта в контракт с мультиподписью на хранение.
