{"id":28286,"date":"2023-12-11T14:11:59","date_gmt":"2023-12-11T12:11:59","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=28286"},"modified":"2023-12-11T14:11:59","modified_gmt":"2023-12-11T12:11:59","slug":"vulnerability-in-hot-cryptowallets-from-2011-2015","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/vulnerability-in-hot-cryptowallets-from-2011-2015\/28286\/","title":{"rendered":"Randstorm: le vulnerabilit\u00e0 dei cripto wallet degli anni 2010"},"content":{"rendered":"

Alcuni ricercatori hanno scoperto nella libreria BitcoinJS diverse vulnerabilit\u00e0 che potrebbero esporre alle violazioni i portafogli Bitcoin creati online un decennio fa. Il problema di fondo \u00e8 che le chiavi private per questi portafogli di criptovaluta, o cripto wallet, sono state generate in modo molto pi\u00f9 prevedibile di quanto gli stessi sviluppatori della libreria non si aspettassero.<\/p>\n

Vulnerabilit\u00e0 e conseguenze di Randstorm<\/h2>\n

Partiamo dall\u2019inizio. I ricercatori di Unciphered, una societ\u00e0 specializzata nel recupero dell\u2019accesso ai cripto wallet, hanno scoperto e descritto<\/a> una serie di vulnerabilit\u00e0 nella libreria JavaScript BitcoinJS utilizzata da molte piattaforme di criptovaluta online. Tra questi servizi ce ne sono alcuni molto popolari, in particolare Blockchain.info, ora noto come Blockchain.com. I ricercatori hanno soprannominato questo insieme di vulnerabilit\u00e0 Randstorm.<\/p>\n

Nel 2014 le vulnerabilit\u00e0 riscontrate nella libreria BitcoinJS sono state risolte. Tuttavia, il problema interessa anche il prodotto dell\u2019utilizzo di questa libreria: i cripto wallet creati con BitcoinJS all\u2019inizio degli anni 2010 potrebbero non essere sicuri, poich\u00e9 trovarne le chiavi private \u00e8 molto pi\u00f9 facile del previsto, nonostante il sistema di criptaggio Bitcoin sottostante.<\/p>\n

Secondo le stime dei ricercatori, a causa di Randstorm sono potenzialmente a rischio diversi milioni di portafogli, per un totale di circa 1,4 milioni di Bitcoin. I ricercatori ritengono inoltre che il 3-5% dei portafogli considerati potenzialmente vulnerabili<\/em> agli attacchi, sia effettivamente vulnerabile<\/em> in situazioni reali. In base al tasso di cambio in vigore al momento della pubblicazione di questo articolo (circa 36.500 dollari per 1 Bitcoin) gli autori degli attacchi in grado di sfruttare Randstorm potrebbero mettere le mani su un bottino del valore di 1,5-2,5 miliardi di dollari.<\/p>\n

I ricercatori non si sono limitati a sostenere che le vulnerabilit\u00e0 Randstorm possono effettivamente essere utilizzate per attaccare i portafogli di criptovaluta: hanno anche utilizzato queste vulnerabilit\u00e0 per ripristinare l\u2019accesso a diversi portafogli creati su Blockchain.info prima del marzo 2012. Per motivi etici, tuttavia, hanno evitato di pubblicare il progetto PoC (Proof-of-Concept) dell\u2019attacco, perch\u00e9 avrebbe esposto direttamente al rischio di furto decine di migliaia di portafogli di criptovaluta.<\/p>\n

I ricercatori hanno quindi contattato i servizi di criptovaluta online noti per aver utilizzato una versione vulnerabile della libreria BitcoinJS, che a loro volta hanno informato i clienti potenzialmente a rischio di un attacco basato sulle vulnerabilit\u00e0 Randstorm.<\/p>\n

La natura delle vulnerabilit\u00e0 Randstorm<\/h2>\n

Vediamo ora in dettaglio come funzionano in pratica queste vulnerabilit\u00e0. Al centro della sicurezza di un portafoglio Bitcoin c\u2019\u00e8 la chiave privata. Come ogni moderno sistema di criptaggio, Bitcoin fa affidamento sul fatto che questa chiave sia segreta e non decifrabile. E, come in ogni moderno sistema di criptaggio, questo comporta l\u2019utilizzo di numeri casuali molto lunghi.<\/p>\n

Per assicurare la massima sicurezza dei dati che protegge, inoltre, una chiave privata deve essere il pi\u00f9 casuale possibile. Se il numero utilizzato come chiave \u00e8 prevedibile, qualsiasi malintenzionato informato sulla procedura di generazione della chiave potr\u00e0 trovarlo ancora pi\u00f9 facilmente e rapidamente con un attacco di forza bruta.<\/p>\n

La generazione di un numero veramente<\/em> casuale non \u00e8 un\u2019operazione semplice<\/a> e i computer sono inadatti a questo compito, proprio per via della loro natura estremamente prevedibile. Pertanto, in genere otteniamo numeri solo pseudocasuali<\/em> e per aumentare il livello di entropia<\/em> (per usare un termine tecnico che indica l\u2019imprevedibilit\u00e0) durante il processo di generazione delle chiavi ci affidiamo ad alcune funzioni speciali.<\/p>\n

Ora torniamo alla libreria BitcoinJS. Per ottenere numeri pseudocasuali \u201cdi alta qualit\u00e0\u201d, questa libreria utilizza un\u2019altra libreria JavaScript denominata JSBN (JavaScript Big Number), in particolare la funzione SecureRandom<\/em>. Come suggerisce il nome, questa funzione \u00e8 stata progettata per generare numeri pseudocasuali idonei per il criptaggio. Per aumentare il livello di entropia, SecureRandom<\/em> si affida alla funzione del browser window.crypto.random<\/em>.<\/p>\n

Ed \u00e8 proprio qui che nasce il problema: nella famiglia di browser Netscape Navigator 4.x la funzione window.crypto.random<\/em> era disponibile, ma quando i servizi Web hanno iniziato a utilizzare attivamente la libreria BitcoinJS questi browser erano gi\u00e0 obsoleti. Nei browser pi\u00f9 diffusi all\u2019epoca (Internet Explorer, Google Chrome, Mozilla Firefox e Apple Safari), invece, la funzione window.crypto.random<\/em> semplicemente non era stata implementata.<\/p>\n

Poich\u00e9, purtroppo, gli sviluppatori della libreria JSBN non hanno previsto nessun tipo di controllo o messaggio di errore corrispondente, il passaggio per l\u2019incremento del livello di entropia veniva ignorato dalla funzione SecureRandom<\/em> e, di fatto, il compito di creare le chiavi private era affidando al generatore di numeri pseudocasuali standard, Math.random<\/em>.<\/p>\n

Questo rappresenta un problema di per s\u00e9, perch\u00e9 Math.random<\/em> non \u00e8 progettato<\/a> per il criptaggio. La situazione venne tuttavia ulteriormente peggiorata dal fatto che l\u2019implementazione di Math.random<\/em> nei browser pi\u00f9 diffusi nel 2011-2015, in particolare Google Chrome<\/a>, conteneva dei bug per cui i numeri prodotti risultavano anche meno casuali del previsto.<\/p>\n

A sua volta, la libreria BitcoinJS ha ereditato da JSBN tutti questi problemi. Di conseguenza, le piattaforme che l\u2019hanno utilizzata per generare le chiavi private per i loro portafogli di criptovaluta hanno ottenuto dalla funzione SecureRandom numeri molto meno casuali di quanto gli sviluppatori della libreria non si aspettassero. Essendo generate in modo tanto prevedibile, queste chiavi possono essere facilmente ottenute tramite un attacco di forza bruta, che pu\u00f2 cos\u00ec aprire la strada al furto dei portafogli di criptovaluta vulnerabili.<\/p>\n

Come accennato in precedenza, non si tratta un pericolo solo teorico: in pratica, il team di Unciphered \u00e8 stato in grado di sfruttare queste vulnerabilit\u00e0 per ripristinare l\u2019accesso (in altre parole, per violare in modo etico) diversi vecchi portafogli di criptovaluta creati su Blockchain.info.<\/p>\n

Per chi rappresenta un rischio Randstorm<\/h2>\n

La libreria vulnerabile JSBN \u00e8 stata utilizzata da BitcoinJS a partire dalla sua introduzione, nel 2011, fino al 2014. Alcuni progetti di criptovaluta potrebbero tuttavia aver utilizzato per un po\u2019 di tempo una versione meno recente della libreria. Considerando il fatto che i bug di Math.random nei browser pi\u00f9 diffusi sono stati risolti nel 2016 (con la modifica degli algoritmi per la generazione di numeri pseudocasuali), possiamo ipotizzare che tutti i portafogli di criptovaluta creati nel periodo compreso tra il 2011 e il 2015 siano potenzialmente vulnerabili.<\/p>\n

Come sottolineano i ricercatori, essendo BitcoinJS molto popolare nei primi anni di quel decennio, \u00e8 difficile compilare un elenco completo dei servizi che avrebbero potuto utilizzarne una versione vulnerabile. Pertanto, nel loro rapporto troviamo l\u2019elenco solo delle piattaforme che sono stati in grado di identificare come a rischio:<\/p>\n