6,8 мільярда доларів попереджають: більшість атак DeFi поза межами аудиту

Автор: Ліам 'Акіба' Райт, cryptoslate

Скомпільовано: Чоппер, Foresight News

У сфері децентралізованих фінансів "аудит" часто розглядається як гарантія безпеки всього проєкту. Але насправді аудит зазвичай охоплює лише певний момент часу, конкретний код, компоненти та версії. Будь-які зміни, додавання або видалення поза цими межами можуть призвести до зовсім інших результатів аудиту.

Нове попереднє дослідження наводить конкретні цифри цього розриву. Компанія безпеки ack3 разом з дослідниками з Чеського технічного університету в Празі проаналізували 135 випадків безпеки, які були зафіксовані в першій половині 2026 року, що призвели до збитків у розмірі 939,86 мільйона доларів. Вони виявили, що 68 з цих випадків мали ідентифіковані публічні записи попереднього аудиту.

У вибірці з 68 випадків дослідники класифікували 46 шляхів атак як повністю поза межами будь-якого перевіреного аудиту; 20 випадків принаймні підпадали під одну область аудиту; залишилися 2 випадки не підлягали оцінці. Випадки поза межами аудиту становили 67,6% від загальної кількості випадків, але відповідали 94,4% від загальної суми збитків.

Цей вражаючий відсоток не є оцінкою ефективності аудиту і не є доказом того, що обмеження аудиту призводять до збитків. Він лише відображає розподіл збитків у вибраній публічній вибірці випадків безпеки. Два великі випадки суттєво вплинули на дані: виключивши збитки Kelp DAO у розмірі 292 мільйони доларів і Drift Protocol у розмірі 285 мільйонів доларів, у вибірці вже перевірених випадків частка збитків від атак поза межами аудиту зменшилася до 72,1%.

Навіть з цими обмеженнями, це дослідження виявляє основну проблему довіри до безпеки: проєкт може стверджувати, що він пройшов аудит, але користувачі не можуть знати, чи була перевірена фактична система, потоки коштів та відповідні контрольні заходи.

Реальне значення даних

Дослідження ack3 охоплює період з 1 січня 2026 року по 29 червня, включаючи 122 підтверджені випадки атак і 13 підозрюваних випадків. У всій вибірці 35 випадків не мали записів аудиту, 32 випадки мали невідомі історії аудиту, ці дві категорії не враховуються у вищезгаданій статистиці 68 випадків.

У вибірці з 68 випадків збитки від атак поза межами аудиту становили 680,97 мільйона доларів, загальні збитки склали 721,24 мільйона доларів, що дало 94,4% цього показника. Виключивши Kelp DAO та Drift Protocol, збитки поза межами аудиту становили 103,97 мільйона доларів, загальні збитки склали 144,24 мільйона доларів, що становить 72,1%. Файл даних у форматі json може відтворити кількість класифікацій випадків та суму збитків.

Мітка "в межах/поза межами аудиту" є судженням дослідників на основі публічних доказів. Дослідницька група переглянула архіви проєкту та аудиторських організацій, знайшла звіти про аудит до атаки, порівняла остаточні шляхи атак з перевіреним кодом, версіями та виключеними елементами аудиту. Це дослідження є попереднім документом на 6 сторінок, спільно випущеним з постачальником даних, двоє авторів належать до компанії з аудиту безпеки ack3.

Дослідження не має контрольної групи, яка не зазнала атак, і не статистує тривалість ризику, на який піддаються різні системи. Тому неможливо довести, що перевірені протоколи загалом є більш безпечними, не можна оцінити ймовірність виникнення випадків, і не можна підтвердити, що "поза межами аудиту" є безпосередньою причиною кожної втрати. Деякі непублічні аудити та приватні інциденти можуть бути відсутніми, а вже звітувані дані про збитки не завжди є порівнянними.

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

Два випадки, що сталися в серпні, з різних точок зору підтверджують цю різницю. Випадок ICON Network наочно демонструє, як два перевірених коди зазнають збоїв на межах двох контрольних етапів; а безпека aelf у серпні є іншим випадком, коли наявні докази аудиту не можуть зв'язати шлях атаки з попереднім охопленням аудиту.

ICON Network: зразок збою на межі перевірки

У повторній атаці ICON Network 27 серпня два модулі ланцюга виведення виявили розбіжності в тлумаченні одного й того ж повідомлення.

Згідно з післяопераційним звітом ICON Foundation: контракт міграції покладався на старші біти номеру послідовності повідомлення для визначення унікальності повідомлення; але криптографічний підпис охоплював лише нижні 256 біт. Зловмисник змінив старші біти, які не підлягали перевірці підписом, і протягом приблизно 20 хвилин повторно подав дві легітимні підписані повідомлення 1492 рази, з яких 1490 разів виклик виконання успішно.

Ця повторна атака призвела до виведення 119,866 мільйона ICX та 531600 bnUSD. У момент публікації звіту ICON підтвердив чисті збитки приблизно 150,2 ETH плюс 31204 USDC. Фонд підтвердив, що 531600 bnUSD та 1,366 мільйона SODA активів були повернуті, а депозити користувачів, залишки рахунків та позиції не постраждали.

ICON зазначив, що цей контракт міграції вже пройшов зовнішній аудит і реалізував рекомендації аудиту, включаючи відповідні зміни в межах одного модуля; відповідна логіка реле також підлягала окремій спеціалізованій перевірці. У списку аудиту документації розробки Sodax міститься 8 звітів, що охоплюють різні компоненти, включаючи звіт про аудит реле Sodax за листопад 2025 року.

Але звіт про повторну атаку чітко зазначає, що логіка перевірки унікальності та значення перевірки підпису не входять до виявлених під час аудиту. Простий ярлик "аудитований" не може дати користувачам знати, чи зберігаються стандарти визначення "унікальності повідомлення" на обох кінцях ланцюга виведення.

Хронологія реагування також виявила інший тип проблеми на межі. Перше автоматичне сповіщення ICON спрацювало о 02:08 UTC, приблизно за 7 хвилин до початку атаки. Співробітники розпочали розслідування приблизно о 03:40, о 03:53 призупинили уражений контракт, а о 06:18:54 призупинили всю мережу.

Від першого сповіщення до повного реагування на надзвичайну ситуацію пройшло близько 90 хвилин. ICON пояснив це коригуванням механізму сповіщення, оскільки це правило сповіщення викликало багато помилкових сповіщень під час попередніх збоїв зв'язку в мережі, тому не було повідомлено черговому персоналу з високим пріоритетом. Фонд планує впровадити механізм автоматичного вимкнення, знизити поріг спрацьовування та провести спеціалізовану перевірку на предмет унікальності повідомлень та захисту від повторних атак.

Ці механізми управління ризиками не можуть замінити аудит, але вони відповідають на інше ключове питання: чи може система швидко виявити та ізолювати ризики, коли запобіжні заходи не спрацювали?

Користувачі все ще повинні чітко відповісти на питання безпеки

aelf: безпека потребує постійного оновлення

aelf у серпневому інциденті безпеки підтверджує цю точку зору з іншого боку. Публічна інформація описує, що відбулося вторгнення під час виконання та контрольоване відновлення, але наявних доказів недостатньо, щоб визначити, чи потрапив шлях атаки в межі попереднього специфічного аудиту.

Офіційне оголошення проєкту зазначає: існує несанкціонований смарт-контракт, який може за допомогою параметрів транзакції впроваджувати закодовані .NET збірки та інструкції в ланцюг виконання вузлів.

Попередній звіт розслідування пов'язує інцидент з дефектами перевірки під час виконання та динамічного завантаження, а також недостатньою ізоляцією між середовищем виконання контракту та чутливими вузлами, ресурсами інфраструктури. aelf виявив 155 відповідних транзакцій, 5 незалежних збірок корисного навантаження, які здатні виконувати команди на хостах, намагатися зв'язатися з зовнішніми системами, отримувати ключі вузлів, проводити розвідку інфраструктури тощо.

Наявність можливостей не означає, що всі корисні навантаження були успішно виконані, і не означає, що зловмисник отримав усі цільові свідоцтва, чутливі дані не були витікнуті. aelf зазначив, що вже відповідно до стандартів потенційного витоку змінив ключі підпису та свідоцтва інфраструктури.

Станом на 11 вересня це висновок залишається етапним. Блог aelf на офіційному сайті не публікував спеціальних оновлень щодо цього інциденту після 26 серпня. Оголошення від 26 серпня обіцяло подальші оновлення та остаточний звіт.

aelf у технічній документації з безпеки зазначає, що його блокчейн та контракти токенів ELF пройшли кілька раундів аудиту, і не було виявлено жодних проблем з безпекою. Але наявна публічна сторінка не може зв'язати шлях атаки в серпні з якимось звітом про аудит, що відбувся до інциденту. Тому кваліфікувати інцидент як недолік аудиту або збій поза межами аудиту не має достатніх доказів.

Ця невизначеність сама по собі має значення. Аудиторський звіт з часовою міткою з часом буде відставати від коду системи, бібліотек залежностей, фактичного стану експлуатації. Користувачам потрібен запис безпеки з версією, щоб відобразити цю різницю.

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

Це не заперечує цінність аудиту, а лише дозволяє узгодити рекламу аудиту з фактичним змістом роботи та зв'язати його з поточною системою.

Одна мітка аудиту не може відповісти на питання: чи залишаються перевірені компоненти, розгорнуті системи та механізми реагування на збої в межах одного й того ж безпечного кордону?

Цей контент надано лише для загальних інформаційних цілей і не є фінансовою, інвестиційною, юридичною чи податковою консультацією. Події, нагороди, онлайн-акцій або пов’язану інформацію, згадана тут, не слід розглядати як рекомендацію, прохання чи запрошення до купівлі, продажу, торгівлі чи інших операцій з криптоактивами. Криптоактиви є дуже волатильними та можуть призвести до збитків. Доступність послуг, продуктів WEEX та пов’язаних із ними подій може відрізнятися залежно від регіону. Ви несете відповідальність за забезпечення відповідності вашої участі чинному місцевому законодавству та нормативним актам.