фон

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 в контракте проекта также были украдены хакером с другого адреса.

В настоящее время на контрактном адресе участника проекта все еще хранятся 7 276 WETH, 7 758 267 USDB и 4 ETH, которые могут попасть в руки хакеров в любой момент. Хакер имеет право забрать все средства Весь проект общей стоимостью около 97 миллионов долларов США подвержен риску.

Сразу после инцидента ZachXBT, известный сетевой детектив X (Twitter), указал, что первопричиной этой атаки стал найм хакеров из определенной страны.

Давайте подробнее рассмотрим, как «хакер из одной страны» осуществил атаку стоимостью почти 100 миллионов долларов.

Реставрация на месте

[UTC+0] В 21:37 26 марта 2024 года (через 5 минут после атаки) Munchables официально разместил в X (Twitter) сообщение о том, что он подвергся атаке.

По данным расследования онлайн-детектива Зака ​​Злоумышленник пришел заняться разработкой игр. Он был очень груб и действительно выглядел как китайский хакер. Мы уволили его в течение месяца. Он также пытался заставить нас нанять одного из своих друзья, который, вероятно, тоже был хакером. хакером».

Поскольку эта атака нанесла огромный ущерб пользователям в сообществе, мы немедленно начали расследование в сети.Давайте подробно рассмотрим детали атаки этого «хакера из определенной страны».

[UTC+0] 26 марта 2024 года в 21:32 произошла атака с использованием 17413,96 ETH.

Мы можем увидеть эту транзакцию атаки через Blastscan: https://blastscan.io/tx/0x9a7e4d16ed15b0367b8ad677eaf1db6a2a54663610696d69e1b4aa1a08f55c95.

Поврежденный контракт (0x29..1F) представляет собой прокси-контракт, в котором хранятся заложенные пользователем средства. Мы видим, что злоумышленник вызвал функцию разблокировки контракта залога, прошел все проверки разрешений и перевел средства в контракте. Все ETH на адрес злоумышленника 1 (0x6E..c5).

Похоже, что злоумышленник вызвал функцию разблокировки, аналогичную поведению при снятии средств, и забрал большую часть ETH на поврежденном контракте (0x29..1F).

Участники проекта забыли запереть хранилище?

В поврежденном контракте (0x29..1F) есть две связанные проверки на разблокировку, рассмотрим их поочередно.

Во-первых, мы обнаружили, что в процессе проверки разрешений вызывался метод контракта isRegistered (0x16..A0), чтобы проверить, зарегистрирован ли текущий msg.sender, то есть хакерский адрес 1 (0x6E..c5). :

Ответ: прошел проверку.

Это включает в себя контракт (0x16..A0) и соответствующий ему последний логический контракт (0xe7..f1).

[UTC+0] В 08:39 24 марта 2024 года (за 2 дня до атаки) был обновлен логический контракт, соответствующий контракту (0x16..A0).

Логическая транзакция обновления контракта:

https://blastscan.io/tx/0x9c431e09a80d2942319853ccfdaae24c5de23cedfcef0022815fdae42a7e2ab6

Логический контракт обновляется до 0xe7..f1.

Здесь можно увидеть исходный логический адрес контракта: 0x9e..CD.

https://blastscan.io/tx/0x7ad050d84c89833aa1398fb8e5d179ddfae6d48e8ce964f6d5b71484cc06d003

На данный момент мы подозреваем, что хакер обновил контракт реализации логики прокси-контракта и изменил 0x9e..CD на вредоносный 0xe7..f1, завершив обход разрешений проверки.

Это правда?

В Web3.0 вам никогда не придется гадать или слушать других, вам нужно лишь освоить технологию, чтобы получить ответ самостоятельно.

Сравнивая два контракта (не контракты с открытым исходным кодом), мы обнаружили некоторые очевидные различия между исходным контрактом 0x9e..CD и обновленным контрактом 0xe7..f1:

Функциональная часть инициализации 0xe7..f1 реализована следующим образом:

Функциональная часть инициализации 0x9e..CD реализована следующим образом:

Видно, что злоумышленник установил адрес злоумышленника (0x6e..c5) в качестве регистра в исходном логическом контракте (0x9e..CD), а также есть два других адреса злоумышленника: 0xc5..0d и 0xbf..87. были зарегистрированы, и их поле 0 установлено на время блока при инициализации. Использование поля 0 будет объяснено позже.

На самом деле, вопреки тому, что мы предполагали, настоящий логический контракт с бэкдором существовал с самого начала, и последующие обновления были нормальными!

Подождите, это обновление появилось в 08:39 24 марта 2024 года [UTC+0] (за 2 дня до атаки).То есть до этого инцидента логический контракт стал контрактом без бэкдоров.Почему?Может ли злоумышленник выполнить нападение позже?

Это происходит из-за вызова делегата, поэтому фактическое обновление хранилища состояния находится в контракте (0x16..A0), что приводит к тому, что даже если логический контракт позже обновляется до логического контракта 0xe7..f1 без бэкдора, контракт (0x16..A0) все равно не будет восстановлен.

Давайте проверим это:

Видно, что соответствующий слот в контракте (0x16....A0) имеет числовое значение.

Это позволяет злоумышленнику пройти проверку метода isRegistered:

Позже злоумышленник меняет контракт бэкдора на обычный контракт, чтобы скрыть тот факт, что бэкдор уже установлен.

Кроме того, процесс разблокировки также предполагает повторную проверку:

Что касается проверки времени блокировки, эта часть призвана гарантировать, что заблокированные активы не будут переданы до истечения срока действия.

Злоумышленнику необходимо убедиться, что время блокировки при вызове разблокировки превышает требуемое время истечения срока действия блокировки (поле3).

Эта часть проверки включает поврежденный контракт (0x29..1F) и соответствующий логический контракт 0xf5..cd.

В транзакции в 11:54 21 марта 2024 г. [UTC+0] (за 5 дней до атаки):

https://blastscan.io/tx/0x3d08f2fcfe51cf5758f4e9ba057c51543b0ff386ba53e0b4f267850871b88170

Мы видим, что исходный логический контракт поврежденного контракта (0x29..1F) был 0x91..11, и всего четыре минуты спустя, в

https://blastscan.io/tx/0xea1d9c0d8de4280b538b6fe6dbc3636602075184651dfeb837cb03f8a19ffc4f

Был обновлен до 0xf5..cd.

Мы также сравниваем два контракта и видим, что злоумышленник, как и раньше, также использовал трюки в функции инициализации.

Частичная реализация функции инициализации 0xf5..cd:

Был обновлен до 0xf5..cd.

Мы также сравниваем два контракта и видим, что злоумышленник, как и раньше, также использовал трюки в функции инициализации.

Частичная реализация функции инициализации 0xf5..cd:

Частичная реализация функции инициализации 0x91..11:

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

На данный момент мы понимаем эту транзакцию с участием 17413 ETH и то, как злоумышленник это сделал, но стоит ли за этим инцидентом столько информации?

В нашем приведенном выше анализе мы фактически увидели, что хакер встроил в контракт 3 адреса:

0x6e..c5 (адрес злоумышленника 1)

0xc5..0d (адрес злоумышленника 2)

0xbf..87 (адрес злоумышленника 3)

Однако в транзакции атаки, которую мы нашли выше, мы видели только 0x6e..c5.Что делали два других адреса? А какие секреты скрываются в адресе(0), _dodoApproveAddress и _uniswapV3Factorty?

Давайте сначала взглянем на адрес злоумышленника 3 (0xbf..87), который похитил 73,49 WETH тем же методом:

https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233

Атакуйте исходный адрес газа (0x97..de) и предоставьте комиссию за обработку как 0xc5..0d (адрес злоумышленника 2), так и 0xbf..87 (адрес злоумышленника 3).

Источником 0,1 ETH, который атакует адрес источника газа (0x97..de), является owlto.finance (мост между цепочками).

0xc5..0d (адрес злоумышленника 2) не осуществил никакой атаки после получения платы за обработку, но на самом деле взял на себя скрытый план.Давайте продолжим его рассматривать.

На самом деле, согласно официальной транзакции после спасения, исходный адрес поврежденного контракта (0x29..1F) был не просто 73,49 WETH: до конца атаки еще оставалось 7276,5 WETH и 7758267 USDB.

На самом деле, согласно официальной транзакции после спасения, исходный адрес поврежденного контракта (0x29..1F) был не просто 73,49 WETH: до конца атаки все еще оставалось 7276,5 WETH и 7758267 USDB.

Спасательная сделка:

https://blastscan.io/tx/0x1969f10af9d0d8f80ee3e3c88d358a6f668a7bf4da6e598e5be7a3407dc6d5bb

Первоначально злоумышленник планировал украсть эти активы.Вы можете видеть, что адрес 0xc5..0d (адрес злоумышленника 2) изначально использовался для кражи USDB.

_dodoApproveAddress здесь равен 0x000000000000000000000000430000000000000000000000000000000000003

это адрес usdb

0xbf..87 (адрес злоумышленника 3). Этот адрес используется для кражи:

0xbf..87 (адрес злоумышленника 3). Этот адрес используется для кражи:

_uniswapV3Factory здесь — 0x00000000000000000000000430000000000000000000000000000000000004

это адрес Wet

А 0x6e..c5 (адрес злоумышленника 1) отвечает за кражу адреса (0), который является собственным активом ETH.

Установив поле field0, злоумышленник может украсть соответствующие активы с помощью следующей логики:

вопрос

Теоретически он может украсть все активы, а именно оставшиеся WETH и USDB.

0xbf..87 (адрес злоумышленника 3) украл только 73,49 WETH. 0xbf..87 (адрес злоумышленника 3) фактически может забрать все 7350 WETH. Вы также можете использовать 0xc5..0d (адрес злоумышленника 2) ) забрал все 7758267 USDB , почему он прекратился после принятия всего лишь небольшого количества WETH, мы не знаем. Возможно, для проведения углубленного внутреннего расследования может потребоваться известный сетевой детектив.

0xbf..87 (адрес злоумышленника 3) украл только 73,49 WETH. 0xbf..87 (адрес злоумышленника 3) фактически может забрать все 7350 WETH. Вы также можете использовать 0xc5..0d (адрес злоумышленника 2) ) забрал все 7758267 USDB , почему он прекратился после принятия всего лишь небольшого количества WETH, мы не знаем. Возможно, для проведения углубленного внутреннего расследования может потребоваться известный сетевой детектив.

https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233

Как мы все знаем, основная сеть Blast может перехватить эти ETH централизованным методом и оставить их здесь навсегда, не вызывая существенных потерь пользователей. Однако, как только эти ETH попадут в основную сеть Ethereum, способа перехватить не будет. это.

Мы оценили текущий перекрестный мост Blast. Ограничений на количество официальных перекрестных мостов нет, но для выхода из него требуется 14 дней, чего достаточно чиновникам Blast для подготовки плана перехвата.

Сторонний кросс-чейн мост может быть зачислен почти в реальном времени, как и источник комиссий злоумышленника, и может быстро завершить кросс-чейн. Почему злоумышленник не выполнил кросс-чейн сразу?

Фактически злоумышленник выполнил перекрестную цепочку в первый момент (в течение 2 минут после атаки):

https://blastscan.io/tx/0x10cf2f2b884549979a3a1dd912287256229458ef40d56df61738d6ea7d9d198f

Более того, для поступления средств в основную сеть Ethereum потребовалось 20 секунд.Теоретически злоумышленник может продолжать перекрестную цепочку и передавать большое количество ETH между цепочками, прежде чем межцепочный мост сможет вмешаться вручную.

Что касается того, почему одновременно может быть только 3 ETH, то причина в лимите ликвидности кроссчейн-моста, от Blast до ETH:

Что касается того, почему одновременно может быть только 3 ETH, то причина в лимите ликвидности кроссчейн-моста, от Blast до ETH:

Другой кросс-чейн мост, поддерживающий Blast, поддерживает еще меньше:

После этой кроссчейн транзакции злоумышленник не продолжил другие кроссчейн операции. Причина нам неизвестна. Судя по всему, «хакер из определенной страны» не провел должной подготовки к выводу средств из Blast.

Что произошло после нападения

Основываясь на отзывах пользователя сообщества Nearisbuilding, он нашел дополнительную информацию о личности злоумышленника и нашел способы побудить злоумышленника вернуть средства.

https://twitter.com/Nearisbuilding/status/1772812190673756548

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