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

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

Автор: imToken

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Безпосередньо після цього стався інцидент безпеки Taiko, який виявив ще один ризик ланцюга довіри L2.

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

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

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

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

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

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

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

3. Контракт не був зламаний, але треті сторони також можуть принести атаки користувачам

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

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

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

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

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

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

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

З точки зору продукту гаманця, це також означає, що роль гаманця змінюється.

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

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

На завершення

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

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

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

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

Разом до мети.