Ledger, la vulnerabilità Ethereum spiegata: cosa ha replicato OneKey e quali aggiornamenti servono

La dimostrazione di OneKey ha riprodotto una vera vulnerabilità di sostituzione delle transazioni nella vecchia app Ethereum 1.22.1 di Ledger, ma in un ambiente di laboratorio controllato. Ledger sostiene che il problema fosse già stato corretto nella versione 1.22.2, prima che la dimostrazione diventasse pubblica, e afferma di non aver trovato prove di attacchi contro i propri utenti. 31731

L’episodio mette però in luce un aspetto più ampio della sicurezza dei wallet hardware: non basta che le chiavi private restino isolate. Il dispositivo deve anche mostrare fedelmente la transazione che sta per firmare.

Che cosa ha riprodotto OneKey

La vulnerabilità, identificata da Ledger come LSB-023, riguardava l’intercalamento dei comandi durante la revisione di una transazione sul dispositivo. Un computer collegato poteva inviare un nuovo comando APDU mentre il comando precedente era ancora in attesa della risposta dell’utente. Poiché i parametri della firma rimanevano in uno stato condiviso durante la revisione, potevano essere modificati dopo essere stati visualizzati sul dispositivo ma prima della produzione della firma. 3

In pratica, lo schermo poteva mostrare la transazione A mentre il dispositivo firmava la transazione B. Il team Anzen di OneKey ha riprodotto questo comportamento utilizzando in laboratorio la versione non aggiornata 1.22.1 dell’app Ethereum. Il test dimostra che il vecchio software era sfruttabile, ma non dimostra che i sistemi di produzione o gli utenti di Ledger siano stati compromessi. 172332

Ledger afferma di aver individuato la vulnerabilità attraverso il proprio processo di sicurezza e di aver introdotto le misure di protezione nell’app Ethereum 1.22.2. Secondo le ricostruzioni disponibili, il problema alla base è stato inoltre corretto nel Secure SDK 26.6.1. 172124

Qualcuno è stato hackerato?

La posizione di Ledger è netta: «Nessun utente Ledger è stato hackerato». Le informazioni disponibili non descrivono perdite note collegate alla riproduzione di OneKey, ma questa dichiarazione va interpretata come un resoconto degli attacchi osservati, non come la prova che lo sfruttamento fosse impossibile sulle versioni vulnerabili. 172031

La distinzione è importante: una riproduzione in laboratorio può confermare che un determinato percorso vulnerabile funziona nelle condizioni richieste, senza dimostrare che criminali lo abbiano utilizzato nel mondo reale.

Le due ulteriori vulnerabilità corrette con la versione 1.22.3

La versione 1.22.3 ha corretto altri due problemi dell’app Ethereum rimasti rilevanti dopo l’aggiornamento alla 1.22.2. L’indice dei bollettini di sicurezza di Ledger li identifica come LSB-024 e LSB-025. 46

LSB-024: un batch di clear signing poteva nascondere alcune operazioni

LSB-024 riguardava un difetto nella gestione del numero di interi o di operazioni durante il clear signing, cioè la modalità in cui il dispositivo mostra i dettagli dell’operazione prima della firma. Un batch appositamente costruito con 257 operazioni poteva fare in modo che il dispositivo mostrasse soltanto l’operazione finale, pur firmando l’intero batch.

Si tratta di un problema di integrità della revisione della transazione. Il dispositivo poteva comunque richiedere la conferma dell’utente, ma le informazioni mostrate non descrivevano fedelmente l’intero contenuto firmato. Ledger definisce il problema «Clear-signing bypass via array-count truncation», ovvero un bypass del clear signing dovuto al troncamento del conteggio dell’array. 46

LSB-025: un pagamento per uno swap poteva diventare un’approvazione di token

LSB-025 riguardava il flusso di uno swap. Un fornitore di swap compromesso poteva sostituire il pagamento atteso con un’approvazione di token senza far comparire un nuovo prompt sul dispositivo. Ledger descrive il problema come «Swap flow accepted a token approval in place of a payment». 46

I limiti indicati nelle segnalazioni sono importanti: il difetto non è stato descritto come un modo per creare un’approvazione illimitata o autorizzare un indirizzo scelto arbitrariamente dall’attaccante. Poteva tuttavia indurre l’utente a firmare un’approvazione che non intendeva autorizzare, un’operazione sostanzialmente diversa dal pagamento previsto in uno swap. 46

Perché LSB-024 e LSB-025 non erano già nella versione 1.22.2?

Il materiale pubblico disponibile per questo caso indica che le modifiche relative ai due problemi successivi sarebbero state integrate mesi prima della pubblicazione della versione 1.22.2. Le correzioni sono però arrivate con la 1.22.3. Le ricostruzioni parlano di una questione di rilascio o integrazione ancora senza spiegazione definitiva. 37

Non esiste, nelle fonti pubbliche considerate, una documentazione autorevole sufficiente a stabilire se la causa sia stata una scelta di priorità, un errore di integrazione, una fase di test o un’altra decisione interna. La conclusione sostenibile è quindi più circoscritta: le correzioni non erano incluse nella versione 1.22.2 e il motivo preciso non è stato spiegato pubblicamente. Andare oltre significherebbe superare le prove disponibili.

Che cosa rivela il caso sul modello di sicurezza aggiornabile di Ledger

La risposta di Ledger ha sottolineato che un’architettura aggiornabile permette di correggere e distribuire le patch per le vulnerabilità presenti nelle app del dispositivo e nel software di supporto. In questo modello, il processo dovrebbe consistere nell’individuare il difetto, sviluppare la correzione, pubblicarla e poi divulgare i dettagli tecnici. LSB-023 è stato presentato come un esempio di questo percorso: la vulnerabilità sarebbe stata identificata internamente, corretta e infine documentata in un bollettino di sicurezza. 3

Il vantaggio è evidente: una vulnerabilità software scoperta non deve necessariamente restare permanente. Ma il modello impone anche un obbligo operativo agli utenti. Una patch protegge il dispositivo soltanto dopo che l’app interessata è stata effettivamente aggiornata; inoltre, un rilascio incompleto o ritardato può lasciare irrisolti problemi collegati, come mostra il passaggio dalla 1.22.2 alla 1.22.3. 37

Che cosa devono fare gli utenti Ledger

1. Aggiornare l’app Ethereum almeno alla versione 1.22.3. Le ricostruzioni indicano la 1.22.3 come la versione che ha corretto LSB-024 e LSB-025, mentre la 1.22.2 conteneva la correzione a livello di app per LSB-023. 1737
2. Utilizzare il gestore del dispositivo in Ledger Live e i canali ufficiali di Ledger per gli aggiornamenti. Le istruzioni di Ledger indicano di installare l’app Ethereum tramite Ledger Live. 7
3. Controllare ogni richiesta visualizzata sul dispositivo, soprattutto durante gli swap. Se il dispositivo chiede un’approvazione quando ci si aspettava un pagamento, è meglio interrompere e rifiutare l’operazione.
4. Prestare attenzione ai batch insolitamente grandi o poco trasparenti. Quando possibile, evitare la firma alla cieca, soprattutto se il contenuto completo non può essere esaminato in modo significativo sul dispositivo.
5. Considerare computer, browser e fornitori collegati parte del modello di minaccia. Le vulnerabilità riguardavano il confine di comunicazione tra il computer o il servizio e l’app Ledger: un wallet hardware riduce alcuni rischi, ma non elimina quelli derivanti da malware, pagine web ostili, dApp compromesse o fornitori di swap. 328
6. Controllare le autorizzazioni dei token dopo aver utilizzato software interessato. Chi ha effettuato swap o firmato approvazioni con una versione vulnerabile dovrebbe verificare la presenza di autorizzazioni non necessarie e revocarle tramite un’interfaccia affidabile.

La conclusione immediata è semplice: OneKey ha dimostrato una vulnerabilità reale nella vecchia app Ethereum di Ledger, ma le prove disponibili non mostrano un attacco in corso contro gli utenti Ledger. L’episodio va comunque preso sul serio, perché LSB-024 e LSB-025 dimostrano che installare la prima correzione disponibile non era necessariamente la fine del problema di sicurezza.