Не тільки приватні ключі: від гаманців, L2 до ланцюжка поставок, як захистити межі безпеки Web3?

null

Щойно минулий червень став для криптосвіту періодом низки інцидентів безпеки, що охопили різні ланки.

Згідно з останнім щомісячним звітом безпеки PeckShield, у червні сталося 40 серйозних хакерських атак, загальні збитки сягнули 75,87 мільйона доларів США. Що більш тривожно, ці атаки не були зосереджені на якомусь одному векторі, а охопили недоліки реалізації підписів у гаманцях, вразливості протоколів L2, атаки на ланцюги постачання третіх сторін — кілька ліній оборони впали одна за одною протягом одного місяця.

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

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

Інцидент безпеки в гаманці SecondFi екосистеми Cardano в червні є найбільш показовим прикладом.

SecondFi, раніше відомий як гаманець Yorui екосистеми Cardano. З 21 по 23 червня зловмисники вивели близько 16 мільйонів ADA з адрес деяких користувачів SecondFi, що зачепило приблизно 374 гаманці. За цінами на момент інциденту це склало близько 2,4 мільйона доларів. Згодом SecondFi повідомив, що завдяки екстреним заходам вдалося додатково захистити близько 129 мільйонів ADA, які могли опинитися під загрозою.

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

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

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

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

Звісно, це дефект реалізації конкретної версії конкретного гаманця, а не загальна проблема всіх самокерованих гаманців. Наприклад, TokenCore від imToken — його сховище основного коду публічно розміщене на GitHub і охоплює базові функції гаманця, такі як управління ключами, виведення адрес і підпис транзакцій.

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

Для звичайних користувачів такі інциденти також відповідають кільком більш практичним принципам безпеки.

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

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

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

2. L2 — це не просто «дешевший Ethereum», а цілий складний ланцюжок довіри

Окрім гаманців, кілька червневих інцидентів спрямували ризики на дедалі складніші системи L2.

14 та 18 червня дві старі розгортання Rollup, пов'язані з Aztec, зазнали атак, що загалом призвело до збитків у розмірі приблизно 4,35 мільйона доларів.

Слід окремо зазначити, що атаковано було старі розгортання, такі як Aztec Connect, які вже перейшли у спадковий стан. Це не означає, що було атаковано поточну основну мережу Aztec Network, але проблеми, виявлені цими двома інцидентами, є повчальними для всієї сфери ZK Rollup.

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

Інший інцидент виник через відсутність обмежень у схемі доказу з нульовим розголошенням. Система верифікувала формально дійсний доказ, але не забезпечила повну відповідність приватного дерева стану, використаного в цьому доказі, публічному кореню стану на Ethereum, який фактично використовується для розрахунків. Тому зловмисник міг згенерувати доказ навколо підробленого дерева стану та вивести активи з контракту L1.

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

Подальший інцидент безпеки з Taiko виявив інший тип ризику довіри до L2.

22 червня процес верифікації доказів Taiko на основі SGX був використаний, що спричинило збитки приблизно 1,7 мільйона доларів. Згідно з аналізом BlockSec, зловмисник використав закритий ключ підпису SGX enclave, який раніше був викладений у публічному репозиторії GitHub. Водночас контракт верифікації в блокчейні не відхиляв Enclave в режимі DEBUG, що дозволило зловмиснику зареєструвати шкідливий доказовик як легітимний екземпляр.

Зловмисник підробив доказ стану L2, змусивши контракт на Ethereum прийняти неіснуючий стан L2, і врешті вивів активи з мостових коштів. По суті, проблема виникла через те, що ключ, який використовувався для підпису довіреного середовища виконання, став публічним, а правила віддаленої атестації не повністю перевіряли атрибути середовища виконання. У результаті «атестований» доказ втратив свою початкову довіру.

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

Це не була крадіжка активів або зовнішня атака, а технічний збій, який вплинув на доступність мережі та здатність до відновлення. Але в ширшому сенсі безпеки доступність сама по собі є частиною моделі безпеки L2.

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

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

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

3. Контракт не зламано, але послуги третьої сторони можуть принести атаку до користувача

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

25 червня Polymarket повідомив, що один із використовуваних ним сторонніх постачальників був зламаний, і зловмисник впровадив шкідливий скрипт у фронтенд Polymarket, до якого зверталися деякі користувачі.

За даними безпекових фірм та аналітиків блокчейну, інцидент призвів до втрат користувацьких активів на суму близько 3 мільйонів доларів, що зачепило приблизно 11 гаманців. Вкрадені кошти були переведені з Polygon на Ethereum і обміняні на приблизно 1893 ETH. Згодом Polymarket заявив, що усунув уражену залежність і повністю відшкодує збитки постраждалим користувачам.

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

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

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

• Використовуйте окремий гаманець для взаємодії з DApp: гаманці для довгострокового зберігання заощаджень не варто безпосередньо підключати до різних DeFi, NFT, предиктивних ринків та сайтів з еірдропами. У щоденному гаманці для взаємодії зберігайте лише кошти, призначені для нещодавнього використання. Якщо фронтенд або авторизація буде скомпрометована, вплив буде відносно обмеженим.
• Перед підписом звертайте увагу на фактичну операцію, а не дивіться лише на кнопки на веб-сторінці: на сторінці може бути написано «Увійти», «Отримати» або «Підтвердити замовлення», але це не означає, що підпис, який з'являється в гаманці, стосується тієї самої дії.
• При виникненні аномалій на сторінці не продовжуйте діяти за інерцією: якщо сторінка раптово вимагає повторно імпортувати мнемонічні фрази, завантажити додатковий плагін або якщо вміст транзакції не відповідає опису на сторінці, слід призупинити взаємодію, перевірити ситуацію через кілька офіційних каналів проекту та перевірити або відкликати історичні авторизації, які більше не використовуються.
• З точки зору продукту гаманця, це також означає, що роль гаманця змінюється. Він не повинен бути лише інструментом для зберігання закритих ключів та відображення вікна підпису. Гаманець також має допомагати користувачеві розуміти намір транзакції, виявляти аномальні авторизації, показувати зміни активів і надавати достатньо чіткі попередження перед високоризиковою взаємодією.

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

Наостанок

Раніше часто казали: хто володіє закритим ключем, той володіє активами в блокчейні.

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

Звісно, це не означає, що користувачі повинні триматися подалі від будь-яких on-chain взаємодій. Для користувачів справді ефективні звички безпеки означають окреме управління використанням активів, рівнем ризику та сценаріями взаємодії: довгострокові активи — ізоляція, щоденна взаємодія — невеликі суми, незнайомі DApp — низькі дозволи, високоризикові операції — багаторазова перевірка.

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

Бажаю всім успіху.