Ledger łata lukę w aplikacji Ethereum. Starsze wersje mogły podpisywać inną transakcję niż ta widoczna na ekranie

Podsumowanie rynku AI
Ledger załatał lukę w swojej aplikacji Ethereum (naprawioną w wersji v1.22.2), która mogła umożliwić złośliwej aplikacji internetowej wykorzystanie warunku wyścigu do podmiany danych transakcji po jej sprawdzeniu, potencjalnie zamieniając nieszkodliwe działania w szkodliwe zgody. Choć nie doszło do naruszenia kluczy prywatnych ani firmware'u i nie odnotowano potwierdzonych strat, incydent podkreśla ryzyko operacyjne dla użytkowników Ethereum/ERC-20 wchodzących w interakcje z dApps przez WebHID i może obniżyć krótkoterminowy apetyt na ryzyko w aktywności powiązanej z ETH.
Wpływ
● Średni
Aktywa, których dotyczy
ETH/USDT-1.32%
Analiza AI · ETH/USDTAnaliza AI
▼ Spadkowy
Handluj teraz
⚠️ Analizy generowane przez AI opierają się na treściach z wiadomości i mają charakter informacyjny. Nie stanowią porady inwestycyjnej ani nie odzwierciedlają poglądów BingX. Inwestowanie wiąże się z ryzykiem. Handluj odpowiedzialnie.
Użytkownicy portfeli Ledger, którzy przechowują ETH lub tokeny ERC20, powinni uruchomić Ledger Live i sprawdzić wersję zainstalowanej na urządzeniu aplikacji Ethereum. Wersje starsze niż 1.22.2 nie zawierają poprawki bezpieczeństwa. To istotne, bo błąd uderzał w kluczową obietnicę portfela sprzętowego: że ekran urządzenia pokazuje dokładnie to, co ma zostać podpisane. Sprawa stała się publiczna 24 sierpnia 2026 r., gdy firma TestMachine opublikowała analizę. Sama poprawka istniała już wcześniej. Między tymi datami pojawił się spór o to, kto odkrył lukę jako pierwszy i kiedy Ledger faktycznie ją dostarczył. Z perspektywy użytkownika ważniejsze są dwie rzeczy: czy aplikacja Ethereum ma co najmniej wersję 1.22.2 oraz jakie zgody (approvals) na tokeny mogły zostać kiedyś udzielone. Co dokładnie było podatne Błąd nie dotyczył firmware'u urządzenia ani przejęcia klucza prywatnego. Problem tkwił w aplikacji Ethereum, czyli dodatkowym module instalowanym na Ledgerze do obsługi ETH i tokenów ERC20. To ona przygotowuje transakcję, wyświetla jej szczegóły i zbiera potwierdzenie użytkownika. W podatnych wersjach możliwe było zaburzenie kolejności działań. Złośliwa aplikacja webowa mająca dostęp do podłączonego urządzenia mogła wysłać drugie żądanie podpisu, gdy pierwsza transakcja wciąż była na ekranie i czekała na weryfikację. Aplikacja mogła wtedy podmienić dane w pamięci bez wyświetlenia nowego ekranu podglądu. Na wyświetlaczu pozostawał „bezpieczny" przelew, który użytkownik właśnie sprawdził, ale potwierdzenie dotyczyło już podmienionych danych. Badacze wskazują, że schemat udało się odtworzyć na Ledger Flex. Ponieważ urządzenia w dużej mierze współdzielą kod aplikacji Ethereum, za potencjalnie narażone uznaje się też Nano X, Nano S Plus, Stax oraz Apex. Ledger nie podał, od której wersji błąd występował; analiza porównawcza badaczy startuje od 1.22.1 (oznaczonej wcześniej wersji z 27 maja 2026 r.). "Clear signing": dlaczego ekran jest podstawą bezpieczeństwa Clear signing oznacza prezentowanie pełnych danych transakcji w czytelnej formie na ekranie portfela sprzętowego przed zatwierdzeniem: adres odbiorcy, kwota, a przy wywołaniach kontraktów także czynność, którą ma wykonać smart kontrakt. To sens istnienia takiego urządzenia. Komputer może być zainfekowany, przeglądarka może wyświetlać podmieniony interfejs, a strona może być fałszywa. Dopóki niezależny ekran w Twojej dłoni pokazuje rzeczywiste dane, manipulację da się zauważyć przed naciśnięciem przycisku. W opisywanej luce klucz prywatny pozostawał bezpieczny, a firmware nie był naruszony, mimo to użytkownik mógł udzielić innej zgody niż ta, którą odczytał. Jeśli nie da się traktować ekranu jako wiążącego, w tym jednym aspekcie portfel sprzętowy zaczyna przypominać portfel programowy używany na zainfekowanej maszynie. Rdzeń problemu: race condition i komendy APDU Race condition to błąd, w którym wynik zależy od tego, które z dwóch niemal jednoczesnych poleceń zostanie przetworzone jako pierwsze. Takie usterki są zdradliwe: kod zwykle wygląda poprawnie i w większości przypadków działa bez zarzutu, a ujawnia się dopiero, gdy ktoś celowo wymusi konkretną kolejność. APDU to format komend używany do komunikacji kart inteligentnych i portfeli sprzętowych z komputerem. Proces podpisu składa się z kilku takich komend. Aplikacja Ethereum utrzymywała stan mówiący, która transakcja jest aktualnie w trakcie przeglądu. Ten stan mógł zostać nadpisany, zanim użytkownik zakończył weryfikację. WebHID w przeglądarce: skąd strona ma dostęp do urządzenia WebHID to interfejs w przeglądarce pozwalający stronie internetowej komunikować się bezpośrednio z podłączonym urządzeniem USB po uprzednim, wyraźnym udzieleniu zgody. Bez tego trudno byłoby wygodnie używać portfela sprzętowego w aplikacjach zdecentralizowanych. Z drugiej strony strona bywa „bliżej" urządzenia, niż wielu użytkowników zakłada. Opisany atak wymaga, aby wcześniej przyznać dostęp WebHID stronie zmanipulowanej lub przejętej oraz zainicjować na niej transakcję. To nie jest atak zdalny na urządzenie leżące w szufladzie. Zawęża to grono narażonych osób, ale nie zmienia faktu: użytkownicy DEX-ów, mostów czy interfejsów stakingowych regularnie udzielają takiego dostępu. Podmiana przelewu na approval: dlaczego nieograniczone zgody są ryzykowne W praktyce największe szkody w tego typu scenariuszu rzadko wynikają z samego przelewu. Kluczowe jest to, co można wstawić w jego miejsce. Token approval to zgoda dla smart kontraktu na dysponowanie określoną ilością tokenów w przyszłości bez każdorazowego potwierdzania obciążenia. Wiele aplikacji prosi o zgodę „na zawsze" i „bez limitu" dla wygody. Taka zgoda nie wygasa. Obowiązuje, dopóki użytkownik jej explicite nie cofnie. Różnica między transferem a nieograniczonym approval Transfer kosztuje dokładnie tyle, ile zatwierdzasz. Nieograniczony approval w najgorszym wypadku może kosztować cały posiadany balans danego tokena, w momencie wybranym przez podmiot, który tę zgodę posiada. Z tego powodu podmiana niewielkiego przelewu na daleko idącą zgodę jest atrakcyjnym celem w atakach na ścieżkę podpisu. Aktualizacja do 1.22.2: jak wgrać poprawkę w Ledger Live Wersja 1.22.2 zamyka opisaną ścieżkę dwoma mechanizmami: aplikacja nie pozwala rozpocząć nowej sesji podpisu, gdy trwa przegląd, oraz odrzuca potwierdzenie, jeśli stan nie odpowiada temu, co było wyświetlone. Sama aktualizacja jest prosta: podłącz urządzenie, otwórz w Ledger Live menedżer zainstalowanych aplikacji i zaktualizuj aplikację Ethereum. Salda nie są zagrożone, bo klucze wynikają z frazy odzyskiwania, a nie są przechowywane w aplikacji. Usunięcie i ponowna instalacja aplikacji również nie powoduje utraty środków. Jak sprawdzić wersję Ledger Live pokazuje numer wersji każdej aplikacji w menedżerze urządzenia. Jeśli widzisz 1.22.2 lub wyższą, poprawka jest obecna. Jeśli 1.22.1 lub niższą, urządzenie jej nie ma. Sprawdzenie wersji samego Ledger Live nie wystarcza. Dlaczego aktualizacja firmware nie aktualizuje aplikacji Ethereum To częsty punkt nieporozumień. Firmware, Ledger Live i poszczególne aplikacje coinowe są utrzymywane osobno i aktualizowane osobno. Można mieć zaktualizowany firmware, a jednocześnie przestarzałą aplikację Ethereum. W tym przypadku nie ma potrzeby generowania nowej frazy odzyskiwania. Błąd dotyczył wymienialnej aplikacji, więc wystarcza aktualizacja aplikacji. Drugi krok po aktualizacji: przegląd i cofnięcie starych approvals Aktualizacja chroni przyszłe podpisy. Nie cofa zgód, które mogły zostać udzielone wcześniej. Jeśli w ostatnich miesiącach korzystałeś z aplikacji zdecentralizowanych, warto sprawdzić aktywne approvals na swoim adresie. Eksplorery bloków i wyspecjalizowane narzędzia pokazują, które kontrakty mają prawo dysponować którymi tokenami. Zgody dla kontraktów, z których już nie korzystasz, można cofnąć pojedynczo. Cofnięcie to zwykła transakcja i wymaga opłat sieciowych, dlatego porządki najlepiej robić w okresach niższych fee. Warto pamiętać o efekcie ubocznym: każde cofnięcie pojawi się w historii transakcji i wygeneruje koszty. Osoby, które na bieżąco dokumentują takie operacje, mają później łatwiej przy rozliczeniach; popularne narzędzia podatkowe i portfolio zwykle importują te zdarzenia automatycznie. Spór o ujawnienie: Ledger kontra TestMachine Istnieją dwie wersje chronologii, które nie są ze sobą zgodne. Poniżej ujęto je jako stanowiska stron; żadnego z nich nie potwierdzono niezależnie. CTO Ledgera, Charles Guillemet, przekazał, że błąd wykryło wewnętrzne laboratorium Ledger Donjon, a poprawka została dostarczona około dwa tygodnie przed publikacją analizy. Według niego TestMachine zgłosiło się do programu bug bounty dopiero później, a komunikacja firmy miała jego zdaniem wzbudzać strach dla rozgłosu. TestMachine odpowiada, że podatność wykrył ich system testowy Azimuth podczas automatycznego przebiegu na Ledger Flex, a wyniki zostały przekazane Ledgerowi. W momencie publikacji, według firmy, poprawka nie była dostępna. Część faktów da się zweryfikować wprost: wpis w changelogu dla wersji 1.22.2 ma datę 12 sierpnia 2026 r., a podpisany tag w repozytorium źródłowym 13 sierpnia. Jako opublikowane wydanie stało się to widoczne dopiero około 24 sierpnia, równolegle z analizą TestMachine. Użytkownik, który chciał sprawdzić wcześniej, czy poprawka istnieje, nie mógł jej tam znaleźć. Techniczną rekonstrukcję osi czasu, wraz z tymi datami, zebrał CryptoSlate. Czy doszło do strat Na podstawie dotychczasowych informacji obu stron nie ma potwierdzonego przypadku faktycznego wykorzystania tej luki. Nie udokumentowano strat, a tą metodą i tak nie dało się wyprowadzić kluczy prywatnych. To dobra wiadomość, ale z zastrzeżeniem: podpis uzyskany w taki sposób wyglądałby w łańcuchu jak zwykły, dobrowolny podpis. Użytkownik mógłby zauważyć problem dopiero później, gdy tokeny zaczęłyby wypływać, i przypisać to klasycznemu phishingowi. Brak potwierdzonych przypadków nie przesądza więc, że ich nie było. Wnioski dla użytkowników portfeli sprzętowych Ta historia nie jest argumentem za porzuceniem portfeli sprzętowych. Atak wymagał wcześniej przyznanego dostępu do urządzenia i złośliwej aplikacji, nie naruszał klucza i został załatany. Praktyczny wniosek jest inny: portfel sprzętowy przenosi zaufanie z komputera na małe urządzenie z własnym ekranem, a bezpieczeństwo zależy od kilku warstw (firmware, aplikacje, oprogramowanie towarzyszące), aktualizowanych niezależnie. To nie jest stan „kup i zapomnij", tylko utrzymanie: aktualizacje aplikacji, regularne porządki w approvals i, przy większych kwotach, dodatkowa warstwa potwierdzeń. Co zrobić teraz 1) Sprawdź wersję aplikacji Ethereum i zaktualizuj. W Ledger Live w menedżerze urządzenia aplikacja musi mieć co najmniej 1.22.2. Sama aktualizacja firmware nie wystarczy. 2) Posprzątaj approvals. Sprawdź, które kontrakty mają zgody na Twoje tokeny, i cofnij te zbędne. 3) Dokumentuj operacje. Cofnięcia i przenosiny generują opłaty i ślad w historii transakcji; warto to zapisywać na bieżąco. (Stan na 25 sierpnia 2026 r. Materiał nie stanowi porady inwestycyjnej. Ceny i struktury opłat ulegają zmianom; przed zakupem sprawdź warunki u dostawcy.)