На канадських користувачів припадає 25 % збитків, пов’язаних з експлойтом Coldcard

Географічний розподіл збитків

Канадські власники біткойнів виявилися найбільшою групою, яка постраждала від триваючої атаки на апаратний гаманець Coldcard, на їхню частку припадає 25% усіх пов’язаних із нею збитків. Аналітики відзначають, що така значна регіональна концентрація збігається з потужною місцевою присутністю материнської компанії Coldcard — Coinkite, штаб-квартира якої розташована в Торонто.

Згідно з візуальним аналізом Chainalysis, Австралія посідає друге місце серед країн, що найбільше постраждали, на її частку припадає від 15% до 20% загальних збитків. Тим часом США та Таїланд йдуть слідом, їхні збитки становлять від 10% до 15%. Хоча злом найсильніше вразив англомовні країни та юрисдикції, які рано почали використовувати біткойн, дані вказують на широкі глобальні наслідки у Західній Європі, Латинській Америці та ключових африканських крипто-центрах, таких як Нігерія та Південна Африка.

Загальна сума викрадених активів у результаті інциденту сягнула 116 мільйонів доларів. Під час аналізу інциденту компанія Galaxy Research визначила оновлення прошивки, проведене в березні 2021 року — а саме впровадження нового генератора випадкових чисел — як єдину точку відмови, що уможливила атаку.

«Проблема полягала в тому, що його підключили неправильно, і за замовчуванням використовувався слабший генератор. Збій відбувся непомітно, без попередження. Ніхто не знав, що їхні приватні ключі генерувалися з низькою ентропією», — зазначила компанія Galaxy Research. «Через п’ять років зловмисник викрав 70 млн доларів із 1200 гаманців за 41 хвилину».

Пояснюючи, чому стандартні перевірки не виявили цю помилку протягом понад п’яти років, Наталі Ньюсон, старший дослідник блокчейну в CertiK, розкрила, що першопричиною стала конкретна помилка конфігурації: параметр MICROPY_HW_ENABLE_RNG був встановлений на нуль.

«Для статичної перевірки #ifndef макрос, встановлений на 0, все одно вважається визначеним», — пояснила Ньюсон. «Перевірка безпеки дала результат «true», придушивши захист #error і дозволивши системі збірки продовжувати роботу так, ніби все було налаштоване належним чином».

Протоколи реагування на інциденти та екстреного усунення проблем

Щоб запобігти подібним прихованим переходам на програмну псевдовипадковість, Ньюсон закликала виробників переглянути свої архітектурні стандарти. «Найдієвішим заходом контролю є усунення такого переходу на резервний варіант у виробничому середовищі та використання лише одного затвердженого постачальника генератора випадкових чисел», — підкреслила вона, зазначивши, що весь шлях від отримання ентропії до генерації початкового значення повинен суворо відповідати межам валідації, визначеним стандартом NIST FIPS 140-3.

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

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

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

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

Поворотний момент для концепції самостійного зберігання

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

Нанак Ніхал Халса, співзасновник Human.tech, стверджує, що цей інцидент підкреслює незмінну реальність ризиків, пов’язаних із залученням третіх сторін у екосистемах апаратних гаманців.

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

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

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

Відповідно, консенсус у галузі зміщується в бік конфігурацій із залученням декількох постачальників, багатопідписних або порогових підписів (MPC) як обов’язкової базової вимоги.

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