Під час взаємодії з DApps користувачам потрібно звернути увагу на контроль кількості авторизованих токенів, перевірку вмісту підпису та нестандартні ситуації авторизації.
Автор: Ліза
фон
11 травня користувач Twitter «pineapple.eth» написав у Twitter, що його гаманець вкрали через помилковий клік на фішинговому веб-сайті (syncswap[.]network), і він втратив понад 100 доларів.
(
Хоча сума збитків невелика, в ній прихований величезний ризик для безпеки. Жертви часто втрачають величезні активи через «непомітний» ризик «не бачити». Тому ми написали цю статтю.
За описом потерпілого, викрадені операції такі:
(
(
З цих двох транзакцій договірний абонент (0x00002…d0000) переказує 34,87 USDC на адресу жертви (0xA4089…82C3) на (0x8256…D6B8) і переказує 81,36 USDC на (0x5A69… 1C17). Якщо ви просто подивитеся на функцію transferFrom, неважко виявити, що функція цієї функції полягає в тому, щоб дозволити третій стороні ініціювати транзакцію для передачі відповідних цифрових активів з облікового запису власника на обліковий запис одержувача.
Потім проаналізуйте адресу абонента контракту (0x00002...d0000) і виявіть, що існує додаткова операція дозволу, якої немає в записах транзакцій жертви. Яка роль дозволу?
(
Що таке дозвіл?
Згідно з офіційним вступом, дозвіл було введено в протокол ERC20 в EIP-2612, і користувачі можуть взаємодіяти з контрактом програми, додаючи авторизаційний підпис (дозвіл) без попередньої авторизації. Зокрема, ми всі знаємо, що під час транзакції валюти ERC20 A може викликати функцію схвалення, щоб авторизувати B, тобто дозволити токен, указаний A, іншому обліковому запису для роботи, і повинен бути власником цього облікового запису, щоб викликати функцію схвалення. . Функція функції дозволу полягає в тому, що A підписує об’єкт авторизації заздалегідь у ланцюжку та інформує B про отриманий підпис, і B може використовувати цей підпис для виклику permit для реалізації операції авторизації A (використовуйте transferFrom для передачі дозволу ) , A може передати вказаний маркер без надсилання транзакції, і незалежно від того, є він власником облікового запису чи ні, він може виконати дозвіл на авторизацію операції. Крім того, Uniswap випустила новий стандарт авторизації токенів Permit2.
Нижче наведено порівняння між схваленням і дозволом:
функція approve(адреса usr, uint wad) зовнішні повернення (bool)
{
надбавка[msg.sender] [usr] = пачка;
…
}
дозвіл функції(
власник адреси, власник адреси,
uint256 nonce, uint256 закінчення терміну дії, bool дозволено,
uint8 v, bytes32 r, bytes32 s
) зовнішній {
…
надбавка [holder] [spender] = пачка;
…
}
Зрозумівши основи, а потім повернувшись до самої події фішингу, ви можете надіслати цю функцію дозволу з 7 параметрами:
власник: офіційна адреса
витратник: Хто уповноважений
значення: кількість наданих авторизованих маркерів
крайній термін: позначка часу, дійсна лише до вказаного часу
v, r, s: дані підпису
Серед них кінцевий термін 1714509304969, а значення 116239404, що означає, що авторизація дійсна до 00:42 22 серпня (GMT) о 56300, майже необмежений час. А кількість авторизованих токенів становить 116,239404 USDC, що дорівнює сумі, яку вкрала жертва. Значення v, r і s є даними підпису після того, як користувач (власник) підпишеться на фішинговому веб-сайті, а функція дозволу перевірить дійсність даних підпису. Після проходження перевірки підпису токен користувача буде авторизовано хакеру (витратнику).
Весь процес дуже зрозумілий: жертва підписала підпис і відправила його на фішинговий веб-сайт, але не завантажила в ланцюжок.Отримавши інформацію про підпис, хакер відправив дозвіл на ланцюжок, тобто викликав approve для авторизації . Підписання здійснюється поза мережею, не витрачаючи жодного газу. Але треба чітко розуміти, що відсутність газу тут не означає, що газу немає, а підписанту (потерпілому) не потрібно платити за газ за авторизацію та передачу.
Безсумнівно, як і схвалення авторизованого фішингу, дозвіл є більш небезпечним, ніж схвалення авторизованого фішингу, зрештою, поки підпис викрадено, авторизація отримана. Наприклад, для функції відкладеного замовлення в dex потрібно лише підписати певне повідомлення, і користувач може довірити актив dex для обробки, не сплачуючи газ. Активи користувача можуть бути втрачені. Наскільки нам відомо, деякі гаманці розшифровують і відображають інформацію підпису підтвердження фішингу авторизації, але гаманець майже не має попереджень про дозвіл фішингу підпису, і користувачі піддаються більшому ризику бути атакованими. У той же час, підпис дозволу є поведінкою поза мережею, і користувачам важко помітити, чи стався витік їхніх підписів.
MistTrack
Наразі хакерська адреса була позначена MistTrack як шкідлива фішингова адреса.
Використовуючи MistTrack для аналізу ETH, WBTC, USDT, USDC, SHIB, DAI, WETH, DAI, stETH, APE, поточний прибуток адреси 1 становить близько 120 000 доларів США, прибуток адреси 2 становить приблизно 200 000 доларів США, а прибуток адреси 3 Близько 2000 дол. Крім того, згідно з аналізом Scam Sniffer, платформи для боротьби з шахрайством Web3, станом на 9 травня загалом у понад 300 жертв було викрадено активи на суму близько 690 000 доларів США за допомогою шкідливих підписів на основі Permit2. на Uniswap до 9 травня. Наразі майже 670 000 адрес у головній мережі Ethereum авторизували Permit2. Звісно, ці дані – лише вершина айсберга для всієї картини цієї банди.
Підсумуйте
Ця стаття в основному починається з фактично вкраденої справи та представляє ризик підпису дозволу. Команда безпеки SlowMist нагадує вам не відкривати веб-сайти невідомого походження для роботи за бажанням. Під час взаємодії з DApps зверніть увагу на контроль кількості токенів, авторизованих у контракті, і ретельно перевіряйте вміст підпису. Час від часу використовуйте інструменти авторизації, такі як RevokeCash до часу (перевірте наявність ненормальної авторизації, а також Ви можете скористатися інструментом керування авторизацією для Uniswap Permit2 (щоб перевірити, чи є будь-яка ненормальна авторизація, вчасно скасуйте авторизацію.
Довідкове посилання:
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Дозволити аналіз підпису: чи можуть підписи поза ланцюгом також перехопити ваш токен?
Автор: Ліза
фон
11 травня користувач Twitter «pineapple.eth» написав у Twitter, що його гаманець вкрали через помилковий клік на фішинговому веб-сайті (syncswap[.]network), і він втратив понад 100 доларів.
(
Хоча сума збитків невелика, в ній прихований величезний ризик для безпеки. Жертви часто втрачають величезні активи через «непомітний» ризик «не бачити». Тому ми написали цю статтю.
За описом потерпілого, викрадені операції такі:
(
З цих двох транзакцій договірний абонент (0x00002…d0000) переказує 34,87 USDC на адресу жертви (0xA4089…82C3) на (0x8256…D6B8) і переказує 81,36 USDC на (0x5A69… 1C17). Якщо ви просто подивитеся на функцію transferFrom, неважко виявити, що функція цієї функції полягає в тому, щоб дозволити третій стороні ініціювати транзакцію для передачі відповідних цифрових активів з облікового запису власника на обліковий запис одержувача.
Потім проаналізуйте адресу абонента контракту (0x00002...d0000) і виявіть, що існує додаткова операція дозволу, якої немає в записах транзакцій жертви. Яка роль дозволу?
(
Що таке дозвіл?
Згідно з офіційним вступом, дозвіл було введено в протокол ERC20 в EIP-2612, і користувачі можуть взаємодіяти з контрактом програми, додаючи авторизаційний підпис (дозвіл) без попередньої авторизації. Зокрема, ми всі знаємо, що під час транзакції валюти ERC20 A може викликати функцію схвалення, щоб авторизувати B, тобто дозволити токен, указаний A, іншому обліковому запису для роботи, і повинен бути власником цього облікового запису, щоб викликати функцію схвалення. . Функція функції дозволу полягає в тому, що A підписує об’єкт авторизації заздалегідь у ланцюжку та інформує B про отриманий підпис, і B може використовувати цей підпис для виклику permit для реалізації операції авторизації A (використовуйте transferFrom для передачі дозволу ) , A може передати вказаний маркер без надсилання транзакції, і незалежно від того, є він власником облікового запису чи ні, він може виконати дозвіл на авторизацію операції. Крім того, Uniswap випустила новий стандарт авторизації токенів Permit2.
Нижче наведено порівняння між схваленням і дозволом:
функція approve(адреса usr, uint wad) зовнішні повернення (bool)
{
надбавка[msg.sender] [usr] = пачка;
…
}
дозвіл функції(
власник адреси, власник адреси,
uint256 nonce, uint256 закінчення терміну дії, bool дозволено,
uint8 v, bytes32 r, bytes32 s
) зовнішній {
…
надбавка [holder] [spender] = пачка;
…
}
Зрозумівши основи, а потім повернувшись до самої події фішингу, ви можете надіслати цю функцію дозволу з 7 параметрами:
Серед них кінцевий термін 1714509304969, а значення 116239404, що означає, що авторизація дійсна до 00:42 22 серпня (GMT) о 56300, майже необмежений час. А кількість авторизованих токенів становить 116,239404 USDC, що дорівнює сумі, яку вкрала жертва. Значення v, r і s є даними підпису після того, як користувач (власник) підпишеться на фішинговому веб-сайті, а функція дозволу перевірить дійсність даних підпису. Після проходження перевірки підпису токен користувача буде авторизовано хакеру (витратнику).
Весь процес дуже зрозумілий: жертва підписала підпис і відправила його на фішинговий веб-сайт, але не завантажила в ланцюжок.Отримавши інформацію про підпис, хакер відправив дозвіл на ланцюжок, тобто викликав approve для авторизації . Підписання здійснюється поза мережею, не витрачаючи жодного газу. Але треба чітко розуміти, що відсутність газу тут не означає, що газу немає, а підписанту (потерпілому) не потрібно платити за газ за авторизацію та передачу.
Безсумнівно, як і схвалення авторизованого фішингу, дозвіл є більш небезпечним, ніж схвалення авторизованого фішингу, зрештою, поки підпис викрадено, авторизація отримана. Наприклад, для функції відкладеного замовлення в dex потрібно лише підписати певне повідомлення, і користувач може довірити актив dex для обробки, не сплачуючи газ. Активи користувача можуть бути втрачені. Наскільки нам відомо, деякі гаманці розшифровують і відображають інформацію підпису підтвердження фішингу авторизації, але гаманець майже не має попереджень про дозвіл фішингу підпису, і користувачі піддаються більшому ризику бути атакованими. У той же час, підпис дозволу є поведінкою поза мережею, і користувачам важко помітити, чи стався витік їхніх підписів.
MistTrack
Наразі хакерська адреса була позначена MistTrack як шкідлива фішингова адреса.
Адреса 1: 0x00002644e79602F056B03235106A9963826d0000
Адреса 2: 0x82563Ba592986Cb277d67B2E7c56ab3BB3FDD6B8
Адреса 3: 0x5A697967F0791d12db8A0f92344Abc6DD07a1C17
Обидва USDC жертви були обміняні на ETH.
Використовуючи MistTrack для аналізу ETH, WBTC, USDT, USDC, SHIB, DAI, WETH, DAI, stETH, APE, поточний прибуток адреси 1 становить близько 120 000 доларів США, прибуток адреси 2 становить приблизно 200 000 доларів США, а прибуток адреси 3 Близько 2000 дол. Крім того, згідно з аналізом Scam Sniffer, платформи для боротьби з шахрайством Web3, станом на 9 травня загалом у понад 300 жертв було викрадено активи на суму близько 690 000 доларів США за допомогою шкідливих підписів на основі Permit2. на Uniswap до 9 травня. Наразі майже 670 000 адрес у головній мережі Ethereum авторизували Permit2. Звісно, ці дані – лише вершина айсберга для всієї картини цієї банди.
Підсумуйте
Ця стаття в основному починається з фактично вкраденої справи та представляє ризик підпису дозволу. Команда безпеки SlowMist нагадує вам не відкривати веб-сайти невідомого походження для роботи за бажанням. Під час взаємодії з DApps зверніть увагу на контроль кількості токенів, авторизованих у контракті, і ретельно перевіряйте вміст підпису. Час від часу використовуйте інструменти авторизації, такі як RevokeCash до часу (перевірте наявність ненормальної авторизації, а також Ви можете скористатися інструментом керування авторизацією для Uniswap Permit2 (щоб перевірити, чи є будь-яка ненормальна авторизація, вчасно скасуйте авторизацію.