Ecco come gli attaccanti di Drift hanno prosciugato oltre 270 milioni sfruttando una funzione di Solana pensata per comodità

L’attacco al Drift Protocol non è stato un classico “hack” tecnico: non è stato trovato un bug, non è stata compromessa una chiave privata e non è stata sfruttata una vulnerabilità di oracle o di flash loan. L’aggressore ha invece sfruttato una funzione legittima della rete Solana, i cosiddetti “durable nonces”, per indurre il consiglio di sicurezza del protocollo ad approvare transazioni che sarebbero state eseguite settimane dopo, in un contesto e a un momento che i firmatari non avevano inteso autorizzare. Il risultato è stato un prelievo di almeno 270 milioni di dollari, eseguito in meno di un minuto ma predisposto in più di una settimana.

Cosa sono i durable nonces e perché esistono

Su Solana ogni transazione contiene un “recent blockhash”, un valore che funge da timbro temporale e dimostra che la transazione è stata creata di recente; tale blockhash scade dopo circa 60-90 secondi. Questa scadenza impedisce il replay di transazioni vecchie o fuori contesto. I durable nonces sovvertono questa barriera: sostituiscono il blockhash scadente con un nonce fisso, memorizzato in un conto on-chain dedicato, mantenendo la transazione valida indefinitamente finché qualcuno non decide di inviarla.

La funzionalità è pensata per casi legittimi. Soluzioni come hardware wallet, sistemi di firma offline e servizi di custodia istituzionale devono poter preparare e approvare transazioni senza l’obbligo di inviarle entro 90 secondi. Tuttavia, la validità indefinita introduce un rischio operativo: se qualcuno ottiene una firma oggi, la transazione può essere eseguita la settimana successiva o il mese dopo, senza che il firmatario possa revocare retroattivamente l’approvazione, a meno che il conto nonce non venga manualmente avanzato — una pratica che molti non monitorano.

Modalità dello sfruttamento

Il protocollo Drift era governato da un multisig chiamato “Security Council”, composto da cinque membri con una soglia di approvazione di almeno due firme per ogni azione. I multisig sono una misura di sicurezza comune nella finanza decentralizzata: l’idea è che la compromissione di una singola persona non debba consentire lo svuotamento di fondi.

L’attaccante non ha dovuto violare chiavi private: gli sono bastate due firme apparentemente legittime. Secondo quanto riferito da Drift, le approvazioni sono state ottenute attraverso “autorizzazioni non autorizzate o presentate in modo fuorviante”, il che suggerisce che i firmatari credevano di approvare operazioni ordinarie.

La cronologia pubblicata da Drift descrive le fasi principali dell’operazione.

Il 23 marzo sono stati creati quattro conti di tipo durable nonce. Due erano associati a membri autentici del Security Council, mentre due erano controllati dall’attaccante, il che indica che l’aggressore aveva già ottenuto firme valide da due dei cinque membri, incapsulate in transazioni con nonce che non sarebbero scadute.

Il 27 marzo è stata eseguita una migrazione pianificata del Security Council per sostituire un membro. L’attaccante ha adattato la strategia: entro il 30 marzo è comparso un nuovo conto durable nonce legato a un membro della multisig aggiornata, segno che l’aggressore aveva riconquistato la soglia minima di due firme nella nuova configurazione.

Il 1° aprile è stato il giorno dell’esecuzione. In un primo momento Drift ha effettuato un prelievo di test legittimo dal fondo assicurativo; circa un minuto dopo, l’attaccante ha inviato le transazioni pre-firmate basate sui durable nonces. Due transazioni, separate da quattro slot sulla blockchain di Solana, sono state sufficienti per creare, approvare ed eseguire un trasferimento amministrativo malevolo.

In pochi minuti l’attaccante ha ottenuto il controllo delle autorizzazioni a livello di protocollo, ha introdotto un meccanismo di prelievo fraudolento e ha svuotato i forzieri.

Cosa è stato sottratto e come si sono mossi i fondi

Analisti on-chain hanno seguito i flussi in tempo reale. Il totale stimato dei fondi sottratti è di circa 270 milioni di dollari, distribuiti su decine di token. La categoria più consistente è rappresentata da JPL per circa 155,6 milioni di dollari, seguita da circa 60,4 milioni in USDC, 11,3 milioni in CBBTC (wrapped bitcoin di Coinbase), 5,65 milioni in USDT, 4,7 milioni in wrapped ether, oltre a quantità minori in DSOL, WBTC, FARTCOIN e altri token.

Il wallet principale che ha drenato i fondi è stato finanziato otto giorni prima dell’attacco tramite intent su NEAR Protocol, ma è rimasto inattivo fino al giorno dell’esecuzione. Dai wallet intermedi, i fondi sono stati instradati verso indirizzi su Ethereum tramite il bridge Wormhole. Alcuni indirizzi Ethereum erano stati pre-finanziati usando un servizio di mixing per la privacy, complicando le attività di tracciamento.

Prima dell’esfiltrazione finale, alcuni wallet intermedi erano stati riforniti il giorno prima tramite Backpack, una piattaforma decentralizzata di scambio che richiede verifiche identitarie, elemento che potrebbe offrire piste di indagine agli inquirenti.

Più di 230 milioni di USDC sono stati trasferiti da Solana a Ethereum utilizzando il protocollo di trasferimento cross-chain CCTP di Circle attraverso oltre 100 operazioni. Diversi osservatori hanno criticato Circle per non aver congelato i fondi rubati durante la finestra di sei ore successiva all’inizio dell’attacco.

L’operazione richiama schemi di ingegneria sociale già visti in passato, in cui l’obiettivo è compromettere l’infrastruttura di firma o convincere i firmatari a autorizzare transazioni malevole, piuttosto che sfruttare bug nel codice.

Temmy ha commentato in un post sui social:

“Abbiamo visto attacchi simili molte volte: la compromissione delle infrastrutture di firma o l’ingegneria sociale che induce le firme a autorizzare transazioni malevole. Non è sempre un bug di codice, ma spesso un errore operativo.”

Che cosa non è stato compromesso

L’incidente non sembra derivare da una falla nei contratti intelligenti di Drift, ma da una debolezza nel livello umano e operativo che circonda il multisig. La separazione temporale tra approvazione e esecuzione resa possibile dai durable nonces ha creato una discrepanza: il contesto in cui i firmatari hanno autorizzato le operazioni non coincideva più con quello in cui sono state eseguite.

Tutte le depositi nei prodotti di prestito e presa a prestito di Drift, i depositi nei vault e i fondi destinati al trading sono stati interessati. I token DSOL non depositati in Drift, compresi gli asset stakeati al validatore di Drift, non risultano compromessi. Il fondo assicurativo è stato prelevato per mettere al sicuro le risorse residue, il protocollo è stato congelato e il wallet compromesso è stato rimosso dalla multisig.

Implicazioni e questioni aperte

Questo episodio rappresenta il terzo grande sfruttamento recente che non dipende da un bug nel codice: sempre più spesso le perdite nei protocolli DeFi derivano da ingegneria sociale o da errori operativi piuttosto che da vulnerabilità nei contratti intelligenti. La variante dei durable nonces è particolarmente insidiosa perché sfrutta una funzionalità progettata per casi d’uso legittimi e richiede cambiamenti sostanziali nella gestione delle approvazioni multisig per essere neutralizzata.

Rimangono domande cruciali che il post-mortem promesso da Drift dovrà affrontare: in che modo due membri differenti della multisig hanno approvato transazioni che non comprendevano pienamente? Esistono strumenti, modifiche dell’interfaccia o procedure operative che avrebbero potuto evidenziare l’uso di durable nonces e richiedere ulteriori verifiche?

Possibili misure di mitigazione includono una migliore UX per evidenziare transazioni con nonce durevoli, alert operativi per la creazione e l’avanzamento dei conti nonce, monitoraggio proattivo dei conti multisig da parte dei custodi istituzionali e politiche che rendano più semplice revocare o invalidare approvazioni quando il contesto cambia. Queste soluzioni richiedono però modifiche alle pratiche consolidate e, in alcuni casi, aggiornamenti infrastrutturali sulla rete Solana.

Le indagini sono in corso e, oltre alla tracciabilità on-chain, esistono elementi che potrebbero permettere agli investigatori di seguire piste off-chain, come i rifornimenti effettuati tramite servizi che richiedono verifica identitaria. L’evento solleva inoltre interrogativi di natura regolamentare e di compliance per i servizi centralizzati coinvolti nei trasferimenti cross-chain.

In attesa del rapporto tecnico dettagliato da parte di Drift e delle risultanze investigative, la vicenda sottolinea la necessità di rafforzare sia gli aspetti tecnologici sia le pratiche umane e procedurali che governano le firme e le approvazioni nelle infrastrutture DeFi.