21 червня один із найактивніших MEV-ботів на мережі Ethereum, Jaredfromsubway.eth, став жертвою добре спланованої «медовій ловушці» (honeypot attack) і втратив понад 7,5 мільйона доларів США в криптоактивах. Нижче наведено аналіз та відстеження потоків вкрадених коштів командою безпеки Beosin.
Аналіз процесу атаки
Атака на контрактний родину
- Координаторний контракт (0xb84db016324e8f2bfdd8dd9c260338aee0a8df52): відповідає за реєстрацію того, чи перебуває поточний блок у стані armed, та циклічно викликає дочірні контракти на етапі фінального вилучення коштів. - Тригерний контракт (0x4de8c729a064ff6087cc84a4152969349e4feb98): відповідає за налаштування фальшивого стану торгової пари в межах того ж блоку, щоб зробити шлях арбітражу видимим як виконуваний. - Дочірні контракти / фальшиві токени: маскуються під нормальні ERC-20 токени для отримання справжніх авторизацій. - Hub-контракт: відповідає за сплату невеликої реальної прибутковості, щоб MEV Bot вважав його вигідним. - Ring V2 pair: фальшива торгова пара Uniswap v2. - Фальшивий проміжний токен: використовується для побудови багатоетапних арбітражних шляхів, наприклад, fCAP, fUSDC.
Ключ до атаки: обманна авторизація
Аналізуючи ланцюгові транзакції, нападник створив кілька груп навідних транзакцій:
- Великі USDC: робот заробив приблизно 36,997120 USDC, але залишив 20 USDC у авторизації. - Великі USDT: робот заробив приблизно 37,053440 USDT, але залишив 20 USDT у авторизації. - Великі WETH: робот заробив приблизно 0,0179 WETH, але залишив 16 WETH у авторизації. - Малі угоди працюють нормально: авторизація споживається в межах однієї угоди для зменшення підозрілості.
Під час мінімальних угод, після того як робот авторизує справжні токени, дочірній контракт миттєво переказує справжні токени, авторизація витрачається, і все виглядає абсолютно нормально.
У великих транзакціях дочірній контракт не викликає transferFrom для переказу справжніх токенів, а замість цього безпосередньо створює підроблені токени шляхом підробки транзакцій. Робот вважає, що він завершив звичайний передній крок swap, але справжнє дозвіл на токени залишається збереженим.
Ось суть всієї атаки: дрібні транзакції нормально витрачають авторизацію, а величезні транзакції зберігають авторизацію.
Процес атаки
Наприклад, атакувальна угоду з USDC:
(1) Зловмисник викликає координатора, щоб встановити поточний блок у стан armed. (2) Зловмисник викликає тригер, щоб оновити стан кількох підроблених пар Ring V2. (3) MEV-бот виявляє арбітражну можливість і виконує угоду.
Механізм роботи MEV-бота виглядає так:
(1) Контракт MEV Bot надав велику кількість USDC у повноваження підконтракту (2) MEV Bot викликав функцію wrapTo/wrap підконтракту (3) Оскільки поточний стан підконтракту — armed, реальні USDC не споживаються, а замість цього створюються фальшиві токени для пари, а повноваження на USDC зберігаються (4) MEV Bot продовжує викликати обмін на фальшивій парі (5) Друга пара надсилає токени MEV Bot (6) Hub-контракт сплачує MEV Bot невеликий реальний прибуток у USDC
приклад схвалення
хеш транзакції: 0x0121e07a916c06eea3e7daf11893f3f0b95b9e1684124545ae14c32aee6029bb
Результат, який побачив MEV Bot: успішна арбітражна угоду з отриманням реального прибутку у USDC. Однак авторизація USDC була залишена підконтрактом. Цей процес був повторений окремо для USDC, USDT, WETH, що в результаті призвів до великої кількості авторизацій.
Хеш атаки на угоду:
0x2be8704f5a59b69e0b71f64aefdb99eb0e8ae9fb3926147c581910d71bcf3e65
Зловмисник викликає цикл витягування координаторського контракту, де calldata містить 66 адрес підконтрактів та адресу контракту MEV Bot. Якщо раніше контракт MEV Bot надав повноваження на ліміт підконтрактам, підконтракти можуть безпосередньо переказати відповідні реальні токени зловмиснику.
Остаточний результат:
- 20 USDC великих авторизацій повністю використано - 16 WETH великих авторизацій повністю використано - Частина авторизації USDT все ще існує, але баланс USDT недостатній
Аналіз руху коштів
Після успішної атаки адреса атакуючого (0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0) отримала $2,87M USDC, $2,04M 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, інші три адреси не здійснювали подальших переказів ETH. Графік руху коштів виглядає так:
Висновок
Ця атака демонструє високотехнологічний підхід: атакуючий не атакує безпосередньо код контракту, а, виходячи з логіки роботи MEV Bot, створює відповідні арбітражні сценарії, щоб ввести MEV Bot в оману і змусити його надати дозвіл, який здається безпечним, а потім переказати його активи. Для арбітражних роботів і MEV Bot не достатньо полагоджуватися лише на симуляції прибутку для оцінки безпеки маршруту, особливо коли в арбітражному шляху присутні невідомі контракти, підроблені токени або користувацькі обгортки — слід діяти обережно і розглянути можливість обов’язкової перевірки змін allowance після транзакції.