фон
Blast — це мережа Ethereum рівня 2, запущена Pacman (Tieshun Roquerre, він же Tieshun), засновником Blur. Вона запустила основну мережу 29 лютого. Наразі приблизно 19 500 ETH і 640 000 stETH залучено в основну мережу Blast.
Атакований проект Munchables — високоякісний проект, який переміг у конкурсі Bigbang, організованому Blast.
Представники Blast нараховуватимуть звичайні бали користувачам, які внесуть ETH у мережу Blast:
Щоб заохотити користувачів брати участь у проектах DeFi в екосистемі Blast, офіційні особи Blast вибиратимуть високоякісні проекти для рекомендацій і заохочуватимуть користувачів вдруге внести ETH у DeFi, щоб отримати швидший приріст балів і золотих балів, тому є досить Кілька користувачів пообіцяли ETH, покладені на основну мережу Blast, новоствореному проекту DeFi.
Зрілість і безпеку цих проектів DeFi ще належить дослідити, а також чи мають ці контракти достатні міркування щодо безпеки, щоб захистити десятки мільйонів або навіть сотні мільйонів доларів.
Огляд події
Менш ніж через місяць після того, як основна мережа Blast вийшла в Інтернет, 21 березня 2024 року сталася атака на токен SSS (Super Sushi Samurai). У контракті токена сталася логічна помилка передачі, яка дозволила зловмиснику збільшити токен SSS токена зазначений обліковий запис на порожньому місці, проект зрештою втратив понад 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 дні до атаки). Тобто до цього інциденту логічний контракт став контрактом без бекдорів. Чому? Чи може зловмисник все одно завершити напад?
Це відбувається через delegatecall, тому фактичне оновлення сховища стану міститься в контракті (0x 16…A 0), що призводить до того, що навіть якщо логічний контракт пізніше оновлюється до логічного контракту без бекдору 0x і 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 тут 0x000000000000000000000000430000000000000000000000000000000000000003
це адреса usdb
0x bf…87 (адреса зловмисника 3) Ця адреса використовується для крадіжки weth:
Фабрика _uniswap V3 тут 0x00000000000000000000000430000000000000000000000000000000000004
це адреса 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 хвилин атаки):
Крім того, знадобилося 20 секунд, щоб кошти надійшли в основну мережу Ethereum.Теоретично зловмисник може продовжувати крос-чейн і передавати велику кількість ETH між ланцюжками, перш ніж крос-чейн-міст зможе вручну втрутитися.
Щодо того, чому це може бути лише 3 ETH за раз, причина полягає в обмеженні ліквідності перехресного мосту, від Blast до ETH:
Інший перехресний міст, який підтримує Blast, підтримує ще менше:
Після цієї міжланцюжної транзакції зловмисник не продовжував інші міжланцюгові операції. Причина нам невідома. Схоже, що «хакер з певної країни» не зробив належної підготовки до виведення коштів з Blast.
Розвиток подій після нападу
На основі відгуків користувача спільноти Nearisbuilding він знайшов більше інформації про особу зловмисника та знайшов способи спонукати зловмисника повернути кошти.
Зрештою, з увагою та зусиллями спільноти шифрувальників, «хакер з певної країни», можливо тому, що боявся розкрити свою особу, надав особисті ключі трьох вищевказаних адрес зловмисника стороні проекту та повернув усі кошти Сторона проекту також провела операцію порятунку Перевести всі кошти з пошкодженого контракту на мультипідписний контракт на зберігання.
