Що трапилося під час атак NEAR Intents?
NEAR Intents втратив приблизно $3.8M у USDT на BNB Chain після того, як зловмисники експлуатували баг у взаємодії між інфраструктурою Omni для депозитів і виводів та смарт-контрактом NEAR Intents. Витік був помітний ще до публічного розголосу, тоді як NEAR Intents припинив обслуговування, виправив проблему на стороні контракту та повідомив, що постраждалі користувачі отримають повне відшкодування.
На блокчейні активність показує, що під час дня 30 вересня у схему витоку потрапили невеликі трансфери по 10 USDT та 11 USDT. Ці малі перекази узгоджуються з фазою валідації, коли зловмисник тестує, чи поведінка виводу, обліку або випуску відповідає очікуванням, перед тим як почати більш масштабні операції.
Після цього з 23:54 UTC 30 вересня до 06:08 UTC 1 жовтня було зроблено п’ять більших переказів, що коливалися від приблизно $35 000 до $1.5M кожен. За оцінками експертів з безпеки, збитки склали $3.865M з “гарячого” гаманця BNB Smart Chain, тоді як окремий блокчейн-аналіз показав близько 3.87 мільйонів USDT, що були зібрані із витоку контракту.
NEAR Intents публічно повідомив про витік приблизно о 12:53 UTC 1 жовтня. Протокол заявив, що обслуговування зупинено після того, як SHIELD виявив підозрілу активність, а проблема на стороні контракту була виправлена приблизно за годину. Очікувалося, що депозити і виводи по 11 мережах залишаться недоступними ще приблизно 12 годин, доки інфраструктура буде відновлена.
| Етап інциденту | Дата або час | Конкретна подія | Важливість для безпеки |
|---|---|---|---|
| Початкові перевірки | 30 вересня, після обіду за часом US Eastern | З витоку зникли 10 USDT і 11 USDT з контракту BNB Chain | Малі перекази можуть показати, чи доступний шлях випуску для експлуатації |
| Початок основного витоку | 30 вересня, 23:54 UTC | Почався перший із п’яти більших переказів | Експлуатація перейшла від тестування до масштабного витягу |
| Завершення основного витоку | 1 жовтня, 06:08 UTC | Завершився п’ята більша переказа | Період витоку триваний кілька годин |
| Публічне розголошення | 1 жовтня, близько 12:53 UTC | NEAR Intents повідомляє про зупинку сервісів і баг у взаємодії контракту з інфраструктурою | Повідомлення про інцидент слідувало за витоком на блокчейні |
| Оголошення терміну повернення | 2 жовтня, 00:18 UTC | Надано 48-годинний термін для повернення коштів | Строк приблизно закінчився о 00:18 4 жовтня |
Зазначений публічно активований актив — USDT на BNB Chain. Це важливо, оскільки розділяє інцидент із додатком та інфраструктурою моста від компрометації основної мережі NEAR або загального провалу всіх активів NEAR Intents.
NEAR Intents обробив понад $30B через близько 35 блокчейнів, при цьому панель показує обсяг у $31.4B за всі часи станом на 22 вересня. Такі масштабні системи потребують не лише безпечних смарт-контрактів, а й узгоджених умов стану між ланцюгами, операторами мостів, контрактами врегулювання, системами моніторингу та процедурами оперативної зупинки.
Як NEAR Intents зазвичай переміщує активи між ланцюгами?
NEAR Intents узгоджує результати міжланцюгових операцій через свій intents.near Verifier контракт, який зберігає реєстр депозитних балансів, оновлює їх при обмінах і випускає токени тільки через pathways виводу та мосту. Вразливість існувала у межі, де інфраструктура депозитів та виводів взаємодіяла з цим рівнем врегулювання.
Користувач NEAR Intents підписує запланований результат, а не прямо визначає кожен крок виконання. Решту і маркетмейкери змагаються за виконання цього результату, і обраний результат фіксується на блокчейні. Модель може підвищити ефективність міжланцюгового виконання, але також поширює поверхню довіри та верифікації: реєстр врегулювання має правильно розпізнавати, що було депоновано, обміняно й що можна вивести.
Документація NEAR Intents ідентифікує три системи мосту з різними моделями довіри:
- Omni Bridge, яким керує Near One.
- POA Bridge.
- HOT Bridge.
Дизайн HOT Bridge особливо важливий для аналізу інциденту, оскільки публічний аналіз визначив витік із контракту BNB Chain як адресу казначейства HOT Bridge, вказану в документації NEAR Intents, а не основний сейф NEAR Intents. Це — аналіз, а не остаточне виведення причин, і станом на 2 жовтня NEAR Intents не підтвердив, яка компонента зазнала збою.
У Hot Bridge контракти-локери на кожному підтримуваному ланцюгу зберігають рідні активи. Контракт на NEAR створює відповідні omni-токени у співвідношенні 1:1. Підпис MPC авторизують депозити та виводи, а кожен nonce має бути одноразовим.
Ця архітектура має кілька незмінних безпекових властивостей:
- Вивід на BNB Chain має відповідати реальному блокуванню, дебету або врегулюванню.
- Повідомлення про депозит не має бути повторно використане після виконання.
- Підпис має бути підтверджений щодо конкретного ланцюга, активу, адресата, суми і nonce.
- Запит на вивід не має бути прийнятий лише через те, що зовнішній компонент стверджує його валідність.
- Баланс казначейства повинен постійно узгоджуватися з реєстром та станом мосту.
У нашому досвіді аудиту смарт-контрактів у Soken найнебезпечнішими збої мостів трапляються на межах системи. Контракт може правильно виконувати свої локальні правила, але все одно випускати активи через те, що вхідне повідомлення, сервіс поза мережею або припущення обліку було прийнято без достатньої незалежної перевірки.
Перелічені 11 мереж були зупинені і відповідали списку HOT Bridge згідно документації NEAR Intents: BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll та Plasma. Ethereum, Base, Arbitrum, Solana і Bitcoin не були зупинені. Ці списки підтверджують гіпотезу зосередженість на HOT Bridge, але не доводять, яка саме компонента є вразливою.
Що відомо про баг і що залишилося невідомим?
NEAR Intents підтвердив, що виявлено баг у взаємодії між інфраструктурою Omni для депозитів і виводів і смарт-контрактом NEAR Intents, але точної компоненти або класу уразливості станом на 2 жовтня не розголошували. Твердження, що проблема була точною обходом підпису, багом повторного застосування, обліковою помилкою або компрометацією валідатора, виходить за межі доступних доказів.
Ключове слово — “взаємодія”. Це натякає, що уразливість не обов’язково полягає у простому ізольованому дефекті в одній функції контракту. Системи міжланцюгового обміну часто дають збій, коли дві розумні частини, що здаються разом цілком прийнятними, сперечаються щодо значення, остаточності або унікальності станового переходу.
Наприклад, шлях випуску на мосту може зазнати збою, якщо компонента поза мережею видає дозвіл на подію, яка так і не стала остаточною, або якщо контракт приймає повідомлення про вивід без його негайного споживання, або якщо обліковий шар зараховує баланс, якого фактично джерельний locker ще не отримав. Це різні технічні механізми, але вони поділяють однакову проблему безпеки: активи випускаються без еквівалентно заблокованого активу або валідного дебету.
Подія NEAR Intents має схожу структуру з кількома великими інцидентами мостів, але залишається відмінною у деталях підтверджених відомостей.
| Інцидент | Дата | Повідомлені збитки | Підтверджена модель несправності |
|---|---|---|---|
| Wormhole | Лютий 2022 | Близько $325М | Баг у перевірці підпису дозволив підробити схвалення guardian та створити 120 000 wETH без колатералі |
| Nomad | Серпень 2022 | Близько $190М | Оновлення встановило довірений корінь нульовим, змусивши кожне повідомлення бути обробленим як підтверджене |
| Kelp DAO через LayerZero | квітень 2026 | Близько $292М-$293М | Конфігурація 1-до-1 дозволила phantom burn випустити кошти на Ethereum |
| Liquid Network | 6 вересня 2026 | Близько $320М | Баг у кеші перевірки range-proof дозволив прив’язати непідтверджений L-BTC до реальних BTC |
| NEAR Intents | 1 жовтня 2026 | Орієнтовно $3.8М | Підтверджений баг у взаємодії інфраструктури для депозитів і виводів з смарт-контрактом NEAR Intents |
Wormhole, Nomad, Kelp DAO і Liquid Network мають спільний патерн несправностей у зоні випуску: міст прийняв кредит, доказ або повідомлення, що не відповідає реальному блокуванню або дебету. NEAR Intents ще не підтвердив, що 1 жовтня експлойтистова дія базувалася на цьому ж механізмі, але контекст мосту та казначейства робить цю інваріанту першою, яку слід досліджувати після розслідування.
Ronin Bridge — корисний контраст. Інцидент у березні 2022 року був викликаний компрометацією 5 із 9 ключів валідаторів. Це у першу чергу проблема управління ключами та порогових значень валідаторів, а не перебільшення контракту, що неправильно визнав підроблений кредит законним.
NEAR Intents пообіцяв додати формальну перевірку свого процесу випуску. Формальні методи особливо корисні тут, якщо використовувати їх для закодування invariants мосту безпосередньо: валідний вивід не може перевищувати врегульовану суму, повідомлення про вивід не може виконатися двічі, а сукупні випуски не можуть перевищувати підтверджену підтримку по всій системі мосту.
Для протоколів, що проектують подібну інфраструктуру, технічні аудити безпеки мають перевіряти весь життєвий цикл від депозиту до випуску, а не ізольовано кожен контракт, сервіс чи домен підписувача.
Чому відповіді та рішення з обмеження поширювалися?
NEAR Intents стримав інцидент, зупинивши сервіси після виявлення підозрілої активності SHIELD, швидко виправивши баг у взаємодії контракту з інфраструктурою приблизно за годину, та призупинивши депозити і виводи на 11 мережах. Швидке обмеження дозволяє зменшити масштаби витоку, але повне відновлення потребує трасування, юридичних кроків і доведення, що відновлені потоки мосту відповідають оновленій інваріанті безпеки.
Миттєве припинення сервісів — відповідь, що відповідає ситуації невизначеності. Якщо шлях міжланцюгового виводу може виробляти непідтверджені випуски, подальша робота з ризиком перетворює обмеження витоку у ширший дефіцит казначейства. Важливо, щоб механізми зупинки мосту були деталізовані, репетирувані та контрольовані.
NEAR Intents повідомив, що повідомив правоохоронним органам і співпрацює з експертами з безпеки і блокчейн-аналітики для трасування коштів і повернення. Оголошувалося, що викрадені кошти були надіслані у KuCoin і переведені до Bitcoin. Окремий аналіз показав, що близько 1.5М USDT рухаються через контракт Settlemant CoW Protocol.
Представник NEAR Intents дав зловмиснику 48-годинний строк для повернення коштів, опублікував адреси для повернення у Bitcoin, BNB Chain і Solana, але не пропонував вознаграждень. Станом на 2 жовтня повернення коштів або план погашення не було повідомлено.
Зобов’язання щодо компенсації теж важливе. Засновник NEAR Ілля Полосухін заявив, що всі постраждалі користувачі отримають повне відшкодування. Це зобов’язання враховує вплив на клієнтів, але не звільняє від технічного обов’язку опублікувати точний аналіз і запис про відновлення перед повторною роботою з вразливими маршрутами.
Корисний комплекс заходів після інциденту повинен включати:
- Точний опис уразливої компоненти і класу багу.
- Зміни у контрактах і інфраструктурі, що закривають шлях експлуатації.
- Чи не трапилася помилка у повідомленнях, nonce, реєстрі, підписувачах або процесах узгодження.
- Результати незалежного аудиту щодо виправлення.
- План відновлення по кожній мережі: BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll та Plasma.
- Правила моніторингу для раннього виявлення тієї самої аномальної форми виводу.
Інцидент також піднімає питання управління та операційної безпеки поза межами коду. Публікація адрес повернення, трасування коштів, координація з біржами, компенсація користувачам та залучення правоохоронних органів — кожне з них потребує правових і розкривних рішень. Команди, що готують процедуру відновлення мосту, повинні узгоджувати технічні заходи з юридичною та комплаєнс-підтримкою, особливо коли йдеться про зберігання активів, претензії користувачів, санкційні перевірки або міжнародне відновлення.
Що змінити міжланцюговим командам після інциденту NEAR Intents?
Команди міжланцюгових систем повинні розглядати кожен вивід через міст як доведення збереження цінності: випуск має бути прив’язаний до підтвердженого блокування або дебету, унікального повідомлення, конкретної цілі та обмеженої суми. Інцидент NEAR Intents демонструє, що моніторинг і екстрені зупинки є необхідними, але запобігання базується на тому, щоб зробити неможливим авторизацію неправдивих станів у складових системах.
Першим завданням інженерії є визначення основного invarianta мосту у бізнесі та технічних термінах. Для системи у стилі HOT Bridge invarianta — не просто “підпис MPC є дійсним”. Це ближче до: “цей точний вивід авторизований один раз, для цього активу та адресата, після того, як відповідний завершений і непогашений депозит або дебет у реєстрі”.
Цю invariantu потрібно тестувати у різних сценаріях збою:
- дублювання повідомлень і повторне використання nonce;
- невідповідність ідентифікаторів ланцюгів;
- невідповідність адрес токенів або їхніх десяткових частот;
- застарілі дозволи підписувачів;
- часткові збої інфраструктури;
- неконсистентність балансів реєстру та locker’ів;
- переходи у режимі аварійної зупинки;
- повтори після оновлень або міграцій контрактів.
Другим, протоколи мають розділяти детекцію та довіру. SHIELD виявив підозрілі активності під час події NEAR Intents, що допомогло активувати обмеження. Але моніторинг не має бути єдиним бар’єром між обліковою помилкою і втратою казначейства. Система моніторингу має виявляти підозрілі дії вже після їх початку. Правила перевірки контракту та мосту мають відкидати недійсну активність перед виконанням трансферу.
Третім, команда має створювати механізми відновлення, що порівнюють локації на зчитках із фундаментальних рівнів — блокчейн-локами, реєстром врегулювань, випусками на цільових ланцюгах і заявками на вивід. Неспівпадіння автоматично обмежує або зупиняє маршрут. Це особливо важливо для гарячих гаманців і казначейств, де валідна транзакція може швидко рухати ліквідність.
Четвертий аспект — формальна перевірка, орієнтована не тільки на арифметичну безпеку. Зобов’язання NEAR Intents щодо впровадження формальної перевірки правильні, якщо вони охоплюють стан — перехід через депозити, врегулювання, створення повідомлень мосту та виконання виводів. Формальне доведення однієї функції контракту не достатньо, якщо зовнішній компонент Infrastruktur може подати неправдиві, але прийнятні припущення.
Дослідницький центр Soken досліджує повторювані моделі збоїв у смарт-контрактах та безпеці протоколів, включно з різницею між локальною перевіркою і гарантією системної безпеки. Для команд мостів найбільш практичний урок — аудит має охоплювати контракти, формати повідомлень, політики підписувачів, операційний контроль, телеметрію і процедури відновлення.
NEAR Intents тепер має перетворити обіцянку пост-мортему у перевірюваний план відновлення: визначити несправну взаємодію, показати, чому випуск за виправленим шляхом не може виробляти неоплачений USDT, і незалежно протестувати кожен відновлений маршрут HOT Bridge. Командам, що керують подібною міжланцюговою інфраструктурою, потрібно почати з карти кожної заявки на вивід, прив’язаної до її підлеглого блокування або дебету, а потім перевірити, чи цей зв’язок стабільний при повторних спробах, затримках, оновленнях і ворожих повідомленнях.