Ви не купували rsETH, але ваш WETH був заморожений

Вступ

Ключові моменти:

  • У період з 13 по 19 квітня 2026 року зафіксовано чотири випадки атак, що стосуються кількох блокчейнів, таких як Ethereum, Unichain, Arbitrum та NEAR, з загальними збитками приблизно $310М.

  • Вектори атак включають отруєння RPC інфраструктури для LayerZero DVN, підробку MMR доказів, зловживання знаковими цілими числами у страховому фонді, а також використання циклічних шляхів обміну у протоколах маржинальної торгівлі.

  • Інцидент KelpDAO (збитки $290М) показує, що безпека міжланкових мостів вже виходить за межі смарт-контрактів і поширюється на інфраструктуру офлайн-верифікації. Водночас, каскадне блокування WETH на п’яти ланцюгах та примусове переключення стану Arbitrum додатково демонструють, як комбінація може посилювати єдину точку відмови та визначати реальні межі довіри у “децентралізованих” системах.

За минлий тиждень (13.04.2026 - 19.04.2026) BlockSec виявила та проаналізувала чотири інциденти, загальні збитки яких оцінюються приблизно у $310М. Нижче наведено їх короткий огляд, а у наступних розділах буде детальний аналіз кожного з них.

Таблиця 1: Огляд виявлених цього тижня чотирьох атак

Головні події тижня: KelpDAO

Цей інцидент обрано як головний через його новий рівень інфраструктурних векторів атаки (отруєння RPC для унікального DVN, а не вразливості смарт-контрактів), каскадний вплив через DeFi-комбінованість та проблеми управління, викликані примусовим переключенням стану Arbitrum для повернення викрадених коштів.

18 квітня 2026 року було здійснено атаку на міжланковий міст rsETH LayerZero OFT KelpDAO, внаслідок якої було викрадено близько $290М. LayerZero Labs пояснили цю атаку як результат державної підтримки з боку атакуючих, ймовірно, з Північної Кореї, група Lazarus [1]. Основна причина — конфігурація DVN KelpDAO у режимі 1-із-1, що зводить перевірку міжланкових повідомлень до єдиного вузла, що є вразливим. Атакуючий отруїв RPC інфраструктуру, довірену LayerZero Labs DVN, змусивши її підписати підроблене міжланкове повідомлення, що призвело до випуску 116,500 rsETH на Ethereum, хоча у джерельному Unichain не було відповідних вихідних подій.

Контекст

LayerZero — протокол міжланкових повідомлень на модульній архітектурі безпеки. Його ядро — цілісність міжланкових повідомлень, забезпечена децентралізованою мережею валідаторів (DVN), що є офлайн-об’єктами, відповідальними за незалежну перевірку повідомлень з джерельного ланцюга перед їхньою обробкою у цільовому. Кожен застосунок, розгорнутий на LayerZero, налаштовує DVN самостійно, визначаючи довірених валідаторів, кількість учасників та поріг консенсусу. Це дає застосункам повний контроль над моделлю безпеки, але і повну відповідальність: слабка конфігурація не може бути компенсована протоколом.

rsETH KelpDAO — це OFT (загальноланкова замінна токен), розгорнутий на LayerZero, що з’єднує Unichain (джерельний ланцюг) та Ethereum Mainnet (цільовий). Стандарт OFT дозволяє знищувати токени у джерелі та відновлювати їх у цілій мережі, а міжланкове повідомлення — єдиний дозвіл на таку операцію. Адаптер Ethereum (0x85d456…e98ef3) відповідає за випуск rsETH після перевірки та передачі міжланкового повідомлення. Важливо, що KelpDAO налаштував цю схему у режимі 1-із-1, довіряючи лише LayerZero Labs як єдиному валідатору. Це означає, що один доказ DVN достатній для авторизації будь-якого випуску токенів без додаткового підтвердження.

Для виконання перевірки LayerZero Labs DVN запитує кілька RPC вузлів, щоб підтвердити факт вихідної події у джерельному ланцюгу. Ці вузли — як власна інфраструктура, так і сторонні провайдери, і довіра до їхньої відповіді лежить у основі цілісності процесу.

Аналіз вразливості

Ця уразливість — системна помилка інфраструктури та конфігурації, що складається з трьох слабких ланок.

Перша — конфігурація DVN 1-із-1 у KelpDAO усуває будь-яке резервування на рівні перевірки. Рекомендована LayerZero безпекова конфігурація вимагає множинних DVN та незалежних валідаторів, щоб жоден один DVN не міг самостійно авторизувати повідомлення. Обмеження — залежність від єдиного DVN, що уразливий до компрометації.

Друга — механізм аварійного перемикання DVN, що маршрутує запити до будь-якого доступного RPC. Це передбачає, що збої — випадкові, а не цілеспрямовані. Однак, це створює ситуацію, коли атакуючий може, наприклад, DDoS-атаками вивести з ладу здорові вузли і підмінити їх на отруєні, отримуючи повний контроль над даними DVN.

Третя — заміна файлу op-geth на сервері RPC вимагає доступу до ОС сервера. Точний вектор початкового проникнення не розкрито, але компрометація двох вузлів на окремих кластерах вказує на спільні слабкості у системах безпеки.

Ці три слабкості разом формують повний ланцюг атаки: перша — відсутність резервування валідаторів, друга — можливість контролювати дані через DDoS і отруєні вузли, третя — можливість підміни файлу для маніпуляції даними. Жодна з них сама по собі не достатня, але разом вони дозволяють атакуючому повністю контролювати процес.

Аналіз атаки

Аналіз базується на транзакції 0x1ae232…4222 та офіційних заявах LayerZero Labs.

Крок 1: Атакуючий отримує список RPC вузлів, довірених LayerZero Labs DVN. Це цінна інформація, оскільки знання точних вузлів дозволяє планувати цілеспрямовані атаки, а не масові.

Крок 2: Атакуючий отримує права запису на два RPC вузли і замінює їхні бінарні файли op-geth на зловмисні версії. Вони працюють на окремих кластерах, що натякає на спільний вектор проникнення — наприклад, компрометація ключів, CI/CD, або соціальний інженіринг.

Крок 3: Зловмисний файл реалізує цілеспрямовану логіку відповіді: повертає підроблені дані транзакцій лише для IP DVN, тоді як для інших — реальні дані блокчейну. Це робить отруєння невидимим для систем моніторингу.

Крок 4: Внутрішній консенсус DVN вимагає згоди між отруєними та неотруєними вузлами. Для вирішення конфлікту атакуючий запускає DDoS-атаки на здорові вузли у проміжок з 10:20 до 11:40 за тихоокеанським часом, що викликає перехід DVN у режим аварійного перемик

Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • Прокоментувати
  • Репост
  • Поділіться
Прокоментувати
Додати коментар
Додати коментар
Немає коментарів
  • Закріпити