È stata l’intelligenza artificiale a individuare la falla di sicurezza di Coldcard?

Un’operazione coordinata svuota centinaia di portafogli

L’incidente è venuto alla luce dopo che, il 30 luglio, circa 594 BTC, per un valore di quasi 38 milioni di dollari al momento, sono stati trasferiti da circa 500 indirizzi Bitcoin a firma singola. Quando la notizia è stata diffusa per la prima volta, Bitcoin.com News ha osservato che i trasferimenti sono avvenuti nell’arco di circa 25 minuti e sembravano prendere di mira portafogli con una vulnerabilità tecnica comune.

Successive analisi della blockchain hanno ampliato la portata potenziale del furto. I ricercatori hanno stimato che tra 1.082 e 1.196 indirizzi potrebbero essere stati colpiti in un arco di tempo di circa 41 minuti. Una dashboard personalizzata denominata Coldcard Sweep Watch ha successivamente quantificato il totale a 1.128,4717 BTC, per un valore di circa 71,1 milioni di dollari quando il bitcoin veniva scambiato a circa 63.044 dollari.

La maggior parte dei fondi è stata consolidata in un indirizzo che deteneva centinaia di bitcoin, dove una parte consistente è rimasta sostanzialmente immobile. Gli indirizzi interessati erano accomunati da un dettaglio importante: i loro seed di recupero erano stati creati su portafogli hardware Coldcard prodotti dalla società canadese Coinkite.

Un seed di recupero è un elenco di parole che controlla l’accesso a un portafoglio di criptovaluta. Chiunque riesca a ricostruire o ottenere quel seed può solitamente trasferire i fondi del portafoglio senza possedere il dispositivo fisico.

Coldcard individua un sistema di generazione casuale difettoso

Coinkite ha emesso un avviso urgente in cui segnalava che alcuni seed generati sui dispositivi Coldcard potevano essere vulnerabili. I dispositivi Mk3 con versione firmware 4.0.1, rilasciata intorno a marzo 2021, e le versioni successive erano tra quelli esposti al rischio maggiore.

Ulteriori analisi hanno esteso la preoccupazione ai seed creati su alcuni dispositivi Mk4, Mk5 e Q prima che Coinkite rilasciasse le correzioni di emergenza del firmware. Secondo quanto riferito, i prodotti Tapsigner, Opendime e Satscard non sono stati interessati dal problema poiché utilizzano un software diverso.

La vulnerabilità riguardava il processo utilizzato per generare dati casuali. I portafogli sicuri dipendono da una casualità di alta qualità affinché i loro seed di recupero non possano essere indovinati. Sui dispositivi Mk3 più gravemente colpiti, i ricercatori hanno stimato che il seed potesse contenere solo circa 40 bit di casualità effettiva invece dei 128 bit previsti.

Tale differenza è fondamentale. Un seme a 128 bit generato correttamente è considerato praticamente impossibile da indovinare tramite forza bruta. Un seme a 40 bit offre un numero di possibilità drasticamente inferiore, consentendo a un aggressore con potenza di calcolo sufficiente di testare potenziali semi offline e confrontare gli indirizzi risultanti con la blockchain pubblica di Bitcoin.

Alcuni dispositivi più recenti potrebbero aver fornito circa 72 bit di casualità effettiva, poiché l’hardware sicuro ha aggiunto un ulteriore livello di dati imprevedibili. Ciò renderebbe i semi più difficili da ricostruire, sebbene comunque molto più deboli di quanto previsto.

Un errore di configurazione è rimasto inalterato per 5 anni

Il problema è iniziato con un errore di configurazione in fase di compilazione che ha coinvolto due funzioni software che svolgevano compiti simili. Una funzione utilizzava il generatore di numeri casuali veri basato sull’hardware del dispositivo, mentre l’altra si affidava a un processo software più debole ereditato da MicroPython.

Coinkite intendeva disabilitare l’opzione MicroPython. Tuttavia, un controllo software verificava solo se fosse stata definita un’etichetta di configurazione, anziché se il suo valore fosse stato impostato a zero. Di conseguenza, il firmware finale poteva selezionare silenziosamente la funzione più debole.

Poiché le due funzioni avevano formati corrispondenti, il software ha continuato a compilarsi ed eseguirsi senza generare un errore evidente. L’errore si è insinuato nel codice in occasione di una migrazione software avvenuta nel 2021 ed è rimasto nel firmware disponibile al pubblico per oltre cinque anni.

L’aggiornamento del dispositivo ora non rafforza un seed generato con il software difettoso. Gli utenti interessati devono creare un seed completamente nuovo utilizzando il firmware corretto o un altro dispositivo sicuro, quindi trasferire i propri fondi agli indirizzi controllati da quel nuovo seed.

Gli utenti che hanno aggiunto almeno 50 lanci di dadi indipendenti durante la creazione del proprio seed potrebbero aver fornito una quantità sufficiente di casualità aggiuntiva per evitare questa vulnerabilità. Anche una passphrase BIP-39 forte avrebbe potuto rendere più difficile la ricostruzione, mentre i portafogli che richiedono firme da diversi dispositivi indipendenti avrebbero potuto impedire che un singolo seed compromesso potesse trasferire fondi da solo.

Coinkite punta il dito contro l’IA, ma mancano ancora le prove

Il CEO di Coinkite, Rodolfo Novak, si è scusato pubblicamente e ha affermato che l’azienda si assume la piena responsabilità del malfunzionamento del firmware. Ha dichiarato che il team sta lavorando a una versione corretta del software, a rapporti tecnici e all’assistenza per gli utenti coinvolti.

Coinkite e Novak hanno inoltre avanzato una teoria sorprendente su come sia stata scoperta la vulnerabilità. Poiché il proprio firmware era disponibile pubblicamente da anni, l’azienda ha dichiarato di ritenere che qualcuno possa aver utilizzato l’IA per esaminare le versioni precedenti del codice e individuare il percorso di casualità vulnerabile. «A tutti gli altri sviluppatori: crediamo che questa sia la cruda realtà del nuovo paradigma dell’IA. La revisione del codice assistita dall’IA è ora in grado di individuare bug latenti a una velocità che supera persino quella degli esperti più navigati del settore”, ha scritto Novak nel suo post di scuse pubblicato su X. “Se il vostro firmware è open source o è mai stato reso pubblico, date per scontato che sia già stato analizzato sia dagli aggressori che dai difensori.”

I moderni sistemi di codifica basati sull’IA sono in grado di elaborare grandi repository software e identificare relazioni sospette tra impostazioni di configurazione, funzioni e presupposti di sicurezza. Un hacker potrebbe chiedere a un sistema di questo tipo di cercare specificatamente generatori di numeri casuali vulnerabili, funzioni di fallback o errori che compromettono le chiavi crittografiche.

Ricercatori indipendenti hanno successivamente riferito di aver utilizzato modelli di IA per individuare o spiegare il problema dopo che era stato reso noto il problema di casualità sottostante. Ciò ha dimostrato quanto sia diventata accessibile l’analisi del codice assistita dall’IA, ma non ha stabilito che l’autore dell’attacco originale abbia utilizzato l’IA.

Coinkite ha ammesso che la propria analisi, effettuata utilizzando un modello di IA all’avanguardia, non è riuscita a individuare la falla prima del furto. Questo risultato dimostra che i sistemi di IA non individuano automaticamente ogni difetto grave. Le loro prestazioni possono dipendere dalle istruzioni ricevute, dalla quantità di codice fornito e dalla capacità di un revisore umano di comprendere i segnali di allarme.

I critici sostengono che l’errore umano sia stato il fattore determinante

Alcuni specialisti della sicurezza sostengono che concentrarsi eccessivamente sull’intelligenza artificiale (IA) rischi di distogliere l’attenzione da un errore di ingegneria di base. Molti ritengono che l’errore di configurazione fosse un tipo noto di errore software e che le tradizionali revisioni del codice, le procedure di test o gli audit incentrati sulla generazione dei seed avrebbero potuto individuarlo anni prima.

I punti di vista opposti non sono necessariamente incompatibili. Un errore umano ha creato la vulnerabilità e ne ha permesso il persistere, mentre l’IA potrebbe aver ridotto il costo necessario per individuarla, comprenderla o sfruttarla. Chi difende il sistema deve identificare ogni punto debole pericoloso, mentre chi attacca deve individuarne solo uno.

L’incidente mette inoltre in discussione i presupposti sulla sicurezza dell’open source. Il codice pubblico consente a esperti indipendenti di ispezionare il software, ma la disponibilità di per sé non garantisce che qualcuno esamini la sezione corretta, riconosca un difetto sottile e lo segnali prima che un aggressore agisca.

Per gli utenti di Coldcard, la priorità immediata è determinare quando e come è stato creato il proprio seed. Chiunque possieda un seed compromesso deve verificare le istruzioni tramite i canali ufficiali di Coinkite, installare il firmware corretto, creare un nuovo seed e trasferire i fondi con cautela, prestando attenzione ai tentativi di phishing e ai messaggi di assistenza falsi.

Le questioni a più lungo termine verteranno su quanto bitcoin sia stato sottratto, se gli investigatori riusciranno a identificare l’autore dell’attacco e se l’intelligenza artificiale abbia svolto un ruolo decisivo nell’individuazione della vulnerabilità. Le aziende produttrici di portafogli hardware saranno inoltre sottoposte a pressioni per rafforzare i test di entropia, verificare le configurazioni di compilazione ed esaminare continuamente il codice obsoleto sia con esperti umani che con strumenti di intelligenza artificiale avversaria.