Порожній підпис, який зламав Bonzo Lend: Постмортем експлойту на Hedera на $9 млн

2026/07/15 11:18:00

picture[data-cms-leading-picture="true"]{display:none!important}

У математиці та інформатиці нуль позначає порожнечу — абсолютне відсутність значення. Але в хрупкій та надзвичайно зв’язаній екосистемі децентралізованого фінансу (DeFi) невідповідно перевірений параметр «нуль» недавно став цифровим головним ключем. За кілька хвилин ця одна невідповідно перевірена порожня значення розблокувала та вивела понад 9 мільйонів доларів із відомої платформи кредитування.

Жертвою цього руйнівного використання вразливості був Bonzo Lend — найбільший протокол позичання, що працює на мережі Hedera. У липні 2026 року протокол побачив, як його загальна заблокована вартість (TVL) різко впала на 77%. Коли паніка поширилася серед спільноти Hedera, спостерігачі поспішали знайти джерело витоку.

Важливо, що ця катастрофа не відбулася через невдачу консенсусу базової мережі Hedera, ні через неправильні основні розрахунки позичання Bonzo Lend. Натомість катастрофа виникла через смертельну вразливість інтеграції: критичний дефект перевірки підпису у їхньому постачальнику цінових даних третьої сторони — Supra Oracles. Це пост-мортем того, як дрібна логічна помилка щодо «нічого» призвела до падіння гіганта DeFi.

Хронологія атаки: від $5 до $9 000 000 за секунди

Виконання експлойту Bonzo Lend було геніальним у своїй простоті, вимагаючи мінімального початкового капіталу і відбуваючись лише кількома транзакційними кроками.

Щоб розпочати напад, нападник внеслив мізерну, незначну суму забезпечення до Bonzo Lend — конкретно 250 токенів SAUCE. На момент внесення це забезпечення коштувало лише кілька доларів, чого вистачало лише на чашку кави. За нормальних правил протоколу ця крихітна сума дозволила б користувачеві позичити лише частину її вартості у інших цифрових активах.

Потім атакувач запустив експлойт, обійшовши перевірки перевірки ціни оракула. Вони створили та надіслали підроблений транзакцію оновлення ціни до контракту валідації оракула. Ця транзакція містила дуже шкідливі дані: вона штучно підвищила ціну токена SAUCE на астрономічні 12 порядків величини — ефективно повідомляючи протоколу, що один токен SAUCE раптово став вартий мільярди доларів.

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

Завдяки критичному недоліку в логіці перевірки, контракт вважав порожній підпис дійсним. Миттєво система оцінки Bonzo зареєструвала 250 SAUCE колатералу атакуючого як актив надзвичайно великої вартості. Використовуючи цю раптову, штучну багатство, хакер швидко вивів 6,63 мільйона USDC і 34,50 мільйона обгорнутих HBAR (wHBAR) з ліквідних пулів Bonzo, успішно опорожнивши протокол до того, як хтось міг підняти тривогу.

Розкриття недоліку «нульового підпису»: як зазнав невдачі код

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

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

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

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

Дилема оракула: чому DeFi-лего є лише настільки міцними, наскільки слабким є їхнє найслабше ланко

DeFi часто відзначають за його «композиційність» — здатність різних протоколів, токенів і інструментів з’єднуватися, як «грошові Лего», для створення складних фінансових додатків. Хоча композиційність забезпечує швидке інноваційне розвиток, вона також вносить системну хрупкість. Одна помилка в основному елементі може призвести до зрушення всієї структурної стопки.

Експлойт Bonzo Lend ідеально ілюструє цю вразливість. Bonzo Lend був добре структурованим протоколом позичання, який пройшов аудит безпеки. Однак протокол мусив довіряти зовнішньому залежному оракулу для надання точних цін. Момент, коли система перевірки оракула прийняла хибну ціну, призвела до того, що угоди позичання Bonzo виконалися точно так, як було написано, дозволивши користувачеві з великою кількістю активів позичити активи.

Наведена нижче таблиця розбиває розподіл структурних обов’язків під час атаки, ілюструючи, де зруйнувалася оборонна лінія:

Компонент	Задумана системна роль	Показники під час експлуатації	Структурний урок
Hedera Consensus Layer	Забезпечте безпеку стану реєстру, упорядкуйте транзакції та підтримуйте стабільну роботу мережі.	Виконано ідеально, без простоїв або експлойтів на рівні мережі.	Шар консенсусу безпечного мережевого рівня не гарантує безпеки на рівні застосунку.
Supra Oracle	Надавайте підписані, криптографічно перевірені та точні дані про ціни активів.	Не вдалося відхилити нульовий підпис, опубліковано пошкоджену ціну.	Залежності слід обробляти з використанням парадигм перевірки з нульовою довірою.
Bonzo позичити	Керуйте активами депозиту, стежте за співвідношенням здоров’я позики та обробляйте позички.	Сліпо довіряв вхідним даним про ціни, не обмежуючи різкі стрибки цін.	Смартконтракти повинні реалізовувати захисну логіку, щоб вижити при відмовах залежностей.

Біла шапка: гонка на мільйон доларів проти хакера

Поки експлуатація розгорталася у публічному реєстрі, відбувся драматичний вторинний подія. У публічних блокчейнах транзакції видно у «mempool» до їх фіналізації. Ця прозорість дозволяє іншим учасникам — як зловмисним, так і етичним — аналізувати поточні атаки в реальному часі.

Коротко після того, як основний нападник почав висмоктувати протокол, незалежний дослідник безпеки — відомий як «білий шапочник» — помітив активний експлойт. Усвідомивши, що весь протокол мав бути повністю опорожнений, білий шапочник швидко використав ту саму вразливість без підпису, щоб вивести приблизно 1 мільйон доларів США активів.

Ця тактика, відома як «фронт-ранінг», є поширеним захисним прийомом у безпеці Web3. Взявши кошти першим, білий капелюх запобіг зловмиснику викрасти ту частину ліквідного пулу.

Після успішного виведення білий капелюх негайно зв’язався з командою Bonzo Lend. Після підтвердження їхньої особистості та намірів етичний хакер безпечно повернув увесь мільйон доларів США на адреси відновлення протоколу. Хоча основний нападник все ще втік з більшістю коштів, ця швидка інтервенція зберегла важливу частину активів спільноти та продемонструвала унікальний, спільний характер безпеки Web3.

Переслідування мільйонів: Як вкрадені кошти покинули екосистему Hedera

Після того як хакер успішно позичив мільйони доларів США в USDC і wHBAR проти своєї фальшивої забезпеки, його основна мета змінилася на втечу з екосистеми Hedera, перш ніж протокол зможе призупинити свої контракти.

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

Невдовзі після обміну токенів атакуючий використав міжланцюгові мости, зокрема маршрутизуючи кошти через LayerZero. Переносячи активи, хакер перемістив понад 5 мільйонів доларів США вкрадених коштів безпосередньо на ethereum-мейннет.

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

Жорсткі уроки: Як DeFi-протоколи можуть захистити себе від катастроф оракулів

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

Щоб запобігти вразливостям, пов’язаним з нульовими підписами, розробники повинні застосовувати строгі, захисні практики кодування. Основні структурні покращення включають:

Явна перевірка нульової адреси: ніколи не припускайте, що функція перевірки підпису вдалася. Кожна криптографічна процедура перевірки повинна явно перевіряти, чи довжина підпису більша за нуль, і переконуватися, що вихідна адреса не розгортається у нульове значення (0x00...00). Якщо повертається нульове значення, транзакція повинна миттєво скасовуватися.
Надлишкові архітектури оракулів: Залежність від одного постачальника оракула створює єдину точку відмови. Надійні DeFi-протоколи повинні отримувати ціни на активи з кількох незалежних мереж оракулів (наприклад, Chainlink, Pyth і Supra одночасно). Якщо один джерело значно відрізняється від медіани інших, протокол повинен позначити розбіжність і автоматично призупинити роботу.
Цінові аварійні вимикачі на ланцюзі: протоколи позичання повинні впроваджувати обмеження швидкості та межі відхилення ціни. Навіть якщо оракул стверджує, що ціна токена зросла на трильйон разів за один блок, внутрішній ціновий вимикач смартконтракту повинен відхилити оновлення як аномалію, зупинивши будь-які дії щодо позичання або ліквідації до виконання ручної адміністративної перевірки.

Майбутнє аудиту смартконтрактів: чому ми повинні тестувати межі

Експлуатація Bonzo Lend виявляє критичну обмеженість сучасних практик аудиту Web3. Багато безпечних аудитів зосереджуються на перевірці того, чи працює бізнес-логіка контракту в очікуваних умовах — часто це називають тестуванням «happy-path».

Однак реальні зловмисники не дотримуються оптимістичного сценарію. Вони спеціально шукають граничні умови, неініціалізовані стани та неочікувані вхідні дані. Індустрія безпеки повинна змінити підхід на агресивне тестування крайніх випадків, щоб виявити приховані недоліки до запуску коду на мейннеті.

Для досягнення цієї мети протоколи повинні зробити просунуті методи тестування, такі як фаззинг і формальна верифікація, обов’язковим стандартом. Фаззинг передбачає використання автоматизованих інструментів для заповнення смартконтрактів мільйонами випадкових, пошкоджених і порожніх вхідних даних — зокрема порожніх байтових рядків і нульових підписів. Якби контракт верифікації був підданий строгому фаззингу, обхід через нульовий підпис був би виявлено миттєво.

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

Висновок: Відновлення довіри в бездовірчій екосистемі

Експлуатація Bonzo Lend — це жорстке нагадування про непримиренний характер смартконтрактів. У Web3 код — це закон, і EVM не цікавиться вашими намірами. Невелика логічна прогалина щодо «нічого» може миттєво знищити роки розробки й мільйони доларів користувацької довіри.

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

Питання та відповіді:

Q1: Чи означає «нульова підписова» помилка, що криптографія блокчейну зламана?

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

Q2: Чому Bonzo Lend автоматично довіряв такій абсурдно завищеної ціні SAUCE?

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

Q3: Що можуть робити звичайні користувачі DeFi, щоб захистити себе від хаків, пов’язаних з оракулами?

Хоча користувачі не можуть керувати кодом протоколу, вони можуть керувати власним ризиком. Щоб захистити свій капітал, диверсифікуйте свої активи між кількома незалежними платформами, уникайте протоколів, які залежать від одного джерела оракула для нишевих активів, і вибирайте платформи, які публічно інтегрували багатоджерельні системи оракулів та надійні, он-чейн аварійні зупинки.

Відмова від відповідальності: Цей матеріал надається виключно в інформаційних цілях і не є інвестиційною порадою. Інвестиції в криптовалюту супроводжуються ризиками. Будь ласка, проводьте власне дослідження (DYOR).

Відмова від відповідальності: Для вашої зручності цю сторінку було перекладено за допомогою технології ШІ. Для отримання найточнішої інформації дивіться оригінальну англійську версію.