21 июня один из самых активных MEV-ботов в сети Ethereum, Jaredfromsubway.eth, стал жертвой тщательно спланированной «атаки honeypot», в результате которой было потеряно более 7,5 миллионов долларов в криптоактивах. Ниже представлен анализ данной атаки и отслеживание потока украденных средств от команды безопасности Beosin.
Анализ процесса атаки
Семейство атакующих контрактов
- Координатор контракта (0xb84db016324e8f2bfdd8dd9c260338aee0a8df52): отвечает за запись состояния текущего блока (armed) и на финальном этапе циклически вызывает дочерние контракты для извлечения средств.- Триггер контракта (0x4de8c729a064ff6087cc84a4152969349e4feb98): отвечает за установку поддельного состояния торговых пар в пределах того же блока, делая арбитражный путь выглядещим исполняемым.- Дочерние контракты / поддельные токен-контракты: маскируются под обычные токены ERC-20, чтобы получить реальные разрешения (allowances).- Hub-контракт: отвечает за выплату небольшой реальной прибыли, чтобы MEV-бот считал операцию выгодной.- Ring V2 pair: поддельная торговая пара Uniswap v2.- Поддельные промежуточные токен-контракты: используются для построения многошагового арбитражного пути, например, fCAP, fUSDC.
Ключ атаки: обманное получение разрешений (allowances)
Проанализировав транзакции в блокчейне, злоумышленник сконструировал несколько наборов приманных транзакций:
- Крупная сумма USDC: бот получил прибыль около 36.997120 USDC, но оставил разрешение на 20 USDC.- Крупная сумма USDT: бот получил прибыль около 37.053440 USDT, но оставил разрешение на 20 USDT.- Крупная сумма WETH: бот получил прибыль около 0.0179 WETH, но оставил разрешение на 16 WETH.- Мелкие транзакции выглядели нормально: разрешения (allowances) расходовались в рамках той же транзакции, чтобы снизить подозрения.
В мелких транзакциях после того, как бот выдавал разрешение на использование реальных токенов, дочерний контракт немедленно переводил эти реальные токены, разрешение расходовалось, и всё выглядело совершенно нормально.
В крупных транзакциях дочерний контракт не вызывал transferFrom для перевода реальных токенов, а вместо этого чеканил поддельные токены через сфабрикованные торговые пары. Бот думал, что выполнил обычные подготовительные шаги для обмена (swap), но реальное разрешение на использование токенов (allowance) оставалось сохранённым.
В этом и заключается суть всей атаки: мелкие транзакции нормально расходуют разрешения, крупные транзакции сохраняют разрешения.
Процесс атаки
В качестве примера рассмотрим атакующую транзакцию с USDC:
(1) Злоумышленник вызывает координатор, переводя текущий блок в состояние armed.(2) Злоумышленник вызывает триггер, обновляя состояние нескольких сфабрикованных торговых пар Ring V2.(3) MEV-бот обнаруживает арбитражную возможность и выполняет транзакцию.
Внутренний процесс транзакции MEV-бота выглядел примерно так:
(1) Контракт MEV-бота выдал крупное разрешение на использование USDC (allowance) одному из дочерних контрактов.(2) MEV-бот вызывает функцию wrapTo/wrap дочернего контракта.(3) Поскольку текущее состояние - armed, дочерний контракт не расходует реальные USDC, а вместо этого чеканит поддельные токены для торговой пары. Разрешение на использование USDC остается сохранённым.(4) MEV-бот продолжает вызов функции swap на поддельной торговой паре.(5) Вторая торговая пара отправляет токены MEV-боту.(6) Hub-контракт выплачивает MEV-боту небольшую реальную прибыль в USDC.
Пример approval (разрешения)
Хэш транзакции: 0x0121e07a916c06eea3e7daf11893f3f0b95b9e1684124545ae14c32aee6029bb
Что увидел MEV-бот: успешная арбитражная сделка, принесшая реальную прибыль в USDC. Однако разрешение на использование USDC (allowance) было сохранено дочерним контрактом. Эта схема была повторно выполнена для USDC, USDT, WETH, что в итоге привело к накоплению большого количества разрешений (allowances).
Хэш атакующей транзакции:
0x2be8704f5a59b69e0b71f64aefdb99eb0e8ae9fb3926147c581910d71bcf3e65
Злоумышленник вызывает функцию drain loop контракта-координатора, calldata содержит адреса 66 дочерних контрактов, а также адрес контракта MEV-бота. Если контракт MEV-бота ранее оставил для дочерних контрактов разрешения на использование средств (allowances), то дочерние контракты могут напрямую перевести соответствующие реальные токены злоумышленнику.
Итоговый результат:
- Полностью использованы все крупные разрешения на 20 USDC.- Полностью использованы все крупные разрешения на 16 WETH.- Часть разрешений для USDT всё ещё существует, но баланс USDT уже недостаточен.
Анализ движения средств
После успешной атаки адрес злоумышленника (0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0) получил $2.87 млн USDC, $2.04 млн USDT и 1,474 WETH. Затем злоумышленник обменял стейблкоины на ETH и перевёл их на следующие 4 адреса:
- 0xe3Da36E4bd1a5738fa5D6Ef4F0e4dF40bDeB5f17 (около 1,000 ETH)- 0x74Dc5b93586D248D5Aec64b3586736FF0A0D0e65 (1,001 ETH)- 0xd8C125efCBc99408eC8723E9BBd81d1E8D39D845 (1,001 ETH)- 0x71d4416A7A85e08a5Fe7227Ca3B44Fc639e94e97 (1,423 ETH)
Из них 0xe3Da3 уже перевел 1,000 ETH в Tornado Cash, средства на трёх других адресах далее не перемещались. График движения средств представлен ниже:
Заключение
Данная атака демонстрирует высокоточный метод: злоумышленник не атакует код контракта напрямую, а на основе бизнес-логики MEV-бота, конструируя соответствующий арбитражный сценарий, вводит MEV-бота в заблуждение, заставляя его выдавать на первый взгляд безобидные разрешения (allowances), а затем переводит его активы. Для арбитражных ботов и MEV-ботов недостаточно полагаться только на симуляцию прибыли для оценки безопасности маршрута. Особенно когда в арбитражном пути присутствуют незнакомые контракты, поддельные токены или пользовательские обёртки (wrappers), следует проявлять осторожность и, возможно, принудительно проверять изменения в разрешениях (allowances) после транзакции.
Читать оригинал статьи
