Канадские владельцы биткойнов оказались самой многочисленной группой, пострадавшей от продолжающейся атаки на аппаратный кошелек Coldcard, на долю которой приходится 25% всех связанных с ней убытков. Аналитики отмечают, что такая высокая региональная концентрация убытков соответствует сильному местному присутствию материнской компании Coldcard — Coinkite, штаб-квартира которой находится в Торонто.
Согласно визуальному анализу Chainalysis, Австралия занимает второе место среди стран, наиболее сильно пострадавших от атаки, на долю которой приходится от 15% до 20% общего ущерба. Между тем США и Таиланд идут следом с убытками в диапазоне от 10% до 15%. Хотя утечка сильнее всего ударила по англоязычным странам и юрисдикциям, рано принявшим биткоин, данные свидетельствуют о широких глобальных последствиях в Западной Европе, Латинской Америке и ключевых африканских криптоцентрах, таких как Нигерия и Южная Африка.
Общая сумма похищенных активов в результате инцидента достигла 116 миллионов долларов. В ходе анализа инцидента компания Galaxy Research определила обновление прошивки, выпущенное в марте 2021 года — а именно внедрение нового генератора случайных чисел — как единственную точку отказа, которая сделала возможной атаку.
«Проблема заключалась в том, что он был подключен неправильно и по умолчанию использовал более слабый генератор. Сбой произошел незаметно, без каких-либо предупреждений. Никто не знал, что их закрытые ключи генерировались с низкой энтропией», — заявили в Galaxy Research. «Пять лет спустя злоумышленник за 41 минуту похитил 70 млн долларов из 1200 кошельков».
Объясняя, почему стандартные проверки не обнаружили эту ошибку на протяжении более пяти лет, Натали Ньюсон, старший специалист по расследованиям в области блокчейна в CertiK, сообщила, что первопричина заключалась в конкретной ошибке конфигурации: переменная MICROPY_HW_ENABLE_RNG была установлена в ноль.
«Для статической проверки #ifndef макрос, установленный в 0, по-прежнему считается определённым», — пояснила Ньюсон. «Проверка безопасности возвращала значение true, подавляя защиту #error и позволяя системе сборки продолжать работу так, как будто всё было настроено правильно».
Протоколы реагирования на инциденты и экстренного устранения неполадок
Чтобы предотвратить подобные незаметные переходы на программную псевдослучайность, Ньюсон призвала производителей пересмотреть свои архитектурные стандарты. «Самый надежный способ контроля — удалить резервный механизм из производственной среды и иметь ровно одного утвержденного поставщика ГСЧ», — подчеркнула она, отметив, что весь путь от получения энтропии до генерации начального числа должен строго укладываться в границы валидации, определенные стандартом NIST FIPS 140-3.
Говоря об управлении операционным риском, связанным с поспешным выпуском экстренных исправлений в ходе активных автоматизированных проверок, Ньюсон подчеркнула, что при реагировании на инциденты необходимо уделять первоочередное внимание информированию пользователей наряду с техническим тестированием.
«Приоритетом должно быть немедленное информирование о масштабах уязвимости, выявление затронутых пользователей и предоставление четких рекомендаций по снижению риска, при этом тщательно проверяя любое исправление перед выпуском», — заявила Ньюсон, добавив, что прозрачность не менее важна, чем само исправление.
Для нетехнических пользователей, владеющих скомпрометированными семенными фразами и опасающихся вывода своих устройств из строя во время экстренных обновлений прошивки, Ньюсон рекомендовал строгий протокол устранения проблемы: во-первых, пользователи должны приобрести надежный аппаратный кошелек, сгенерировать новую семенную фразу в автономном режиме и проверить настройку с помощью небольшой тестовой транзакции. Затем им следует перевести все оставшиеся средства на вновь проверенную конфигурацию, прежде чем пытаться обновить прошивку на исходном устройстве.
Ньюсон также призвал пользователей избегать создания «единственной точки отказа», используя аппаратные кошельки разных производителей для распределения риска между несколькими счетами.
Переломный момент для концепции самостоятельного хранения
Этот инцидент заставил отрасль самостоятельного хранения и её сторонников столкнуться с фундаментальными вопросами о стандартных моделях безопасности. Критики указывают на внезапное исчезновение неактивных, долгосрочных активов как доказательство того, что одно только офлайн-исполнение не гарантирует абсолютной защиты.
Нанак Нихал Халса, соучредитель Human.tech, заявил, что этот инцидент подчеркивает неизменную реальность рисков, связанных с участием третьих сторон в экосистемах аппаратных кошельков.
«В лозунге „Не твои ключи — не твои монеты“ упускается важный факт: вы всегда передаете доверие третьим лицам, даже при самостоятельном хранении. Это лишь добавляет ещё одно доказательство того, что самостоятельное хранение не меняет этого факта», — заметил Халса, предупредив, что появляющиеся векторы угроз, такие как эксплойты с использованием ИИ, вероятно, усугубят эти риски.
Ньюсон из CertiK поддержал опасения относительно конфигураций с однократной подписью, отметив, что для массового внедрения требуются системы, построенные с учетом плавного снижения работоспособности, при котором одна-единственная ошибка — со стороны пользователя или поставщика — не приведет к потере сбережений всей жизни пользователя.
«Самохранение с одной подписью не оставляет никакого запаса на ошибку», — сказал Ньюсон. «Пользователи, полагающиеся на одно устройство, доверяют физическому оборудованию, коду и всем его зависимостям, а также проверкам контроля качества, призванным выявить любые проблемы».
Следовательно, консенсус в отрасли смещается в сторону конфигураций с участием нескольких поставщиков, с использованием многоподписей или пороговых подписей (MPC) в качестве обязательного базового стандарта.
«Да, это должно быть базовым стандартом по умолчанию», — заключил Ньюсон. «Цель состоит в том, чтобы перейти от «доверия одному устройству» к обеспечению того, чтобы ни один скомпрометированный компонент или субъект не мог переместить средства. На практике ключи подписи или доли пороговой подписи должны охватывать независимые области организационных и технологических сбоев, чтобы ни один поставщик не мог самостоятельно восстановить ключ или авторизовать транзакцию».
end-content
