Інцидент безпеки Binance привернув увагу не лише через масштаб підозрілої активності гаманців, а й через одну технічну деталь, помітну незадовго до того, як основні активи Ethereum почали рухатися: пакет авторизацій EIP-7702.
Ця деталь швидко вивела EIP-7702 у центр обговорення. Механізм делегування облікових записів Ethereum дозволяє звичайному зовнішньо керованому обліковому запису, або EOA, тимчасово виконувати логіку смарт-контракту. В інциденті з Binance дослідники блокчейну виявили делегування EIP-7702 незадовго до того, як активи було переказано з гарячого гаманця, пов'язаного з Binance.
Але є важлива відмінність.
Наявність авторизації EIP-7702 сама по собі не доводить, що EIP-7702 було використано як експлойт.
Початкове розслідування Binance натомість вказує на компрометацію операційної інфраструктури. Біржа заявила, що ноутбук інженера DevOps міг бути скомпрометований, що дозволило зловмиснику отримати доступ до сервісного контейнера та подати несанкціоновані транзакції на виведення коштів. Binance також заявила, що не знайшла доказів витоку приватних ключів гаманців.
Це робить інцидент особливо важливим для розуміння сучасної безпеки гаманців. Приватний ключ може залишатися всередині захищеної інфраструктури, тоді як зловмисник зловживає іншою системою, якій дозволено запитувати легітимні підписи.
У цій статті пояснюється, що, ймовірно, зробив EIP-7702 в інциденті, чому повідомлення про численні авторизації привернули увагу та чому різниця між крадіжкою ключів і компрометацією інфраструктури підпису має значення.
Що сталося в інциденті безпеки Binance?
Підозріла активність, пов'язана з гарячими гаманцями Binance, почала привертати увагу 30 жовтня 2026 року.
Дослідники ончейн-даних спостерігали великі перекази з гаманців, пов'язаних з біржею, на новостворені адреси. Ранні оцінки значно різнилися, оскільки дослідники відстежували транзакції в мережах Ethereum, Bitcoin, Tron та інших.
Згодом Binance визнала інцидент безпеки та розпочала розслідування джерела несанкціонованих транзакцій. Біржа тимчасово призупинила депозити та виведення коштів, проводячи перевірки безпеки.
У своєму оновленні щодо безпеки від 30 жовтня Binance заявила, що її початкове розслідування свідчить про те, що скомпрометований ноутбук інженера DevOps дозволив зловмиснику отримати доступ до сервісного контейнера та подати несанкціоновані транзакції на виведення коштів.
Біржа оцінила загальний вплив приблизно в 6,3 мільярда доларів на цьому етапі розслідування та заявила, що близько 3 мільярдів доларів постраждалих активів було заморожено ончейн. Binance також заявила, що покриє збитки за допомогою свого фонду SAFU та коштів компанії.
Найважливіше для технічного обговорення те, що Binance заявила:
Вона не знайшла доказів витоку приватного ключа гаманця.
Ця заява змінює те, як слід інтерпретувати повідомлену активність EIP-7702.
Замість того, щоб питати лише, чи викрав зловмисник приватний ключ гарячого гаманця, більш релевантним стає питання, чи зміг скомпрометований внутрішній системний компонент запросити або сприяти отриманню дійсної авторизації від захищеної інфраструктури підпису.
Чому EIP-7702 став частиною розслідування?
EIP-7702 було впроваджено з оновленням Ethereum Pectra, щоб надати зовнішньо керованим обліковим записам деякі можливості, зазвичай пов'язані з гаманцями смарт-контрактів.
Традиційно EOA Ethereum контролюється приватним ключем. Він може підписувати транзакції, переказувати активи та взаємодіяти зі смарт-контрактами, але його власний обліковий запис не містить програмованої логіки виконання.
EIP-7702 змінює цей зв'язок.
Він дозволяє EOA авторизувати код іншого контракту як свою логіку виконання, зберігаючи оригінальну адресу Ethereum.
Це вможливлює корисні функції абстракції облікових записів, такі як пакетування транзакцій, спонсорування газу та більш просунуті системи дозволів.
Це також означає, що авторизація EIP-7702 заслуговує значно більшої уваги, ніж звичайне схвалення токенів.
Під час аналізу інциденту з Binance дослідники повідомили, що адреса, профінансована через Tornado Cash, подала кілька авторизацій EIP-7702, пов'язаних з гарячим гаманцем Ethereum, пов'язаним з Binance, незадовго до того, як відбулися основні перекази активів.
Повідомлялося, що одна авторизація відповідала стану гаманця і набула чинності.
Приблизно через три хвилини значні активи почали залишати гаманець.
Часова послідовність, природно, зробила авторизацію важливою частиною розслідування.
Це все ще не говорить нам, як було отримано дійсну авторизацію.
Як працює авторизація EIP-7702?
Найпростіший спосіб зрозуміти цей механізм — уявити, що EIP-7702 дозволяє звичайному обліковому запису Ethereum тимчасово заявити:
«Використовуй логіку виконання цього смарт-контракту, коли мій обліковий запис отримує виклики».
Спрощена схема виглядає так:
Ethereum EOA
│
│ Підписує авторизацію EIP-7702
▼
Призначається делегування
│
▼
Смарт-контракт-делегат
│
│ Надає виконувану логіку
▼
Початковий EOA може виконувати
поведінку в стилі смарт-контракту
Початковий обліковий запис не зникає.
Його адреса, баланси та наявна історія в мережі залишаються незмінними. Змінюється код, який можна виконати через цей обліковий запис.
EIP-7702 також містить запобіжні заходи. Авторизації прив'язані до стану облікового запису, включно з nonce, і можуть бути замінені або відкликані. Тому це не довільні інструкції, які будь-хто може прикріпити до гаманця іншої людини.
Дійсна авторизація все одно вимагає легітимної криптографічної авторизації від відповідного облікового запису.
Цей момент є ключовим для розуміння інциденту з Binance.
Якщо зловмиснику вдалося успішно встановити шкідливу логіку делегування, важливе питання безпеки полягає не просто в тому:
«Чи використовував зловмисник EIP-7702?»
А в тому:
«Як зловмисник отримав повноваження створити дійсну авторизацію EIP-7702?»
Чому повідомлялося про кілька авторизацій EIP-7702?
Дослідники безпеки, які вивчали транзакції, повідомили, що зловмисник надіслав пакет, що містив приблизно 50 авторизацій, пов'язаних з різними значеннями nonce.
На перший погляд, «50 авторизацій» може звучати так, ніби було скомпрометовано 50 гаманців.
Це не обов'язково те, що сталося.
Облікові записи Ethereum підтримують nonce, який змінюється в міру виконання транзакцій. Авторизація EIP-7702 повинна відповідати належному стану облікового запису.
Якщо зловмисник знає, на який гаманець хоче націлитися, але не може надійно визначити, який nonce буде дійсним, коли транзакція досягне мережі, він може підготувати авторизації для кількох можливих значень nonce.
Успішною буде лише авторизація, що відповідає дійсному стану гаманця.
Цю техніку іноді називають nonce spraying.
Важливий висновок полягає в тому, що наявність 50 записів авторизації не обов'язково означає 50 успішних дозволів, 50 скомпрометованих приватних ключів або 50 окремих атак на гаманці.
Натомість ця схема могла бути розроблена для підвищення ймовірності того, що одна раніше отримана авторизація відповідатиме стану цільового облікового запису під час подання.
Це породжує ще одне питання:
Хто — або яка внутрішня система — мав повноваження створити базовий підпис?
Саме тут попередні висновки Binance стають особливо актуальними.
Крадіжка приватного ключа та компрометація інфраструктури підпису — це різні проблеми
Багато дискусій про безпеку криптовалют зводять захист гаманця до одного принципу:
Захистіть приватний ключ.
Це залишається важливим, але інституційні гаманці значно складніші.
Біржа може використовувати апаратні модулі безпеки, сервіси підпису, механізми політик, сервіси виведення коштів, системи контролю доступу та іншу інфраструктуру навколо базового ключа.
Тому зловмисник може спробувати скомпрометувати процес, який запитує підпис, а не витягти сам приватний ключ.
Попереднє розслідування Binance наразі вказує значно більше на другий сценарій.
Біржа заявила, що скомпрометований ноутбук DevOps міг надати доступ до контейнера сервісу, здатного подавати несанкціоновані транзакції виведення коштів, при цьому чітко зазначивши, що не знайшла доказів витоку приватного ключа.
Ця різниця є суттєвою.
Приватний ключ, захищений апаратно, технічно може залишатися в безпеці, тоді як навколишня інфраструктура створює підпис для чогось, що ніколи не повинно було бути схвалено.
Чи став EIP-7702 причиною злому Binance?
Виходячи з наразі доступної інформації, немає публічних доказів того, що вразливість у самому EIP-7702 спричинила інцидент безпеки Binance.
Ця різниця є критично важливою.
Атакувальник, який використовує легітимну функцію протоколу, не означає автоматично, що ця функція була зламана.
Розглянемо простіший приклад.
Якщо атакувальник отримує легітимні облікові дані для банківського рахунку та ініціює переказ через звичайну платіжну систему банку, той факт, що платіжна інфраструктура банку виконала платіж, не доводить, що сам протокол переказу був дефектним.
Подібне розрізнення застосовується і тут.
EIP-7702 міг надати механізм виконання, за допомогою якого успішно авторизований обліковий запис міг делегувати свою поведінку шкідливому коду.
Але EIP-7702 зазвичай вимагає дійсної авторизації.
Нерозв'язане питання полягає в тому, як ця авторизація стала можливою.
Попереднє пояснення Binance свідчить про те, що слідчі вивчають скомпрометовану операційну інфраструктуру, а не збій протоколу Ethereum.
Тому найточніша інтерпретація на цьому етапі така:
EIP-7702, схоже, має відношення до шляху виконання, який розслідується, але його не встановлено як кореневу вразливість.
Що було підтверджено і що залишається предметом розслідування?
Оскільки великі інциденти безпеки розвиваються швидко, розрізнення підтверджених висновків від аналізу на рівні транзакцій особливо важливе.
Це розрізнення має значення, оскільки транзакції блокчейну забезпечують чудову видимість того, що відбулося в ланцюжку, але вони не обов'язково розкривають, як була скомпрометована внутрішня система підпису.
Дослідники можуть спостерігати делегування, перекази та взаємодії з контрактами.
Вони не можуть визначити лише з даних блокчейну, чи був підпис створений після крадіжки приватного ключа, чи внутрішній сервіс легітимно його запросив, чи скомпрометований робочий процес змусив захищений підписувач авторизувати шкідливі інструкції.
Для цього потрібні докази зсередини постраждалої інфраструктури.
Чому інфраструктура підпису важлива так само, як і зберігання приватних ключів
Інституційна безпека криптовалют дедалі більше складається з кількох рівнів.
Перший — це безпека ключів.
Де зберігається приватний ключ? Чи можна його витягти? Чи захищений він апаратним модулем безпеки або іншою криптографічною системою зберігання?
Другий — це безпека підпису.
Які сервіси мають право запитувати підписи від захищеного ключа? Які автентифікацію, політики та механізми схвалення повинні задовольняти ці сервіси?
Третій — це безпека авторизації.
Навіть якщо запит криптографічно дійсний, що саме обліковий запис просять авторизувати?
Цей третій рівень стає дедалі важливішим у міру того, як смарт-акаунти та делегування облікових записів набувають більших можливостей.
Звичайний переказ токенів може переміщати фіксовану кількість одного активу.
Делегування натомість може змінити те, як обліковий запис може виконувати майбутні інструкції.
Для команд безпеки ця різниця означає, що самої лише перевірки підпису вже недостатньо.
Також потрібно оцінювати значення транзакції.
Чому EIP-7702 змінює припущення щодо безпеки гаманців
EIP-7702 є потужним саме тому, що він розширює можливості звичайного облікового запису Ethereum.
Гаманець може отримати програмовані функції без перенесення активів до абсолютно нового гаманця смарт-контракту.
Для споживчих гаманців це може покращити зручність використання.
Для складної інституційної інфраструктури це може підтримувати більш просунуті політики виконання.
Але додаткова програмованість створює додаткові поверхні авторизації.
Шкідливе схвалення ERC-20 зазвичай надає іншій адресі дозвіл на один токен.
Шкідливе делегування EIP-7702 потенційно може впливати на те, як обліковий запис виконує значно ширші класи дій.
Це не робить EIP-7702 за своєю суттю небезпечним.
Це означає, що гаманці, біржі та постачальники послуг зберігання повинні ставитися до авторизації делегування як до високоризикової операції безпеки.
Підпис EIP-7702 не слід оцінювати лише як криптографічно дійсний.
Системи безпеки також повинні запитувати, чи ціль делегування є очікуваною, чи було перевірено її байт-код, чи відповідає запитана авторизація звичайній поведінці облікового запису та чи взагалі внутрішня політика дозволяє цьому обліковому запису делегувати виконання.
Що має прояснити розбір інциденту Binance?
Binance заявила, що детальний технічний розбір буде опубліковано після завершення розслідування.
Кілька питань визначать, як галузь зрештою інтерпретує цей інцидент.
По-перше, як зловмисник отримав доступ до шляху підписання?
Попереднє пояснення DevOps вказує на потенційно скомпрометовану частину інфраструктури, але повний ланцюжок від цього доступу до дійсної блокчейн-авторизації залишається важливим.
По-друге, яку саме роль відіграла EIP-7702?
Слідчим потрібно буде визначити, чи була потрібна делегація для виконання переказів Ethereum, як було підготовлено авторизацію і чому внутрішні засоби контролю це дозволили.
По-третє, чи були коли-небудь скомпрометовані приватні ключі?
Наразі Binance заявляє, що немає доказів витоку приватних ключів. Повний судово-технічний звіт міг би надати більше деталей про те, як ключі були ізольовані від скомпрометованої інфраструктури.
Нарешті, який засіб контролю мав зупинити транзакцію?
Для команд інституційної безпеки це, можливо, найцінніше питання з усіх.
Технічно дійсний підпис не повинен автоматично означати операційно дійсну транзакцію.
Найнадійніші системи зберігання відокремлюють криптографічну авторизацію від бізнес-авторизації.
Що це означає для звичайних користувачів гаманців Ethereum?
Інцидент з Binance стосується інституційної інфраструктури і не повинен автоматично тлумачитися як доказ того, що звичайні гаманці Ethereum піддаються тому самому шляху атаки.
Особистий гаманець самостійного зберігання та система гарячих гаманців біржі працюють дуже по-різному.
Однак EIP-7702 дає важливий урок і для окремих користувачів:
Підпис делегації заслуговує на такий самий рівень обережності, як і інші потужні дозволи гаманця.
Користувачі повинні ретельно перевіряти, що гаманець просить їх підписати, особливо коли незнайомий веб-сайт запитує делегацію облікового запису.
Шкідливу делегацію не слід плутати зі звичайним підписом для входу.
Користувачам також слід покладатися на перевірені інтерфейси гаманців, які чітко ідентифікують запити на делегацію та позначають підозрілі контракти.
Ключовий принцип безпеки залишається простим: не оцінюйте підпис лише за тим, чи він негайно переказує кошти. Деякі підписи змінюють те, що обліковому запису буде дозволено робити пізніше.
Більший урок: безпека гаманців виходить за межі приватних ключів
Інцидент з безпекою Binance висвітлює ширшу еволюцію в безпеці блокчейну.
Протягом багатьох років домінуюче припущення галузі було простим:
Захисти ключ — захисти гаманець.
Ця модель стає неповною.
Сучасні інституційні гаманці часто залежать від шарів інфраструктури навколо ключа — API, служб підписання, механізмів виведення, систем політик, засобів контролю доступу та автоматизованих середовищ виконання.
Механізми абстракції облікових записів, такі як EIP-7702, додають ще один шар, дозволяючи гаманцям делегувати логіку виконання.
Як результат, безпека криптовалют дедалі більше залежить від трьох окремих питань:
Хто контролює ключ?
Хто може запросити підпис?
І які повноваження цей підпис насправді надає?
Система може успішно відповісти на перше питання, але зазнати невдачі на другому чи третьому.
Це, схоже, є одним із найважливіших питань, порушених розслідуванням Binance на цей момент.
Часті запитання
Чи була EIP-7702 причиною злому Binance?
Не підтверджено. Попередні висновки Binance вказують на скомпрометовану операційну інфраструктуру, тоді як EIP-7702, схоже, була частиною шляху авторизації, що розслідується.
Чи були викрадені приватні ключі Binance?
Binance заявила, що в ході початкового розслідування не виявила доказів витоку приватних ключів гаманця.
Що таке EIP-7702?
EIP-7702 дозволяє EOA Ethereum делегувати логіку виконання коду смарт-контракту, зберігаючи ту саму адресу гаманця.
Чому спостерігалося кілька авторизацій EIP-7702?
Вони могли бути підготовлені з різними значеннями nonce відповідно до стану цільового облікового запису. Це не обов'язково означає, що було скомпрометовано кілька гаманців.
Чи постраждали звичайні користувачі Ethereum?
Немає доказів компрометації гаманців Ethereum у масштабах усієї мережі. Користувачам все одно слід бути обережними з незнайомими запитами на делегацію або підписання.
Чи достатньо відкликати дозволи на токени?
Не завжди. Дозволи ERC-20 та делегування EIP-7702 є окремими дозволами, тому видалення дозволу на токен не автоматично видаляє делегування облікового запису.
Висновок
Поява EIP-7702 в інциденті Binance робить цей механізм важливою частиною технічного розслідування, але наявні докази не встановлюють, що сам EIP-7702 було скомпрометовано.
Попередні висновки Binance натомість свідчать про те, що зловмисник міг скомпрометувати ноутбук інженера DevOps, отримати доступ до операційного контейнера сервісу та подати несанкціоновані транзакції на виведення коштів. Біржа заявляє, що не знайшла доказів витоку приватних ключів гаманця.
Ця різниця має значення.
Якщо захищену систему підпису можна спонукати авторизувати шкідливі інструкції, зловмисникам може взагалі не знадобитися викрадати приватний ключ.
EIP-7702 може збільшити наслідки такої авторизації, оскільки дозволяє обліковому запису Ethereum делегувати програмовану логіку виконання. Але використання цієї можливості зі зловмисною метою та виявлення вразливості в протоколі — це дві різні речі.
Доки Binance не опублікує повний технічний постмортем, EIP-7702 найкраще розуміти як компонент у повідомленому шляху виконання, а не як підтверджену першопричину інциденту.
Для бірж, кастодіальних провайдерів і розробників гаманців більший урок уже очевидний: сучасна безпека гаманців повинна захищати не лише приватні ключі, а й системи, що запитують підписи, та дозволи, які ці підписи створюють.
Відмова від відповідальності щодо ризиків: Ця стаття призначена лише для інформаційних та освітніх цілей. Криптовалюти та блокчейн-системи пов'язані з технічними, операційними та ринковими ризиками. Читачам слід самостійно перевіряти інформацію про безпеку та використовувати належні засоби контролю ризиків під час управління цифровими активами.
