Автор: imToken
Апаратний гаманець з недоторканими оригінальними чіпами, справжньою прошивкою і навіть здатністю успішно пройти офіційну перевірку Genuine Check — чи можуть активи всередині все ще бути викрадені хакерами?
Нещодавній інцидент безпеки Ledger якраз і виявив цей, здавалося б, неможливий ризик.
Згідно з результатами розслідування, згодом оприлюдненими командою безпеки Ledger, зловмисник вбудував додатковий шкідливий ланцюг всередині ураженого пристрою, який був здатен перехоплювати мнемонічну фразу, що відображалася на екрані, та надсилати її зловмиснику через мережі мобільного зв'язку.
Іншими словами, оригінальний чіп безпеки не був скомпрометований, але мнемонічна фраза могла вже потрапити до рук хакера того ж моменту, коли вперше відобразилася на екрані.
Більше того, це не єдиний інцидент безпеки, на який варто звернути увагу останнім часом.
З вересня, від випадку Bitget із використанням вразливості стороннього продукту безпеки, до злому постачальника послуг електронної пошти Trezor — Brevo, до появи проблем безпеки в частині інфраструктури MetaMask, низка інцидентів нагадує нам, що у міру того, як Crypto-продукти стають дедалі складнішими, безпека вже не зводиться лише до захисту приватних ключів і уникнення вразливостей смарт-контрактів.
Ризики, приховані в обігу пристроїв, сторонніх послугах, внутрішніх дозволах і комунікаціях з користувачами, так само можуть стати точками входу, які шукають зловмисники.
I. Нова тривога щодо "безпеки ланцюга постачання", яку підняв Ledger
Спершу розберімо, що сталося з Ledger цього разу.
Купуючи апаратний гаманець, люди зазвичай остерігаються двох речей: купівлі підробки або отримання пристрою, який хтось інший попередньо ініціалізував.
Найпоширеніша схема в ранні роки полягала в тому, що зловмисні посередники спершу генерували мнемонічну фразу, друкували її на скретч-картці та запихали назад у пакування, розраховуючи на те, що користувачі-новачки не розумітимуть правил і одразу внесуть кошти.
Хоча ця шахрайська схема небезпечна, логіка захисту дуже чітка — використовуйте легальні канали, перевіряйте стан пристрою, спостерігайте, як пристрій сам генерує нову мнемонічну фразу, і ніколи не використовуйте готову мнемонічну фразу з коробки.
Але ця атака проти Ledger явно підвищила рівень методів. Хакер запхав додатковий електронний модуль з мікроконтролером, eSIM і можливостями стільникового зв'язку всередину корпусу. Коли користувачі вперше ініціалізують гаманець, їм зрештою потрібно прочитати мнемонічну фразу з екрана та записати її.
Іншими словами, вбудований шкідливий ланцюг аж ніяк не втручається в процес генерації мнемонічної фрази; він лише відстежує мнемонічну фразу та безпосередньо передає її назовні. Ось чому "приватний ключ не був безпосередньо витягнутий з чіпа безпеки" не означає, що інформація для відновлення гаманця користувача все ще в безпеці.
Що ще проблематичніше, навіть якщо пристрій проходить офіційну перевірку Genuine Check, він може не виявити цей додатковий апаратний компонент, оскільки перевірка справжності головним чином підтверджує ідентичність чіпа безпеки та надійність прошивки.
Тож цей інцидент справді виявив серйозний "ризик ланцюга постачання", який легко не помітити в повсякденному житті: безпека апаратного гаманця залежить не лише від чіпа та прошивки, а й від усього процесу доставки від заводу-виробника до рук користувача.
Зрештою, пристрій може пройти через кілька ланок, таких як регіональні дистриб'ютори, сторонні склади, логістика та роздрібні продавці. Будь-який учасник, який має можливість фізичного доступу до пристрою, може стати точкою ризику, що потребує додаткової оцінки.
II. Від Trezor до Bitget: як зловмисники обходять основні захисні механізми безпеки?
Зрозумівши проблему Ledger, якщо ми потім подивимося на інциденти безпеки, з якими Bitget і Trezor зіткнулися один за одним нещодавно, ми виявимо, що основна логіка разюче схожа: зловмисники так само оминали найсильнішу фронтальну лінію захисту і натомість втручалися з периферійних «сторонніх сервісів».
Спочатку подивіться на Trezor.
На початку вересня деякі користувачі Trezor отримали електронний лист із темою «Критичне попередження про безпеку: вразливість ентропії STM32», у якому стверджувалося, що апаратний гаманець має серйозну вразливість безпеки і що необхідно негайно вжити заходів.
Такі електронні листи легко змушують користувачів нервувати. Адже коли йдеться про апаратні гаманці та вразливості безпеки, ніхто не хоче, щоб його активи зазнали втрат через це.
Саме так і сталося: зловмисник використав Brevo, сторонню платформу маркетингу електронною поштою, яку використовує Trezor, щоб дозволити шкідливому вмісту потрапити до поштових скриньок користувачів через звичайну інфраструктуру надсилання електронної пошти.
Згідно з подальшим звітом Brevo про інцидент, зловмисник використав недоліки меж дозволів у своїй системі єдиного входу, щоб отримати несанкціонований доступ до інших облікових записів клієнтів, що зрештою торкнулося 138 облікових записів клієнтів, деякі з яких використовувалися для надсилання фішингових електронних листів або експорту контактних даних.
Trezor згодом підтвердив, що в результаті інциденту було експортовано 347 149 контактних адрес електронної пошти для маркетингу, а атакувальні електронні листи намагалися спонукати користувачів завантажити шкідливі програми та ввести інформацію для резервного копіювання гаманця.
Слід зазначити, що немає жодних доказів у цьому інциденті, що апаратні гаманці Trezor або системи захисту приватних ключів були скомпрометовані. Зловмисник спочатку отримав інформацію про користувачів і можливість зловживати офіційними каналами зв'язку.
Але для звичайних користувачів, які отримали електронні листи, визначити ризик стало ще складніше, оскільки електронні листи могли надходити зі знайомого офіційного домену і також могли проходити звичайні перевірки автентифікації електронної пошти, тоді як вміст уже був замінений зловмисником на фішингову інформацію.
Якщо користувачі добровільно введуть свою мнемонічну фразу через це, те, що спочатку було лише проблемою стороннього сервісу електронної пошти, може далі перерости в реальні втрати активів.
Тепер подивімося на Bitget.
24 вересня в деяких гарячих гаманцях і теплих гаманцях Bitget відбулися несанкціоновані перекази активів, що зрештою було підтверджено як такі, що стосуються приблизно 388 мільйонів доларів США.
Згідно з результатами розслідування, офіційно оголошеними Bitget, зловмисник використав вразливість у сторонньому продукті безпеки, щоб отримати облікові дані з високими привілеями всередині біржі, потім вторгся в бекенд-системи, пов'язані з гаманцями, підробив інструкції на виведення коштів, обійшов початкові перевірки контролю ризиків і спричинив потрапляння аномальних переказів у звичайний процес виконання.
Bitget заявив, що в цьому інциденті не було виявлено витоку приватних ключів, і холодні гаманці не постраждали. Це звучить дещо суперечливо: якщо приватні ключі не були викрадені, чому гроші все одно могли бути переведені?
Насправді це неважко зрозуміти.
Для кастодіальних платформ, таких як біржі, після того як користувач ініціює виведення коштів, це не означає, що людина вручну підписує кожну транзакцію приватним ключем щоразу. Натомість потрібно пройти через цілий набір внутрішніх процесів, таких як перевірка облікового запису, перевірка контролю ризиків, генерація транзакції та підписання гаманцем.
Це схоже на банківське сховище. Навіть якщо ключ від сховища зберігається дуже суворо, якщо хтось може видати себе за внутрішню особу з високими привілеями і підробити інструкцію на переказ, яка проходить затвердження, кошти зі сховища все одно можуть бути помилково переведені.
Те, що Bitget виявив цього разу, — це саме те, як ризик далі поширюється на систему виконання активів після того, як upstream-дозволи та перевірка інструкцій зазнають невдачі. Тому «приватний ключ не був викрадений» і «кошти не будуть незаконно переведені» — це насправді дві різні речі.
Що стосується інциденту безпеки інфраструктури, розкритого MetaMask наприкінці вересня, то він продемонстрував інший вимір операційного ризику.
На той момент MetaMask вжив запобіжних заходів і завчасно вивів деякі постраждалі валідатори стейкінгу. Згідно з офіційним оновленням розслідування від 1 жовтня, не було виявлено жодних ознак того, що гаманці MetaMask або кошти клієнтів постраждали, а відповідний бізнес стейкінгу не керує ключами для виведення від імені клієнтів.
Однак це не означає, що проблеми інфраструктури не матимуть інших наслідків. Некастодіальні рішення переважно вирішують питання контролю над активами, але вони не можуть автоматично усунути операційні ризики зовнішньої інфраструктури.
Якщо скласти ці події разом, нитка насправді є дуже чіткою:
- Те, що виявив Ledger, — це ризик фізичного втручання в процесі обігу апаратного забезпечення, який зрештою може призвести до крадіжки мнемонічних фраз;
- Те, що виявили Trezor / Brevo, — це ризик витоку інформації користувачів і зловживання офіційними каналами зв'язку, що не означає, що сам гаманець було скомпрометовано;
- Те, що виявив Bitget, — це ризик передачі вразливостей сторонніх продуктів до внутрішніх систем з високими привілеями, що може безпосередньо вплинути на виконання операцій з коштами;
- MetaMask, у свою чергу, нагадує нам, що контроль над активами та ризик функціонування сервісу — це не одне й те саме поняття.
Загалом, сьогоднішні криптопродукти вже не є ізольованими островами.
Гаманці покладаються на зовнішні RPC-вузли для читання даних ончейн і на агрегаційні інтерфейси для отримання ринкових котирувань; біржі не можуть обійтися без зовнішнього моніторингу безпеки, KYC-верифікації та компонентів контролю ризиків; якщо розширити ще далі, є також оператори вузлів, хмарні провайдери, системи звернень до служби підтримки та поштові системи, як-от Brevo.
Ці зовнішні сервіси роблять роботу продуктів ефективнішою, а також покращують користувацький досвід, але водночас щоразу, коли впроваджується нова зовнішня залежність, продукт набуває ще одного рівня довірчих відносин, якими потрібно керувати:
До чого можуть мати доступ треті сторони, який обсяг повноважень вони мають, і якщо їх буде скомпрометовано, чи продовжить ризик передаватися до інших ключових систем?
III. Як продукти та користувачі мають захищатися?
Зіткнувшись із дедалі складнішими ризиками залежності від третіх сторін і взаємопов'язаними відносинами залежності, очікувати, що продуктові команди відступлять до примітивного стану «не покладатися на жодні зовнішні сервіси», очевидно, нереалістично і не відповідає ринковим правилам.
Справжня майстерність архітектури безпеки полягає в мінімізації кожного можливого ризику.
Наприклад, чому SaaS-провайдер, який займається лише маркетинговими електронними листами, повинен зберігати контактні дані всіх користувачів протягом тривалого часу? Чому сторонні інструменти моніторингу безпеки можуть отримати доступ до основного виробничого середовища без незалежної багаторазової авторизації? Особливо для чутливих дій, пов'язаних із переказом коштів, внутрішні системи ніколи не повинні застосовувати «довіру за замовчуванням» і повинні впроваджувати сувору ізоляцію дозволів та незалежну перехресну перевірку.
Це також те, що в архітектурі безпеки часто називають «найменшими привілеями» та «розподілом обов'язків»: платформа для надсилання електронних листів повинна мати лише дозволи, необхідні для надсилання листів, інструменти моніторингу безпеки не повинні мати можливості довільно виконувати перекази коштів, а велике виведення коштів не повинно схвалюватися безпосередньо лише на основі інструкції, переданої з якоїсь внутрішньої системи.
Інцидент із Ledger додатково нагадує виробникам апаратних гаманців, що управління безпекою має поширюватися навіть на процес фізичного обігу продукту.
Від відвантаження з заводу, складування, логістики до доставки дилером — як побудувати відстежуваний процес управління, як виявляти аномальне розбирання або заміну пристроїв і як після виникнення проблеми визначити постраждалі партії та користувачів — усе це не повинно розглядатися як звичайна робота з управління каналами.
Тому що для апаратного пристрою, який захищає приватні ключі, сам процес доставки є частиною системи безпеки.
Звичайно, для пересічних користувачів ми не можемо ні провести аудит ланцюга постачання програмного забезпечення гаманця, ні перевірити кожну ланку складування та логістики апаратного гаманця одну за одною.
Але це не означає, що ми можемо лише пасивно нести ризик. Принаймні є кілька речей, які варто перетворити на звичку в повсякденному використанні.
По-перше, мінімізуйте непотрібних посередників у процесі придбання апаратного гаманця.
Якщо дозволяють умови, надавайте перевагу замовленню з офіційного веб-сайту бренду та доставці безпосередньо з оригінальної фабрики або офіційного складу, що зазвичай зменшує ймовірність того, що пристрій після виходу з-під контролю оригінальної фабрики буде підданий контакту, розбиранню або заміні третіми сторонами.
З точки зору управління ризиками, чим більше незалежних сторін контактують з пристроєм, тим більше ланок потребують додаткової довіри; крім того, після отримання пристрою вам все одно слід перевірити пакування та зовнішній вигляд на наявність аномалій, використати офіційне програмне забезпечення для завершення перевірки та суворо дотримуватися процесу ініціалізації.
По-друге, необхідно заново зрозуміти, чи заслуговують на довіру «офіційні повідомлення».
Інцидент з Trezor уже показав, що навіть якщо електронний лист справді надіслано через офіційно використовувану сервісну платформу, це не означає, що посилання та вимоги до операцій у ньому обов'язково є безпечними.
Особливо коли це стосується чутливих операцій, таких як оновлення гаманця, заморожування облікового запису, міграція активів і виправлення вразливостей, найкраще не переходити за посиланнями в повідомленні безпосередньо, а самостійно перевіряти через збережену вами офіційну адресу веб-сайту або вже встановлений офіційний застосунок.
Для некастодіальних гаманців, таких як imToken, користувачам так само потрібно визначати офіційні канали, використовувати token.im як основу для завантаження та встановлення, а у разі виникнення аномальної інформації надавати пріоритет перевірці через офіційні входи, такі як «Help & Feedback» у застосунку.
Незалежно від того, чи інша сторона називає себе офіційною службою підтримки, командою безпеки, чи надає на вигляд дуже професійне пояснення вразливості, ви ніколи не повинні розкривати їм свою мнемонічну фразу або приватний ключ.
Нарешті, необхідно розрізняти фактичний вплив різних інцидентів безпеки на вас самих.
Витік адреси електронної пошти переважно означає, що в майбутньому ви можете зіткнутися з більшою кількістю цільового фішингу; перехід за підозрілим посиланням вимагає подальшого підтвердження того, чи було завантажено або запущено шкідливі програми; якщо мнемонічну фразу вже було введено, це слід негайно розглядати як витік контролю над гаманцем.
Якщо було підписано підозрілі транзакції або авторизації, також необхідно поєднати конкретні операції в мережі, щоб визначити, чи існує ризик подальшої авторизації контракту.
Що стосується збоїв сторонніх сервісів або аномалій інфраструктури, то більше потрібно звертатися до офіційно розкритого обсягу впливу, щоб визначити, чи стосується це ваших активів, доступності послуг або прибутковості.
Не можна за замовчуванням доходити висновку, що приватний ключ було скомпрометовано, лише почувши про «інцидент безпеки гаманця», і тим більше не слід необачно переказувати активи на незнайомі адреси через так звані термінові повідомлення про безпеку.
Зрештою, у багатьох випадках атакуючі насправді розраховують не на прорив найсильнішої технічної лінії захисту, а на те, щоб змусити користувачів у паніці самостійно зробити останній крок (Додаткове читання: «ШІ «кидає виклик» криптографії? Web3 має готуватися до дощових днів, але ні в якому разі не повинен поспішати з міграцією»).
Остаточні думки
Раніше фраза, яку найчастіше підкреслювали в індустрії Crypto, була «Not your keys, not your coins».
Ця фраза досі важлива, оскільки контроль над приватним ключем визначає, чи можуть користувачі справді самостійно контролювати свої активи.
Але в міру того, як гаманці, біржі та фінансові продукти в мережі поступово стають зрілими, ми також повинні усвідомити, що захист приватного ключа є лише частиною всієї системи безпеки.
Справжній апаратний гаманець все ще може бути фізично підроблений під час доставки; повідомлення, справді надіслане з офіційної системи електронної пошти, також може бути використане атакуючими; а набір сторонніх інструментів, спочатку призначених для посилення безпеки, може навіть стати входом до основної системи фондів.
Ці випадки не означають, що ми повинні втратити довіру до всіх гаманців і зовнішніх сервісів. Навпаки, вони нагадують усій галузі, що безпеку потрібно розширити з меж одного продукту на весь процес ланцюга постачання, управління дозволами, комунікації з користувачами та реагування на надзвичайні ситуації.
Зрештою, по-справжньому зріла система безпеки Crypto повинна не лише гарантувати, що приватні ключі не будуть легко скомпрометовані, а й максимально забезпечувати, що навіть якщо певна зовнішня ланка дасть збій, весь механізм усе ще зможе надійно зупинити ризик на півдорозі та не допустити його перетину останньої червоної лінії захисту активів користувачів.
