Ledger не взламывали, но обновиться всё равно нужно: разбор уязвимостей Ethereum-приложения

OneKey действительно воспроизвела уязвимость, позволявшую подменить транзакцию в старой версии Ethereum-приложения Ledger — 1.22.1. Но демонстрация проходила в контролируемой лабораторной среде. Ledger утверждает, что исправила проблему ещё в версии 1.22.2, до публичного распространения результатов теста, и не нашла свидетельств атак на пользователей. 31731

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

Что именно воспроизвела OneKey

Уязвимость получила обозначение LSB-023. Она была связана с обработкой команд во время просмотра транзакции на экране устройства. Хост мог отправить новую APDU-команду, пока предыдущая ещё ожидала ответа пользователя. Параметры подписи при этом оставались в общем состоянии приложения, поэтому их потенциально можно было изменить после отображения на экране, но до создания подписи. 3

Проще говоря, Ledger мог показать транзакцию A, а подписать транзакцию B. Команда OneKey Anzen воспроизвела такое поведение на устаревшем приложении 1.22.1 в лаборатории. Это подтверждает работоспособность уязвимого сценария в старом ПО, но само по себе не доказывает компрометацию производственной инфраструктуры Ledger или кошельков пользователей. 172332

По словам Ledger, проблему обнаружили в рамках собственной процедуры проверки безопасности. Защита на уровне приложения появилась в версии Ethereum 1.22.2, а исправления базового механизма были также внесены в Secure SDK 26.6.1. 172124

Были ли взломаны пользователи?

Позиция Ledger сформулирована однозначно: «Ни один пользователь Ledger не был взломан». В доступных публикациях нет сообщений о потерях, связанных с воспроизведением OneKey, а Ledger заявляет, что не обнаружила эксплуатации уязвимости в реальных условиях. 172031

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

Какие проблемы исправила версия 1.22.3

Обновление 1.22.3 устранило ещё две уязвимости Ethereum-приложения, которые оставались актуальными после выпуска 1.22.2. В бюллетенях Ledger они обозначены как LSB-024 и LSB-025. 46

LSB-024: пакет из 257 операций мог отображаться неполностью

LSB-024 была связана с обработкой целого числа и количества операций при так называемом clear signing — понятном отображении пользователю содержимого операции перед подписью.

Специально сформированный пакет из 257 операций мог привести к тому, что устройство показывало только последнюю операцию, хотя подписывало весь пакет.

Это проблема целостности проверки транзакции. Пользователь по-прежнему мог увидеть запрос на подтверждение, но отображаемая информация не описывала полностью то, что фактически подписывалось. Ledger называет этот баг обходом clear signing из-за усечения счётчика массива. 46

LSB-025: вместо платежа при обмене могло подставляться разрешение

LSB-025 касалась сценария обмена токенов. Скомпрометированный провайдер обмена мог заменить ожидаемый платёж на разрешение для токена — approve — без дополнительного запроса на устройстве. Ledger описывает проблему как принятие разрешения на токен вместо платежа в процессе обмена. 46

Важны и ограничения этой уязвимости. Доступные данные не описывают её как способ создать неограниченное разрешение или одобрить произвольный адрес, выбранный атакующим. Тем не менее пользователь мог подписать разрешение, которого не собирался давать, вместо ожидаемой платёжной операции. 46

Почему эти исправления не вошли в версию 1.22.2?

Согласно опубликованным материалам, изменения для LSB-024 и LSB-025, предположительно, были подготовлены или объединены в кодовой базе за несколько месяцев до выхода версии 1.22.2. Однако в приложение 1.22.2 они не попали и появились только в 1.22.3. 37

Публичных авторитетных данных, которые позволяли бы точно установить причину, недостаточно. Это могло быть связано с планированием релиза, интеграцией, тестированием или другим внутренним решением. Поэтому корректный вывод ограничивается следующим: исправления LSB-024 и LSB-025 не вошли в 1.22.2, а точная причина публично не объяснена. Более уверенные утверждения вышли бы за пределы доступных свидетельств.

Что эта история говорит о модели безопасности Ledger

Ledger подчёркивает, что обновляемая архитектура — это преимущество: уязвимости в приложениях устройства и вспомогательном Secure SDK можно исправлять и распространять через обновления. В идеальном сценарии процесс выглядит так: команда обнаруживает проблему, готовит исправление, выпускает его, а затем публикует техническую информацию. LSB-023 Ledger приводит как пример такого подхода: уязвимость обнаружили внутри компании, исправили, а позднее описали в бюллетене безопасности. 3

У этой модели есть очевидный плюс: обнаруженная программная ошибка не обязательно остаётся в устройстве навсегда. Но есть и практическое условие для пользователя: патч защищает кошелёк только после фактического обновления приложения. А неполный или поэтапный релиз может оставить связанные проблемы нерешёнными — что и показывает разрыв между версиями 1.22.2 и 1.22.3. 37

Кроме того, аппаратный кошелёк не устраняет все риски со стороны компьютера, браузера, децентрализованных приложений и сервисов обмена. В описанных сценариях важную роль играла граница взаимодействия между подключённым хостом или провайдером и приложением Ledger. 328

Что делать пользователям Ledger

1. Обновите Ethereum-приложение минимум до версии 1.22.3. Версия 1.22.2 содержала исправление LSB-023, а версия 1.22.3 закрыла LSB-024 и LSB-025. 1737
2. Устанавливайте обновления через Ledger Live и официальные каналы Ledger. В инструкции Ledger приложение Ethereum устанавливается через менеджер Ledger Live. 7
3. Проверяйте каждый запрос на самом устройстве, особенно во время обмена. Если вместо ожидаемого платежа или обмена появляется запрос на разрешение токена, остановите операцию и отклоните её.
4. С осторожностью подписывайте крупные или непрозрачные пакетные операции. По возможности избегайте blind signing — подписания операций, содержимое которых нельзя полноценно проверить на экране устройства.
5. Считайте подключённый компьютер, браузер и провайдеры частью модели угроз. Вредоносное ПО, заражённая веб-страница, скомпрометированное децентрализованное приложение или сервис обмена могут создавать дополнительные риски.
6. Проверьте разрешения на использование токенов, если вы совершали обмены или подписывали approve на уязвимой версии приложения. Ненужные разрешения стоит отозвать через надёжный интерфейс управления разрешениями.
7. Не устанавливайте обновления по ссылкам из писем, рекламных объявлений или всплывающих окон. Используйте Ledger Live, загруженный из официального источника.

Главный вывод прост: OneKey показала реальную уязвимость в устаревшем Ethereum-приложении Ledger, но доступные данные не свидетельствуют о действующем взломе Ledger или краже средств пользователей. При этом игнорировать ситуацию не стоит: LSB-024 и LSB-025 показывают, что установка первого доступного исправления не всегда означает завершение всей истории с безопасностью.