Le criptovalute nascono nel 2008 con il protocollo Bitcoin, e la sicurezza dei fondi che vi transitano dipende interamente da un elemento: la chiave privata che controlla il portafoglio. Se quella chiave è generata in modo prevedibile, nessuna password e nessuna precauzione successiva possono proteggere il denaro che custodisce.
È esattamente ciò che è accaduto con Randstorm, una vulnerabilità che ha interessato i wallet di criptovaluta generati tra il 2011 e il 2015 attraverso alcune piattaforme web. Il difetto non stava nelle piattaforme, ma in una libreria di terze parti che tutte utilizzavano.
Come nasce Randstorm
La vulnerabilità è stata individuata nel 2022 dai ricercatori di Unciphered, durante un’operazione di recupero delle credenziali di un portafoglio creato nel 2014. Analizzando il modo in cui quel wallet era stato generato, i ricercatori hanno risalito la catena fino a una libreria JavaScript open source chiamata JSBN, utilizzata da numerose piattaforme di criptovaluta per creare le chiavi private direttamente nel browser dell’utente.
Il punto critico è la funzione `SecureRandom` di quella libreria. Generare una chiave crittografica richiede numeri casuali di qualità elevata, e la funzione tentava di ottenerli da `window.crypto.random`, una delle prime interfacce pensate per la crittografia nel browser. Quella interfaccia era però disponibile soltanto nei browser della famiglia Netscape Navigator, già obsoleti all’epoca in cui la libreria veniva usata.
Quando non la trovava, la libreria ripiegava su `Math.random`, una funzione progettata per usi generici e non per la crittografia. La differenza fra le due non è di grado ma di natura.
| Funzione generica | Funzione crittografica | |
|---|---|---|
| Progettata per | Simulazioni, animazioni, ordinamento casuale di elementi | Chiavi, token, segreti, qualsiasi valore che deve restare non indovinabile |
| Origine dei valori | Un algoritmo deterministico che parte da uno stato interno | Entropia raccolta dal sistema operativo |
| Prevedibilità | Chi conosce lo stato interno ricostruisce la sequenza, in avanti e a ritroso | La conoscenza dei valori precedenti non consente di prevedere i successivi |
| Uso corretto | Tutto ciò che non ha bisogno di restare segreto | Tutto il resto |
Il risultato è che le chiavi generate in quel modo non avevano l’imprevedibilità attesa da una chiave a 256 bit. L’entropia effettiva scendeva a valori talmente inferiori da rendere praticabile un attacco a forza bruta: non serve provare tutte le combinazioni possibili, basta provare quelle che quella funzione poteva effettivamente produrre.
C’è anche una gradazione temporale. Le implementazioni successive hanno progressivamente migliorato la raccolta di entropia, quindi violare un portafoglio generato nel 2012 richiede in genere meno risorse rispetto a uno del 2014.
Perché una patch non risolve il problema
Nella maggior parte dei casi una vulnerabilità si chiude aggiornando il componente difettoso. Qui no, e la ragione riguarda il momento in cui il danno si è prodotto.
La chiave privata è stata generata una volta sola, anni fa, ed è quella che controlla i fondi da allora. Correggere oggi la libreria non rigenera la chiave che è già stata creata: il portafoglio resta debole per sempre, indipendentemente da quante versioni della libreria siano state pubblicate dopo. È il motivo per cui l’unica raccomandazione possibile è creare un portafoglio nuovo e trasferirvi i fondi.
Il secondo aspetto riguarda la provenienza del difetto. Nessuna delle piattaforme coinvolte aveva scritto quel codice: lo avevano ereditato importando una libreria di uso comune. Un’azienda che avesse verificato il proprio codice sorgente non avrebbe trovato nulla, perché il problema stava in una dipendenza esterna, in una funzione che tutti davano per corretta.
Il difetto di Randstorm non riguarda del resto le criptovalute in quanto tali, ma il modo in cui viene prodotta la casualità. Nelle applicazioni aziendali lo stesso errore si presenta in punti diversi, con conseguenze diverse.
| Dove serve casualità imprevedibile | Cosa accade se è prevedibile |
|---|---|
| Token di sessione | Un attaccante calcola il token di un altro utente e ne assume l’identità senza conoscerne le credenziali |
| Link di reimpostazione password | Il link inviato a un altro indirizzo diventa ricostruibile, e con esso il controllo dell’account |
| Codici monouso di verifica | Il secondo fattore di autenticazione perde efficacia, perché il codice si prevede invece di intercettarlo |
| Chiavi API e segreti generati dall’applicazione | Le credenziali di integrazione fra sistemi si deducono anziché rubarle |
| Identificativi di documenti e ordini | Diventa possibile enumerare i dati di altri clienti scorrendo gli identificativi |
Le piattaforme coinvolte
Le librerie JSBN e BitcoinJS sono state utilizzate attivamente fra il 2011 e il 2015 da numerosi servizi di generazione di wallet. Alcuni di quei servizi non esistono più, altri sono ancora operativi.
| Piattaforme non più operative o reindirizzate | Piattaforme ancora attive e potenzialmente interessate |
|---|---|
| Blockrail, BrainWallet, CoinPunk, Dark Wallet, DecentralBank, EI8HT, QuickCon, Robocoin, Skyhook ATM, GreenAddress | BitAddress, Blockchain.com, BitPay, BitGo, CoinKite |
Per le piattaforme della seconda colonna la circostanza da tenere presente è una: il fatto che siano ancora attive e abbiano corretto le proprie implementazioni non protegge i portafogli generati all’epoca. Vale la distinzione della sezione precedente, la chiave debole resta debole.
La vulnerabilità non riguarda soltanto Bitcoin. Diverse criptovalute alternative, fra cui Litecoin, Zcash e Dogecoin, hanno adottato implementazioni derivate da BitcoinJS, ereditandone il difetto di generazione.
L’impatto stimato
Secondo Unciphered la vulnerabilità interessa oltre un milione e mezzo di portafogli, e un attacco condotto su larga scala comporterebbe perdite stimate fra i 4,7 e i 7,9 miliardi di dollari ai valori di mercato del periodo di pubblicazione della ricerca.
I ricercatori hanno dimostrato la praticabilità dell’attacco recuperando l’accesso ad alcuni portafogli creati in passato, ma hanno scelto di non pubblicare alcuna dimostrazione tecnica del metodo. È una decisione coerente con la prassi della divulgazione responsabile: rendere noto il rischio a chi deve proteggersi, senza fornire lo strumento a chi vorrebbe sfruttarlo. Lo stesso criterio distingue le attività di ethical hacking dalla ricerca condotta senza mandato.
Una precisazione utile: nessuno ha modo di sapere quanti di quei portafogli siano stati effettivamente violati. La stima descrive l’esposizione teorica, non il danno accertato.
Cosa fare se avete un wallet di quel periodo
L’azione principale è una sola, e non ammette alternative: se avete generato un portafoglio fra il 2011 e il 2015 tramite un servizio web, createne uno nuovo con uno strumento attuale e trasferitevi i fondi. Non esiste un modo di rafforzare una chiave già generata.
Sulla generazione del nuovo portafoglio, gli strumenti più solidi sono i dispositivi hardware dedicati, che creano e conservano la chiave privata offline e la impiegano soltanto nel momento della transazione, senza esporla al browser né al sistema operativo. È la differenza rispetto ai portafogli generati in una pagina web, dove la qualità della casualità dipende dall’ambiente in cui la pagina viene eseguita.
Per la protezione della chiave privata valgono due criteri. La copia di sicurezza va conservata offline e in forma cifrata, perché una chiave privata copiata su un servizio cloud o in un file di testo è già un rischio superiore a quello da cui la copia dovrebbe proteggervi. E la passphrase che protegge il portafoglio va scelta puntando sulla lunghezza: una sequenza lunga di parole non correlate resiste meglio di una stringa breve con simboli e maiuscole, che è la vecchia regola di composizione oggi superata dalle linee guida di riferimento.
Restano due accortezze operative. Le transazioni in criptovaluta sono irreversibili, quindi l’indirizzo del destinatario va verificato prima della conferma e non dopo: è la ragione per cui il furto di criptovaluta passa spesso dalla sostituzione dell’indirizzo negli appunti di sistema, più che dalla violazione della chiave. E il settore è fra i più battuti dalle frodi, con schemi di investimento fraudolento, campagne di phishing su piattaforme di scambio e falsi annunci attribuiti a personaggi noti.
- Autore articolo
- Gli ultimi articoli
Classe 1998, laureato in Informatica e Comunicazione Digitale, appassionato di informatica e scrittura. Scrivere per questo blog rappresenta per me un’occasione per divulgare la cultura della cybersecurity, oggi più che mai indispensabile. Scrivo di minacce informatiche, social engineering e digital awareness, impegnandomi attivamente a trasformare scenari complessi in contenuti accessibili per i nostri utenti.