Ledger- og OneKey-saken forklart: Dette ble faktisk rettet – og dette må brukerne gjøre

OneKey gjenskapte en reell sårbarhet i den eldre Ledger Ethereum-appen 1.22.1, men testen ble gjennomført i et kontrollert laboratoriemiljø. Ledger sier at feilen allerede var rettet i versjon 1.22.2 før demonstrasjonen ble offentlig kjent, og at selskapet ikke har funnet tegn til angrep mot brukere. 31731

Saken viser likevel et viktig poeng: Sikkerheten i en maskinvarelommebok avhenger ikke bare av at de private nøklene holdes isolert. Enheten må også vise transaksjonen korrekt – og faktisk signere den samme transaksjonen som brukeren har godkjent.

Dette gjenskapte OneKey

Sårbarheten, som Ledger har kalt LSB-023, handlet om at kommandoer kunne flettes inn mens brukeren gjennomgikk en transaksjon på enheten. En vertsmaskin kunne sende en ny APDU-kommando mens den forrige fortsatt ventet på brukerens svar. Fordi signeringsparametere lå i en delt tilstand under gjennomgangen, kunne de i prinsippet endres etter at de var vist på skjermen, men før signaturen ble laget. 3

I praksis kunne enheten vise transaksjon A, mens den signerte transaksjon B. OneKeys Anzen-team gjenskapte denne oppførselen i en lab ved å bruke den utdaterte Ethereum-appen 1.22.1. Det dokumenterer at den gamle programvaren kunne utnyttes under de nødvendige betingelsene – ikke at Ledgers produksjonssystemer eller brukere faktisk ble kompromittert. 172332

Ledger sier at selskapet selv hadde identifisert sårbarheten gjennom sitt sikkerhetsarbeid og lagt inn beskyttelse i Ethereum-app 1.22.2. Den underliggende feilen skal også ha blitt håndtert i Secure SDK 26.6.1. 172124

Ble noen hacket?

Ledger formulerte seg kategorisk: «Ingen Ledger-bruker ble hacket.» Det tilgjengelige materialet beskriver ingen kjente tap knyttet til OneKeys demonstrasjon. Utsagnet bør likevel forstås som en beskrivelse av hva Ledger har observert – ikke som et bevis på at utnyttelse ville vært umulig i en berørt versjon. 172031

Forskjellen er viktig. En laboratorietest kan bekrefte at en sårbar kodevei fungerer under bestemte forhold, uten å vise at kriminelle har brukt den i praksis.

To ytterligere feil ble rettet i versjon 1.22.3

Versjon 1.22.3 rettet to andre sårbarheter i Ethereum-appen som fortsatt var relevante etter oppdateringen til 1.22.2. Ledgers oversikt over sikkerhetsbulletiner kaller dem LSB-024 og LSB-025. 46

LSB-024: En stor batch kunne skjule operasjoner

LSB-024 gjaldt en feil i håndteringen av heltall eller antall operasjoner ved såkalt clear signing – tydelig signering, der brukeren skal kunne kontrollere innholdet på enheten. En spesiallaget batch med 257 operasjoner kunne føre til at enheten bare viste den siste operasjonen, samtidig som den signerte hele batchen.

Dette er en integritetsfeil i transaksjonskontrollen. Enheten kunne fortsatt kreve at brukeren bekreftet, men informasjonen som ble vist, ville ikke beskrive hele innholdet som faktisk ble signert. Ledger omtaler problemet som «Clear-signing bypass via array-count truncation». 46

LSB-025: En betaling i en swap kunne bli til en token-godkjenning

LSB-025 berørte en swap-flyt. En kompromittert swap-leverandør kunne erstatte den forventede betalingen med en token-godkjenning uten å utløse et nytt spørsmål på Ledger-enheten. Ledger beskriver dette som at en swap-flyt kunne godta en token-godkjenning i stedet for en betaling. 46

Begrensningene er viktige. Sårbarheten ble ikke beskrevet som en måte å opprette en ubegrenset godkjenning på eller godkjenne en vilkårlig adresse valgt av en angriper. Den kunne likevel få brukeren til å signere en godkjenning vedkommende ikke hadde ment å gi – noe som er vesentlig forskjellig fra den forventede betalingen i en swap. 46

Hvorfor kom ikke LSB-024 og LSB-025 i 1.22.2?

Det offentlige materialet som ligger til grunn for denne saken, tyder på at de relevante endringene for de to senere sårbarhetene var slått sammen flere måneder før versjon 1.22.2 ble lansert. Likevel dukket rettelsene først opp i versjon 1.22.3. Omtalen av saken beskriver dette som et uavklart spørsmål om lansering eller integrasjon. 37

Det finnes ikke nok autoritativ offentlig dokumentasjon til å slå fast om årsaken var prioritering, en integrasjonsfeil, testing eller en annen intern beslutning. Den forsvarlige konklusjonen er derfor snevrere: Rettelsene var ikke inkludert i 1.22.2, og den nøyaktige årsaken er fortsatt offentlig uforklart. Sterkere påstander går lenger enn dokumentasjonen tillater.

Hva saken sier om Ledgers oppdaterbare sikkerhetsmodell

Ledger har fremhevet at en oppdaterbar lommebokarkitektur gjør det mulig å rette sårbarheter i enhetsapper og støtteprogramvare og distribuere rettelsene til brukerne. Modellen bygger på at en feil identifiseres, utbedres, lanseres og senere dokumenteres med tekniske detaljer. LSB-023 ble presentert som et eksempel på denne prosessen: Feilen ble identifisert internt, rettet og senere beskrevet i et sikkerhetsbulletin. 3

Fordelen er tydelig: En oppdaget programvarefeil trenger ikke å forbli permanent. Men modellen stiller også krav til brukerne. En sikkerhetsoppdatering beskytter først etter at den berørte appen faktisk er oppdatert, og en forsinket eller ufullstendig lansering kan la andre relaterte problemer stå åpne. Forskjellen mellom 1.22.2 og 1.22.3 illustrerer nettopp dette. 37

Dette bør Ledger-brukere gjøre

1. Oppdater Ethereum-appen til versjon 1.22.3 eller nyere. Omtalen av saken identifiserer 1.22.3 som versjonen som rettet LSB-024 og LSB-025, mens 1.22.2 inneholdt apprettelsen for LSB-023. 1737
2. Bruk Ledger Lives enhetsbehandler og Ledgers offisielle distribusjonskanaler når du oppdaterer apper. Ledgers veiledning sier at Ethereum-appen installeres gjennom Ledger Live. 7
3. Les alle meldinger på selve enheten nøye, særlig ved swaps. Hvis Ledger-enheten ber om en godkjenning når du forventet en betaling, bør du stoppe og avslå.
4. Vær forsiktig med uvanlig store eller uklare batcher. Unngå blind signering når det er mulig, spesielt når hele innholdet ikke kan kontrolleres meningsfullt på enheten.
5. Regn tilkoblede datamaskiner, nettlesere og tjenester som en del av trusselbildet. Sårbarhetene berørte kommunikasjonen mellom en vert eller tjeneste og Ledger-appen. En maskinvarelommebok fjerner derfor ikke risikoen fra skadevare, ondsinnede nettsider, kompromitterte desentraliserte apper eller swap-leverandører. 328
6. Kontroller token-godkjenninger etter bruk av berørt programvare. Hvis du gjennomførte swaps eller signerte godkjenninger med en sårbar appversjon, bør du se etter unødvendige godkjenninger og trekke dem tilbake gjennom en pålitelig tjeneste.

Den korte konklusjonen er denne: OneKey demonstrerte en reell feil i en utdatert Ledger Ethereum-app, men det tilgjengelige materialet viser ikke at Ledger ble utsatt for et aktivt angrep. Hendelsen bør likevel tas alvorlig. LSB-024 og LSB-025 viser at den første tilgjengelige rettelsen ikke nødvendigvis var slutten på sikkerhetshistorien.