Come una funzionalità di Solana progettata per la comodità ha permesso agli aggressori di drenare oltre 270 milioni di dollari da Drift

L'attacco a Drift Protocol non è stato un hacking nel senso tradizionale del termine.

Nessuno ha trovato un bug o violato una chiave privata. Non c'è stato né un exploit di flash loan né un oracolo manipolato.

Invece, un aggressore ha utilizzato una funzionalità legittima di Solana, le 'durable nonces', per ingannare il consiglio di sicurezza di Drift, inducendolo a pre-approvare transazioni che sarebbero state eseguite settimane dopo, in un momento e in un contesto che i firmatari non avevano mai intenzione di autorizzare.

Il risultato è stato un deflusso di almeno 270 milioni di dollari che ha richiesto meno di un minuto per essere eseguito ma più di una settimana per essere organizzato.

Cosa sono i nonce durevoli e perché esistono

Su Solana, ogni transazione include un 'recent blockhash', essenzialmente un timestamp che dimostra che la transazione è stata creata di recente. Quel blockhash scade dopo circa 60-90 secondi. Se la transazione non viene inviata alla rete entro tale intervallo, diventa non valida. Questa è una misura di sicurezza che aiuta a prevenire la ripetizione di transazioni vecchie e scadute in un secondo momento.

I nonce durevoli annullano tale funzione di sicurezza. Sostituiscono il blockhash in scadenza con un 'nonce' fisso, un codice monouso memorizzato in un apposito account onchain, che mantiene la transazione valida indefinitamente fino a quando qualcuno decide di inviarla.

La funzione esiste per motivi legittimi. I portafogli hardware, le configurazioni di firma offline e le soluzioni di custodia istituzionale necessitano tutte della capacità di preparare e approvare le transazioni senza essere costretti a inviarle entro 90 secondi.

Ma le transazioni valide a tempo indeterminato creano un problema. Se qualcuno riesce a far firmare una transazione oggi, questa può essere eseguita la settimana prossima o il mese prossimo, secondo le regole hardcoded del sistema. Il firmatario non ha alcun modo di revocare la propria approvazione una volta data, a meno che il conto nonce non venga avanzato manualmente, cosa che la maggior parte degli utenti non monitora.

Come l'attaccante li ha utilizzati

Il protocollo di Drift era gestito da un «Security Council multisig», un sistema in cui più persone (in questo caso, cinque) condividono il controllo e ogni azione richiede l'approvazione di almeno due di esse. Le multisig sono una pratica di sicurezza standard nella DeFi, dove l'idea è che compromettere una singola persona non sia sufficiente per rubare fondi.

Ma l'attaccante non aveva bisogno di compromettere le chiavi di nessuno. Tutto ciò di cui aveva bisogno erano due firme, che sembrano essere state ottenute attraverso quella che Drift descrive come "approvazioni di transazioni non autorizzate o falsificate", il che significa che i firmatari probabilmente pensavano di approvare una transazione di routine.

Ecco la timeline pubblicata da Drift in un post di giovedì su X.

Il 23 marzo sono stati creati quattro account nonce duraturi. Due erano associati a membri legittimi del Drift Security Council. Due erano controllati dall’attaccante. Ciò significa che l’attaccante aveva già ottenuto firme valide da due dei cinque membri del consiglio, bloccate in transazioni nonce durature che non avrebbero scadenza.

Il 27 marzo, Drift ha eseguito una migrazione pianificata del Consiglio di Sicurezza per sostituire un membro del consiglio. L'attaccante si è adattato. Entro il 30 marzo, è comparso un nuovo account nonce durevole, collegato a un membro del multisig aggiornato, indicando che l'attaccante aveva nuovamente ottenuto la soglia di approvazione richiesta di due su cinque secondo la nuova configurazione.

Il 1° aprile, l’attaccante ha eseguito.

In primo luogo, Drift ha effettuato un prelievo di prova legittimo dal suo fondo assicurativo. Circa un minuto dopo, l'attaccante ha inviato le transazioni pre-firmate con nonce durevoli. Due transazioni, separate da quattro slot sulla blockchain di Solana, sono state sufficienti per creare e approvare un trasferimento amministrativo maligno, per poi approvarlo ed eseguirlo.

Nel giro di pochi minuti, l'attaccante ha ottenuto il pieno controllo delle autorizzazioni a livello di protocollo di Drift. Ha utilizzato tale controllo per introdurre un meccanismo di prelievo fraudolento e svuotare i caveau.

Cosa è stato preso e dove è andato

I ricercatori Onchain hanno monitorato i flussi di fondi in tempo reale. La suddivisione degli asset rubati, compilata dal ricercatore di sicurezza Vladimir S., ammontava a circa 270 milioni di dollari distribuiti su dozzine di token.

La categoria singola più grande è stata di 155,6 milioni di dollari in token JPL, seguita da 60,4 milioni di dollari in USDC, 11,3 milioni di dollari in CBBTC (Bitcoin wrapped di Coinbase), 5,65 milioni di dollari in USDT, 4,7 milioni di dollari in wrapped ether, 4,5 milioni di dollari in DSOL, 4,4 milioni di dollari in WBTC, 4,1 milioni di dollari in FARTCOIN e importi minori distribuiti tra JUP, JITOSOL, MSOL, BSOL, EURC e altri.

Il portafoglio principale da cui sono stati sottratti i fondi è stato finanziato otto giorni prima dell’attacco tramite intenti del protocollo NEAR, ma è rimasto inattivo fino al giorno dell’esecuzione. I fondi rubati sono stati trasferiti a portafogli intermedi, finanziati appena il giorno prima tramite Backpack, uno scambio decentralizzato di criptovalute che richiede la verifica dell’identità, fornendo potenzialmente agli investigatori una pista.

Da lì, i fondi sono stati trasferiti verso indirizzi Ethereum tramite Wormhole, un ponte cross-chain. Quegli indirizzi Ethereum erano stati pre-finanziati utilizzando Tornado Cash, il mixer per la privacy sanzionato.

ZachXBT, un rinomato investigatore onchain, notato che oltre 230 milioni di dollari in USDC sono stati trasferiti da Solana a Ethereum tramite il CCTP (Cross-Chain Transfer Protocol) di Circle in più di 100 transazioni.

Ha criticato Circle, l'emittente centralizzata di USDC, per non aver congelato i fondi rubati durante una finestra di sei ore dopo l'inizio dell'attacco intorno a mezzogiorno ora Eastern.

L'attacco ricordava inoltre recenti tentativi di ingegneria sociale, utilizzando tattiche simili a quelle già osservate, secondo un post sui social media da un utente che si fa chiamare 'Temmy.' "Lo abbiamo già visto. Lo abbiamo visto così tante volte," ha detto l'utente.

"bybit. 1,4 miliardi di dollari. L'attaccante ha compromesso l'infrastruttura di firma e ha ingannato i firmatari autorizzando transazioni dannose. Stesso concetto. Ingegneria sociale. Non codice. Ronin Bridge. 625 milioni di dollari. Chiavi dei validatori compromesse. Stessa storia. Cetus Protocol. 223 milioni di dollari. Metodo diverso ma stesso risultato. Centinaia di milioni spariti." riportava il post.

Ciò che non è stato compromesso

Ciò che ha fallito è stato il livello umano intorno al multisig. I nonce durevoli hanno permesso all'attaccante di separare il momento dell'approvazione da quello dell'esecuzione di oltre una settimana, creando una lacuna in cui il contesto del documento firmato non corrispondeva più al contesto in cui è stato utilizzato.

Tutti i depositi nei prodotti di prestito e mutuo di Drift, nei depositi dei vault e nei fondi di trading sono interessati. I token DSOL non depositati in Drift, inclusi gli asset vincolati al validatore Drift, non sono interessati. Gli asset del fondo assicurativo sono in fase di prelievo e salvaguardia. Il protocollo è stato congelato e il wallet compromesso è stato rimosso dalla multisig.

In quanto tale, si tratta del terzo grande exploit degli ultimi mesi che non ha coinvolto una vulnerabilità del codice. Ingegneria sociale e falle nella sicurezza operativa, piuttosto che bug nei contratti intelligenti, sono sempre più spesso la causa della fuoriuscita di fondi dai protocolli DeFi.

Il vettore nonce durevole è particolarmente pericoloso perché sfrutta una funzionalità che esiste per una buona ragione ed è difficile da contrastare senza cambiare radicalmente il modo in cui funzionano le approvazioni multisig su Solana.

La questione aperta, alla quale il prossimo postmortem dettagliato di Drift dovrà rispondere, riguarda come due membri separati del multisig abbiano approvato transazioni che non hanno compreso, e se eventuali strumenti o modifiche all'interfaccia avrebbero potuto segnalare le transazioni con nonce durevole come soggette a un ulteriore scrutinio.

Leggi di più: Gli hacker nordcoreani probabilmente dietro l'exploit da 286 milioni di dollari ai danni di Drift Protocol