Ledger odrzuca zarzuty o hack po tym, jak OneKey odtworzyło błąd

BTC
ETH
LINK
UNI
zamiana transakcjiPortfel sprzętowylukaEthereumbezpieczeństwoLedgerOneKey
1 godzinę temuŹródło: crypto.news
Ledger odrzuca zarzuty o hack po tym, jak OneKey odtworzyło błąd

Ledger odrzucił twierdzenia, że został zhakowany, po tym jak zespół bezpieczeństwa Anzen z OneKey odtworzył wadę zamiany transakcji w nieaktualnej wersji aplikacji Ethereum firmy Ledger.

Podsumowanie

  • OneKey odtworzył atak polegający na podstawieniu transakcji w aplikacji Ethereum Ledger w wersji 1.22.1 w testach laboratoryjnych.
  • Ledger twierdzi, że aplikacja Ethereum 1.22.2 dodała zabezpieczenia, zanim OneKey publicznie opisał swoją próbę odtworzenia w internecie.
  • Atakujący potrzebował kontroli nad komunikacją między urządzeniem a hostem poprzez złośliwe oprogramowanie, wrogie strony internetowe lub naruszone oprogramowanie portfela.
  • Bezpieczny SDK w wersji 26.6.1 blokował przeplatane polecenia, zanim dotarły one bezpośrednio do poszczególnych aplikacji urządzeń Ledger.
  • Ledger nie znalazł dowodów na to, że luka została wykorzystana przeciwko użytkownikom lub spowodowała straty w kryptowalutach gdziekolwiek.

Założyciel OneKey, Yishi Wang, powiedział 27 sierpnia, że badacze przeprowadzili atak na aplikację Ethereum 1.22.1 w laboratorium. Ledger potwierdził podstawową lukę, ale stwierdził, że już załatał dotkniętą aplikację, zanim OneKey opublikował swoją demonstrację.

Luka w Ethereum Ledger złamała gwarancję zaufanego wyświetlania

Luka dotyczyła komunikacji między urządzeniem Ledger a podłączonym hostem. Aplikacje Ledger otrzymują instrukcje zwane poleceniami Application Protocol Data Unit (APDU) z oprogramowania portfela, stron internetowych lub innych interfejsów.

Dotknięta aplikacja mogła przyjąć drugie polecenie APDU, podczas gdy użytkownik przeglądał wcześniejszą operację na ekranie urządzenia. Nowe polecenie mogło nadpisać parametry podpisywania przechowywane w pamięci współdzielonej bez aktualizowania wyświetlanych informacji.

W tym scenariuszu użytkownik mógł przeglądać transakcję A i zatwierdzić ją, podczas gdy aplikacja generowała podpis obejmujący transakcję B. Urządzenie nie ostrzegałoby użytkownika, że podstawowe informacje uległy zmianie.

Ledger sklasyfikował problem jako warunek wyścigu typu time-of-check do time-of-use. Jego biuletyn stwierdził, że wada pokonała ochronę zaufanego wyświetlania, którą portfele sprzętowe wykorzystują, aby umożliwić klientom weryfikację kwot, adresów i działań kontraktowych przed podpisaniem.

Problem nie ujawnił fraz początkowych ani nie wyodrębnił kluczy prywatnych z elementu zabezpieczonego. Zamiast tego mógł spowodować, że chroniony klucz podpisze parametry inne niż te pokazane użytkownikowi.

Wykorzystanie wymagało naruszonego połączenia

Atakujący potrzebował kontroli nad komunikacją między aplikacją Ledger a jej hostem. Ledger wymienił złośliwe oprogramowanie, naruszone oprogramowanie portfela lub wrogą stronę internetową z dostępem WebHID lub WebUSB jako możliwe ścieżki.

Atak nie mógł być przeprowadzony zdalnie na odłączonym urządzeniu. Użytkownik musiał również zatwierdzić transakcję, podczas gdy złośliwe oprogramowanie manipulowało oczekującym kontekstem podpisywania.

Ledger stwierdził, że wada znajdowała się w obsłudze wejścia i wyjścia jego bezpiecznego SDK, a nie w systemie operacyjnym urządzenia ani oprogramowaniu układowym. Aplikacje skompilowane z dotkniętymi wersjami SDK polegały na własnych kontrolach stanu, aby odrzucać polecenia przychodzące podczas aktywnego przeglądu.

Oznacza to, że narażenie było specyficzne dla aplikacji. Aplikacja pozostawała chroniona, jeśli każdy asynchroniczny punkt wejścia poleceń odpowiednio sprawdzał swój stan, nawet jeśli została zbudowana przy użyciu dotkniętego SDK.

Ledger kwestionuje, czy test można uznać za hack

Wang opisał wynik laboratoryjny, mówiąc: „zhakowaliśmy Ledger”. Powiedział również, że firma naprawiła problem w aplikacji Ethereum 1.22.3.

Dyrektor ds. technicznych Ledger, Charles Guillemet, zakwestionował ten opis. Powiedział, że „odtworzenie już załatanej luki to nie „hackowanie Ledger”” i określił pracę OneKey jako ćwiczenie laboratoryjne na starszej aplikacji.

Historia wersji potwierdza bardziej precyzyjną oś czasu. Aplikacja Ethereum 1.22.2, wydana 13 sierpnia, była pierwszą aktualizacją aplikacji zawierającą kontrole stanu mające na celu zatrzymanie udokumentowanej ścieżki podstawiania transakcji.

Ledger następnie wydał Secure SDK 26.6.1 21 sierpnia. Ta aktualizacja blokuje przeplatane polecenia, zanim dotrą one do kodu aplikacji. Aplikacje zostały następnie przebudowane przy użyciu poprawionego SDK.

Ledger zaleca teraz aplikację Ethereum 1.22.3 lub nowszą, ponieważ nowsze wydanie zawiera szerszą ochronę SDK i rozwiązuje kolejną wadę wyświetlania transakcji. OneKey miał zatem rację, że 1.22.3 jest chroniona, ale pierwsza poprawka na poziomie aplikacji pojawiła się w 1.22.2.

Jak wcześniej informował crypto.news, Ledger już wcześniej stwierdził, że jego luka w podpisywaniu Ethereum została naprawiona przed publicznym ujawnieniem.

Użytkownicy muszą aktualizować aplikacje przez Ledger Live

Ledger poinformował, że nie znalazł dowodów na to, aby atakujący wykorzystali LSB 023 przeciwko klientom. Żadne straty w kryptowalutach nie zostały publicznie powiązane z tym konkretnym problemem.

Użytkownicy powinni otworzyć Ledger Live, zainstalować najnowsze aplikacje na urządzeniu i zweryfikować wersję aplikacji Ethereum na portfelu sprzętowym. Aktualizacja samego oprogramowania układowego nie zastępuje aplikacji zbudowanych z dotkniętym SDK.

Deweloperzy zewnętrzni muszą również przejrzeć obsługę stanu i przebudować aplikacje z Secure SDK 26.6.1 lub nowszym. Ledger stwierdził, że słabość została wprowadzona w sierpniu 2025 r. i dotyczyła wersji SDK do 26.6.0.

Ujawnienie następuje po innych poprawkach bezpieczeństwa portfeli sprzętowych. W powiązanych doniesieniach BitBox naprawił dwie luki wpływające na instalację oprogramowania układowego i obsługę adresów Bitcoin, również bez zgłaszania potwierdzonego wykorzystania.