EIP-7702 надає адресам можливості та гнучкість, подібні до смартконтрактів, все більше додатків 7702 постійно створюються, що є вкрай важливим для залучення більшої кількості людей у Web3 та покращення користувацького досвіду.
Однак гнучкість 7702 і той факт, що більшість користувачів не знайомі з 7702, використовуються шахрайськими синдикатами, і нещодавно ми спостерігали, що деяким користувачам довелося авторизувати більше десятка взаємодій через здатність Metamask 7702 виконувати пакети, а фішингова банда #InfernoDrainer об'єднана в одну транзакцію, що призвело до крадіжки активів.
Пояснення: Metamask сам по собі не має проблем із безпекою, Metamask ставить безпеку користувачів на перше місце, надаючи можливості, пов'язані з 7702, і вживає багато заходів безпеки. Користувачам потрібно більше дізнатися про можливості 7702 та пов'язані ризики, щоб запобігти повторенню таких інцидентів із безпекою.
О, Metamask 7702 Delagator підпис авторизації принципи та безпекове проєктування
Технічний аналіз
За допомогою авторизації користувача, вже розгорнутого Делегаторського Контракту, поле code облікового запису користувача вказується на цей контракт. Актуальна адреса офіційного Делегаторського Контракту MetaMask: 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B
Авторизаційна структура: (chainId, delegatorAddress, nonce, signature) записати в authorization_list
Метод підпису: Metamask використовує уніфіковану логіку підпису для транзакцій авторизації, пов'язаних з EIP-7702, тобто метод signEIP7702Authorization, і digest7702 = keccak256(0x05 ‖ RLP(chainId, делегатор, nonce)) підпис ECDSA, згенеруйте структуру підпису (v, r, s) та прикріпіть її до наступних транзакцій типу 4 для реалізації авторизації та оновлення облікового запису, як описано в:
Метод верифікації: рівень консенсусу завершує перевірку за допомогою ecrecover(digest7702, sig) == tx.from.
Дизайн безпеки: веб-клієнт не може спонукати користувачів авторизувати довільних делегаторів, оскільки метод авторизації signEIP7702 реалізований лише всередині гаманця MetaMask і не відкритий для веб-клієнта через window.ethereum**. Метод підпису, доступний на вебсторінці **, наприклад eth_signTypedData_v4 не застосовується до авторизованих підписів EIP-7702, а формат підсумку підпису такий:
А формат підпису, вимогами якого визначається EIP-7702, є:
Оскільки eth_signTypedData_v4 завжди містить префікс 0x1901, а процес обчислення дайджесту абсолютно відрізняється від 7702, то навіть при вмілому конструюванні domainSeparator, primaryType та message, майже неможливо зробити так, щоб digest712 == digest7702.
Таким чином, Інтернет не може підробити законний підпис авторизації 7702 за допомогою цього методу. Крім того, MetaMask також реалізує механізм білого списку для адрес делегаторів, який діє за замовчуванням і дозволяє лише авторизований офіційний делегатор (0x63c0... 32B), який забороняє DApps самостійно впроваджувати адреси, додатково запобігаючи спонуканню користувачів підписувати шкідливі дані авторизації делегатора.
Спосіб використання
Поточний спосіб оновлення існуючого EOA в Metamask до 7702 смартконтракту (Smart Account) поділяється на два основні типи: активне оновлення та пасивне оновлення.
Активне оновлення означає, що користувач на інтерфейсі гаманця активно натискає кнопку "Переключити", авторизуючи певний Delegator Contract.
Пасивне оновлення відбувається, коли користувач взаємодіє з певними DApp, які підтримують 7702, після того, як Metamask виявляє відповідну операцію, автоматично з'являється підказка, яка рекомендує користувачу завершити оновлення.
2.1 Активне оновлення:
Торгова інформація: включає лише дії з оновлення облікового запису, а саме уповноваження конкретного Delegator Contract.
Процес оновлення: перейдіть до інтерфейсу деталей облікового запису гаманця, натисніть на кнопку перемикання, показану на малюнку нижче, щоб оновити користувача з Ethereum Mainnet до смартконтракту. Після натискання на перемикання з'явиться вікно підпису користувача для поточної угоди на оновлення:
Запис авторизації: Після підтвердження дочекайтеся, поки транзакція з'явиться в ланцюжку, що означає, що користувач успішно перейшов на смарт-аккаунт, і може переглянути конкретну інформацію про транзакцію авторизації з **Авторизацій 01928283702(** на сторінці поточної адреси гаманця на etherscan.
2.2 Пасивне оновлення
Торговий зміст: включає дії з оновлення облікового запису та пакетні дії взаємодії з смартконтрактами на ланцюгу.
Процес оновлення: коли користувач взаємодіє з деякими DApps у ланцюжку, Metamask активно нагадуватиме користувачу, що поточну транзакцію можна завершити, оновивши до смарт-облікового запису та використовуючи пакетне надсилання. Наприклад, якщо ви обмінюєте деякі токени на Uniswap, натисніть кнопку «Використовувати розумний обліковий запис», щоб перейти на смарт-акаунт, і тоді авторизація токенів та обмін будуть здійснюватися пакетами в одній транзакції.
2.3 Переключитися назад на звичайний EOA
Незалежно від того, чи використовуються активні чи пасивні оновлення для перетворення поточного рахунку в смартрахунок, його прив'язана адреса Delegator Contract буде постійно зберігатися в ланцюгу як поточна логіка виконання рахунку.
Якщо ви хочете відновити звичайний EOA свого облікового запису, вам потрібно вручну ініціювати операцію «повернутися до EOA». Суть цієї операції полягає в поданні address)0( як нової адреси контракту делегатора з єдиною авторизацією EIP-7702. Коли транзакція буде успішно завантажена в ланцюжок, поле коду облікового запису буде очищено, логіка виконання відновиться до порожнього коду за замовчуванням, а обліковий запис буде відкочено до нормального стану EOA.
Увійдіть у розділ деталей облікового запису гаманця, натисніть кнопку перемикання, щоб переключити користувача з Ethereum Mainnet назад на звичайний EOA обліковий запис.
Натиснувши підтвердження, чекайте, поки транзакція буде додана в блокчейн. Успішне додавання в блокчейн означає, що користувач вже переключився з розумного рахунку на звичайний EOA-рахунок. Конкретну інформацію про транзакцію також можна знайти на сторінці поточної адреси гаманця на etherscan.
Два, приклад фішингової атаки 7702
24 травня #InfernoDrainer рибальська група використала функцію масового виконання контракту Metamask 7702-Delagator для масового шахрайства з токенами користувачів (0xc6D2…06DC) та здійснила фішинг-атаку, завдавши збитків понад 14,6 тисячі доларів США у $HashAI $HUMANS $ParallelAI $NeuralAI $DSync $Zero1 $NodeAI $Sensay $Virtual.
Виклик методу 0xe9ae5c53 через 0xc6D289d5...0d2E606DC на 0xc6D289d5...0d2E606DC | Успіх | Трав-23-2025 02:31:35 PM )UTC(
etherscan.io
)PinkDrainer експериментує з більш прихованими та впливовими методами використання 7702 в риболовлі чорної індустрії.
Згідно з нашим дослідженням, наразі риболовні злочинні угруповання #InfernoDrainer 和 #PinkDrainer займаються дослідженням та експериментами щодо більш прихованого та масштабного використання 7702 в риболовній чорній індустрії. Відповідні адреси наведені нижче, ми також опублікуємо більш детальний звіт у подальшому:
Осушувач Inferno:
0x0000db5c8B030ae20308ac975898E09741e70000
Рожевий дренаж:
0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624
Три, Рекомендації з безпеки
Постачальник гаманців:
Зверніться до впровадження та управління безпекою Metamask для делегатора 7702, який забороняє користувачам авторизувати довільні делегатори та дозволяє працювати лише в додатку. Нагадайте користувачам, що будь-яка спроба дозволити користувачу входити через веб-сторінку є фішинговою атакою.
Перевірте, чи мережа відповідає поточній мережі, і попередьте користувача про ризик повторного використання підпису з chainID 0.
Показувати цільовий смартконтракт під час підписання та авторизації користувачем, під час масового виконання через Делегатора показувати конкретний вміст виклику функцій, зменшуючи ризик фішингових атак.
Користувач:
Захист приватних ключів завжди є найважливішим. Not your keys, not your coins.
Не надавайте Delegator авторизацію на основі будь-яких незалежних веб-сторінок, безпечна авторизація зазвичай відбувається тільки в додатку, як у Metamask.
При використанні будь-якого гаманця для підпису, будь ласка, уважно ознайомтеся з вмістом підпису, щоб уникнути сліпого підпису або помилкового підпису.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Глибина ще раз відтворює 7702 принцип риболовної атаки, Гаманець і користувач як повинні запобігти?
EIP-7702 надає адресам можливості та гнучкість, подібні до смартконтрактів, все більше додатків 7702 постійно створюються, що є вкрай важливим для залучення більшої кількості людей у Web3 та покращення користувацького досвіду.
Однак гнучкість 7702 і той факт, що більшість користувачів не знайомі з 7702, використовуються шахрайськими синдикатами, і нещодавно ми спостерігали, що деяким користувачам довелося авторизувати більше десятка взаємодій через здатність Metamask 7702 виконувати пакети, а фішингова банда #InfernoDrainer об'єднана в одну транзакцію, що призвело до крадіжки активів.
Пояснення: Metamask сам по собі не має проблем із безпекою, Metamask ставить безпеку користувачів на перше місце, надаючи можливості, пов'язані з 7702, і вживає багато заходів безпеки. Користувачам потрібно більше дізнатися про можливості 7702 та пов'язані ризики, щоб запобігти повторенню таких інцидентів із безпекою.
О, Metamask 7702 Delagator підпис авторизації принципи та безпекове проєктування
За допомогою авторизації користувача, вже розгорнутого Делегаторського Контракту, поле code облікового запису користувача вказується на цей контракт. Актуальна адреса офіційного Делегаторського Контракту MetaMask: 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B
Авторизаційна структура: (chainId, delegatorAddress, nonce, signature) записати в authorization_list
Метод підпису: Metamask використовує уніфіковану логіку підпису для транзакцій авторизації, пов'язаних з EIP-7702, тобто метод signEIP7702Authorization, і digest7702 = keccak256(0x05 ‖ RLP(chainId, делегатор, nonce)) підпис ECDSA, згенеруйте структуру підпису (v, r, s) та прикріпіть її до наступних транзакцій типу 4 для реалізації авторизації та оновлення облікового запису, як описано в:
Метод верифікації: рівень консенсусу завершує перевірку за допомогою ecrecover(digest7702, sig) == tx.from.
Дизайн безпеки: веб-клієнт не може спонукати користувачів авторизувати довільних делегаторів, оскільки метод авторизації signEIP7702 реалізований лише всередині гаманця MetaMask і не відкритий для веб-клієнта через window.ethereum**. Метод підпису, доступний на вебсторінці **, наприклад eth_signTypedData_v4 не застосовується до авторизованих підписів EIP-7702, а формат підсумку підпису такий:
А формат підпису, вимогами якого визначається EIP-7702, є:
Оскільки eth_signTypedData_v4 завжди містить префікс 0x1901, а процес обчислення дайджесту абсолютно відрізняється від 7702, то навіть при вмілому конструюванні domainSeparator, primaryType та message, майже неможливо зробити так, щоб digest712 == digest7702.
Таким чином, Інтернет не може підробити законний підпис авторизації 7702 за допомогою цього методу. Крім того, MetaMask також реалізує механізм білого списку для адрес делегаторів, який діє за замовчуванням і дозволяє лише авторизований офіційний делегатор (0x63c0... 32B), який забороняє DApps самостійно впроваджувати адреси, додатково запобігаючи спонуканню користувачів підписувати шкідливі дані авторизації делегатора.
Поточний спосіб оновлення існуючого EOA в Metamask до 7702 смартконтракту (Smart Account) поділяється на два основні типи: активне оновлення та пасивне оновлення.
Активне оновлення означає, що користувач на інтерфейсі гаманця активно натискає кнопку "Переключити", авторизуючи певний Delegator Contract.
Пасивне оновлення відбувається, коли користувач взаємодіє з певними DApp, які підтримують 7702, після того, як Metamask виявляє відповідну операцію, автоматично з'являється підказка, яка рекомендує користувачу завершити оновлення.
2.1 Активне оновлення:
Торгова інформація: включає лише дії з оновлення облікового запису, а саме уповноваження конкретного Delegator Contract.
Процес оновлення: перейдіть до інтерфейсу деталей облікового запису гаманця, натисніть на кнопку перемикання, показану на малюнку нижче, щоб оновити користувача з Ethereum Mainnet до смартконтракту. Після натискання на перемикання з'явиться вікно підпису користувача для поточної угоди на оновлення:
Запис авторизації: Після підтвердження дочекайтеся, поки транзакція з'явиться в ланцюжку, що означає, що користувач успішно перейшов на смарт-аккаунт, і може переглянути конкретну інформацію про транзакцію авторизації з **Авторизацій 01928283702(** на сторінці поточної адреси гаманця на etherscan.
2.2 Пасивне оновлення
Торговий зміст: включає дії з оновлення облікового запису та пакетні дії взаємодії з смартконтрактами на ланцюгу.
Процес оновлення: коли користувач взаємодіє з деякими DApps у ланцюжку, Metamask активно нагадуватиме користувачу, що поточну транзакцію можна завершити, оновивши до смарт-облікового запису та використовуючи пакетне надсилання. Наприклад, якщо ви обмінюєте деякі токени на Uniswap, натисніть кнопку «Використовувати розумний обліковий запис», щоб перейти на смарт-акаунт, і тоді авторизація токенів та обмін будуть здійснюватися пакетами в одній транзакції.
2.3 Переключитися назад на звичайний EOA
Незалежно від того, чи використовуються активні чи пасивні оновлення для перетворення поточного рахунку в смартрахунок, його прив'язана адреса Delegator Contract буде постійно зберігатися в ланцюгу як поточна логіка виконання рахунку.
Якщо ви хочете відновити звичайний EOA свого облікового запису, вам потрібно вручну ініціювати операцію «повернутися до EOA». Суть цієї операції полягає в поданні address)0( як нової адреси контракту делегатора з єдиною авторизацією EIP-7702. Коли транзакція буде успішно завантажена в ланцюжок, поле коду облікового запису буде очищено, логіка виконання відновиться до порожнього коду за замовчуванням, а обліковий запис буде відкочено до нормального стану EOA.
Увійдіть у розділ деталей облікового запису гаманця, натисніть кнопку перемикання, щоб переключити користувача з Ethereum Mainnet назад на звичайний EOA обліковий запис.
Натиснувши підтвердження, чекайте, поки транзакція буде додана в блокчейн. Успішне додавання в блокчейн означає, що користувач вже переключився з розумного рахунку на звичайний EOA-рахунок. Конкретну інформацію про транзакцію також можна знайти на сторінці поточної адреси гаманця на etherscan.
Два, приклад фішингової атаки 7702
24 травня #InfernoDrainer рибальська група використала функцію масового виконання контракту Metamask 7702-Delagator для масового шахрайства з токенами користувачів (0xc6D2…06DC) та здійснила фішинг-атаку, завдавши збитків понад 14,6 тисячі доларів США у $HashAI $HUMANS $ParallelAI $NeuralAI $DSync $Zero1 $NodeAI $Sensay $Virtual.
Шахрайська адреса
0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181
Приклад риболовних угод
Причини риболовлі
Користувач (0xc6D2…06DC) виконав шкідливу транзакцію масового авторизації:
Хеш транзакції Ethereum: 0x1ddc8cecbc... | Etherscan
Виклик методу 0xe9ae5c53 через 0xc6D289d5...0d2E606DC на 0xc6D289d5...0d2E606DC | Успіх | Трав-23-2025 02:31:35 PM )UTC(
etherscan.io
)PinkDrainer експериментує з більш прихованими та впливовими методами використання 7702 в риболовлі чорної індустрії.
Згідно з нашим дослідженням, наразі риболовні злочинні угруповання #InfernoDrainer 和 #PinkDrainer займаються дослідженням та експериментами щодо більш прихованого та масштабного використання 7702 в риболовній чорній індустрії. Відповідні адреси наведені нижче, ми також опублікуємо більш детальний звіт у подальшому:
Осушувач Inferno:
0x0000db5c8B030ae20308ac975898E09741e70000
Рожевий дренаж:
0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624
Три, Рекомендації з безпеки
Постачальник гаманців:
Зверніться до впровадження та управління безпекою Metamask для делегатора 7702, який забороняє користувачам авторизувати довільні делегатори та дозволяє працювати лише в додатку. Нагадайте користувачам, що будь-яка спроба дозволити користувачу входити через веб-сторінку є фішинговою атакою.
Перевірте, чи мережа відповідає поточній мережі, і попередьте користувача про ризик повторного використання підпису з chainID 0.
Показувати цільовий смартконтракт під час підписання та авторизації користувачем, під час масового виконання через Делегатора показувати конкретний вміст виклику функцій, зменшуючи ризик фішингових атак.
Користувач:
Захист приватних ключів завжди є найважливішим. Not your keys, not your coins.
Не надавайте Delegator авторизацію на основі будь-яких незалежних веб-сторінок, безпечна авторизація зазвичай відбувається тільки в додатку, як у Metamask.
При використанні будь-якого гаманця для підпису, будь ласка, уважно ознайомтеся з вмістом підпису, щоб уникнути сліпого підпису або помилкового підпису.