Ledger nie został zhakowany? OneKey odtworzył błąd, a aktualizacje naprawiły trzy luki

OneKey odtworzył rzeczywistą lukę umożliwiającą podmianę transakcji w starszej aplikacji Ethereum Ledger 1.22.1, ale test przeprowadzono w kontrolowanym środowisku laboratoryjnym. Ledger twierdzi, że problem został naprawiony w wersji 1.22.2, zanim demonstracja stała się publiczna, oraz że nie znalazł dowodów na ataki wymierzone w użytkowników. 31731

Sprawa zwróciła jednak uwagę na szerszy problem. Bezpieczeństwo portfela sprzętowego zależy nie tylko od odizolowania kluczy prywatnych, lecz także od tego, czy urządzenie rzeczywiście wyświetla tę samą transakcję, którą ostatecznie podpisuje.

Co odtworzył zespół OneKey

Luka oznaczona przez Ledger jako LSB-023 dotyczyła przeplatania poleceń podczas przeglądania transakcji na urządzeniu. Host — na przykład komputer lub aplikacja połączona z portfelem — mógł przesłać nowe polecenie APDU, gdy wcześniejsze nadal oczekiwało na odpowiedź użytkownika. Ponieważ parametry podpisywania pozostawały w pamięci współdzielonej podczas tego procesu, można było potencjalnie zmienić je po wyświetleniu na urządzeniu, ale przed utworzeniem podpisu. 3

W praktyce ekran mógł pokazywać transakcję A, podczas gdy urządzenie podpisywało transakcję B. Zespół bezpieczeństwa OneKey Anzen odtworzył takie zachowanie w laboratorium, korzystając z nieaktualnej aplikacji Ethereum 1.22.1. Potwierdza to możliwość wykorzystania starej wersji oprogramowania, ale nie dowodzi przejęcia produkcyjnych systemów Ledgera ani urządzeń użytkowników. 172332

Ledger informuje, że zidentyfikował lukę w ramach własnego procesu bezpieczeństwa i wprowadził zabezpieczenia w aplikacji Ethereum 1.22.2. Według dostępnych informacji problem leżący u podstaw błędu został również naprawiony w Secure SDK 26.6.1. 172124

Czy ktoś został zhakowany?

Stanowisko Ledgera było jednoznaczne: „Żaden użytkownik Ledgera nie został zhakowany”. Dostępne materiały nie opisują strat powiązanych z demonstracją OneKey, ale tego stwierdzenia nie należy rozumieć jako dowodu, że wykorzystanie luki w podatnej wersji było niemożliwe. Oznacza ono brak zaobserwowanych ataków na użytkowników. 172031

To ważne rozróżnienie. Test laboratoryjny może potwierdzić, że podatna ścieżka kodu działa w określonych warunkach, ale sam w sobie nie pokazuje, że przestępcy wykorzystali ją w rzeczywistym świecie.

Dwie kolejne luki usunięte w wersji 1.22.3

Wersja 1.22.3 naprawiła dwa dodatkowe problemy w aplikacji Ethereum, które nadal pozostawały istotne po aktualizacji do 1.22.2. Indeks biuletynów bezpieczeństwa Ledgera oznacza je jako LSB-024 i LSB-025. 46

LSB-024: partia operacji mogła ukryć większość transakcji

LSB-024 dotyczyła obsługi licznika operacji w funkcji clear signing, czyli trybie pozwalającym użytkownikowi czytelnie zweryfikować dane podpisywanej transakcji. Specjalnie przygotowana partia zawierająca 257 operacji mogła sprawić, że urządzenie wyświetliłoby tylko ostatnią z nich, mimo że podpisywałoby całą partię.

Była to awaria integralności procesu przeglądu transakcji. Użytkownik nadal mógł być poproszony o potwierdzenie, lecz informacje pokazane na ekranie nie opisywałyby wiernie całego podpisywanego pakietu. Ledger określa ten problem jako „obejście clear signing przez obcięcie licznika tablicy”. 46

LSB-025: płatność w ramach wymiany mogła zostać zastąpiona zgodą na token

LSB-025 dotyczyła procesu wymiany tokenów. Zhakowany lub przejęty dostawca usługi swap mógł podstawić zgodę na użycie tokena w miejsce oczekiwanej płatności, bez wywoływania kolejnego komunikatu na urządzeniu. Ledger opisuje ten błąd jako akceptowanie zgody na token zamiast płatności w procesie swapu. 46

Istotne są jednak ograniczenia tej luki. Nie została ona opisana jako mechanizm pozwalający utworzyć nieograniczone uprawnienie ani zatwierdzić dowolnie wybrany przez atakującego adres. Mimo to użytkownik mógł podpisać zgodę, której nie zamierzał udzielić — a to zasadniczo różni się od oczekiwanej płatności w ramach wymiany. 46

Dlaczego LSB-024 i LSB-025 nie trafiły do wersji 1.22.2?

Materiały dostępne na potrzeby tego raportu wskazują, że zmiany dotyczące obu późniejszych luk miały być gotowe lub zintegrowane już kilka miesięcy przed wydaniem wersji 1.22.2. Ostatecznie poprawki pojawiły się jednak dopiero w wersji 1.22.3. Dostępne publikacje opisują tę sytuację jako niewyjaśnione zagadnienie związane z wydaniem lub integracją zmian. 37

Brakuje wystarczająco autorytatywnej dokumentacji publicznej, aby stwierdzić, czy przyczyną były priorytety wydania, błąd integracyjny, testy czy inna wewnętrzna decyzja. Najostrożniejszy wniosek brzmi więc: poprawek nie uwzględniono w wersji 1.22.2, a dokładny powód pozostaje publicznie niewyjaśniony. Dalej idące twierdzenia wykraczałyby poza dostępne dowody.

Co ta sprawa mówi o modelu bezpieczeństwa Ledgera?

Ledger podkreśla, że możliwość aktualizowania aplikacji portfela i powiązanego oprogramowania jest elementem modelu bezpieczeństwa. Dzięki temu wykryte luki można naprawić, a poprawki rozprowadzić do użytkowników. Zakładany proces obejmuje identyfikację problemu, przygotowanie rozwiązania, wydanie aktualizacji, a następnie publikację technicznych szczegółów. LSB-023 przedstawiono jako przykład takiego podejścia: luka została wykryta wewnętrznie, załatana, a później opisana w biuletynie bezpieczeństwa. 3

To rozwiązanie ma oczywistą zaletę: wykryta luka w oprogramowaniu nie musi pozostać trwałą wadą urządzenia. Jednocześnie nakłada na użytkowników obowiązek aktualizacji. Poprawka chroni urządzenie dopiero wtedy, gdy podatna aplikacja zostanie rzeczywiście zaktualizowana, a opóźnione lub niepełne wydanie może pozostawić powiązane problemy nierozwiązane — co pokazuje różnica między wersjami 1.22.2 i 1.22.3. 37

Co powinni zrobić użytkownicy Ledgera?

1. Zaktualizujcie aplikację Ethereum do wersji 1.22.3 lub nowszej. Dostępne informacje wskazują, że wersja 1.22.3 naprawiła LSB-024 i LSB-025, natomiast poprawka na poziomie aplikacji dla LSB-023 znalazła się już w wersji 1.22.2. 1737
2. Korzystajcie z menedżera urządzenia w Ledger Live i oficjalnych kanałów dystrybucji Ledgera. Instrukcje producenta wskazują Ledger Live jako narzędzie do instalowania aplikacji Ethereum. 7
3. Czytajcie każdy komunikat wyświetlany na urządzeniu, szczególnie podczas wymiany tokenów. Jeśli portfel prosi o zgodę na użycie tokenów, choć spodziewaliście się płatności, przerwijcie operację i ją odrzućcie.
4. Zachowajcie ostrożność przy dużych lub nieprzejrzystych pakietach operacji. W miarę możliwości unikajcie podpisywania danych, których nie da się sensownie zweryfikować na ekranie urządzenia.
5. Traktujcie komputer, przeglądarkę i dostawców usług jako część modelu zagrożeń. Portfel sprzętowy nie eliminuje ryzyka związanego ze złośliwym oprogramowaniem, niebezpiecznymi stronami, przejętymi aplikacjami dApp ani dostawcami swapów. W opisanych lukach problem pojawiał się właśnie na granicy komunikacji między hostem lub usługą a aplikacją Ledgera. 328
6. Sprawdźcie udzielone uprawnienia do tokenów. Jeśli wykonywaliście swapy lub podpisywaliście zgody w czasie korzystania z podatnej wersji aplikacji, przejrzyjcie uprawnienia i cofnijcie te, które nie są potrzebne, używając zaufanego narzędzia.

Najważniejszy wniosek jest prosty: OneKey zademonstrował prawdziwą lukę w nieaktualnej aplikacji Ethereum Ledgera, ale dostępne dowody nie wskazują na trwające włamanie do portfeli użytkowników. Incydentu nie należy jednak bagatelizować. LSB-024 i LSB-025 pokazują, że zainstalowanie pierwszej dostępnej poprawki nie zawsze musi kończyć całej historii bezpieczeństwa.