Ledger odrzuca roszczenia o włamanie po tym, jak OneKey odtworzył błąd

Ledger odrzucił twierdzenia, że został zhakowany, po tym, jak zespół bezpieczeństwa Anzen firmy OneKey odtworzył błąd zastępowania transakcji w przestarzałej wersji aplikacji Ethereum Ledger.

Podsumowanie

• OneKey odtworzył atak zastępowania transakcji przeciwko wersji 1.22.1 aplikacji Ethereum Ledger w testach laboratoryjnych.
• Ledger twierdzi, że aplikacja Ethereum w wersji 1.22.2 dodała zabezpieczenia, zanim OneKey publicznie opisał swoją próbę odtworzenia w Internecie.
• Napastnik musiał mieć kontrolę nad komunikacją między urządzeniem a hostem za pomocą złośliwego oprogramowania, wrogich stron internetowych lub skompromitowanego oprogramowania portfela.
• Zabezpieczona wersja SDK 26.6.1 zablokowała przeplatane polecenia, zanim dotarły one bezpośrednio do poszczególnych aplikacji urządzenia Ledger.
• Ledger nie znalazł dowodów na to, że luka została wykorzystana przeciwko użytkownikom lub spowodowała straty w kryptowalutach.

Założyciel OneKey, Yishi Wang, powiedział 27 sierpnia, że badacze zakończyli atak przeciwko aplikacji Ethereum w wersji 1.22.1 w laboratorium. Ledger potwierdził istnienie podstawowej luki, ale stwierdził, że już załatał dotkniętą aplikację, zanim OneKey opublikował swoją demonstrację.

Błąd Ethereum Ledger naruszył gwarancję zaufanego wyświetlania

Luka dotyczyła komunikacji między urządzeniem Ledger a jego podłączonym hostem. Aplikacje Ledger otrzymują instrukcje zwane poleceniami jednostki danych protokołu aplikacji (APDU) z oprogramowania portfela, stron internetowych lub innych interfejsów.

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

W takim 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 od momentu sprawdzenia do momentu użycia. Jego komunikat prasowy stwierdził, że luka zniweczyła ochronę zaufanego wyświetlania, którą portfele sprzętowe wykorzystują, aby umożliwić klientom weryfikację kwot, adresów i działań umownych przed podpisaniem.

Problem nie ujawniał fraz seed ani nie wydobywał kluczy prywatnych z elementu zabezpieczającego. Zamiast tego mogło to spowodować, że chroniony klucz podpisywał parametry różne od tych, które były wyświetlane użytkownikowi.

Wykorzystanie wymagało skompromitowanego połączenia

Napastnik musiał mieć kontrolę nad komunikacją między aplikacją Ledger a jej hostem. Ledger wymienił złośliwe oprogramowanie, skompromitowaną aplikację portfela lub wrogą stronę internetową z dostępem WebHID lub WebUSB jako możliwe drogi.

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

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

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

Ledger kwestionuje, czy test liczy się jako włamanie

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

Dyrektor technologiczny Ledger, Charles Guillemet, zakwestionował to określenie. Powiedział, że "odtworzenie już załatanej luki nie jest 'włamaniem do Ledger'" i scharakteryzował pracę OneKey jako ćwiczenie laboratoryjne przeciwko starszej aplikacji.

Historia wersji wspiera bardziej precyzyjny harmonogram. Aplikacja Ethereum w wersji 1.22.2, wydana 13 sierpnia, była pierwszą aktualizacją aplikacji zawierającą kontrole stanu zaprojektowane w celu zatrzymania udokumentowanej ścieżki zastępowania transakcji.

Ledger następnie wydał Secure SDK 26.6.1 21 sierpnia. Ta aktualizacja blokuje przeplatane polecenia, zanim kod aplikacji je otrzyma. Aplikacje zostały następnie odbudowane przy użyciu poprawionego SDK.

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

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

Użytkownicy muszą aktualizować aplikacje za pośrednictwem Ledger Live

Ledger stwierdził, że nie znalazł dowodów na to, że napastnicy 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 urządzenia i zweryfikować wersję aplikacji Ethereum na portfelu sprzętowym. Aktualizacja samego oprogramowania układowego nie zastępuje aplikacji zbudowanych przy użyciu dotkniętego SDK.

Deweloperzy zewnętrzni muszą również przejrzeć swoje zarządzanie stanem i odbudować aplikacje z Secure SDK 26.6.1 lub nowszym. Ledger stwierdził, że słabość została wprowadzona w sierpniu 2025 roku i dotyczyła wersji SDK do 26.6.0.

Ujawnienie następuje po innych poprawkach zabezpieczeń portfeli sprzętowych. W związku z tym, BitBox naprawił dwie luki dotyczące instalacji oprogramowania układowego i obsługi adresów Bitcoin, również bez zgłaszania potwierdzonego wykorzystania.