Un attacker ha svuotato 6 milioni di dollari da un vault di finanza decentralizzata (DeFi) nonostante il protocollo utilizzasse una whitelist di indirizzi approvati, un controllo di sicurezza progettato per limitare i movimenti di fondi a destinazioni pre-autorizzate. La piattaforma di bug bounty e sicurezza Immunefi ha reso noto l'incidente, confermando la perdita di 6 milioni di dollari. La violazione evidenzia una lacuna critica nel modo in cui l'autorizzazione basata su whitelist viene implementata e verificata nei contratti di vault. I contratti di vault concentrano i depositi di molti utenti dietro un unico set di permessi contrattuali, ed è per questo che il fallimento di un singolo controllo di autorizzazione può amplificarsi fino a causare una perdita immediata e rilevante per i depositanti.

Il protocollo specifico, la rete blockchain, l'hash della transazione e il vettore di exploit non erano stati confermati pubblicamente al momento della scrittura; i dettagli presentati al di fuori di questi fatti restano non verificati.

Cosa la whitelist di indirizzi approvati non è riuscita a prevenire

Una whitelist di indirizzi approvati è pensata per garantire che i prelievi dal vault o i trasferimenti di asset instradati solo verso un insieme fisso di indirizzi pre-autorizzati. In teoria, un attacker che non può aggiungere il proprio indirizzo a tale lista non può estrarre fondi. In pratica, il controllo è forte quanto la logica che governa gli aggiornamenti della lista, i controlli di accesso sulle funzioni admin che la gestiscono e qualsiasi contratto interagente in grado di invocare metoli privilegiati del vault.

Tra i punti di guasto più comuni figurano il compromissimento di una chiave admin che consente l'aggiunta di un indirizzo malevolo prima dello svuotamento; un percorso di re-entrancy o di callback che aggira completamente il controllo della whitelist; oppure un contratto proxy configurato in modo errato la cui implementazione non applica le stesse restrizioni dell'interfaccia del proxy. In assenza di una post-mortem confermata, i depositanti non possono ancora determinare quale percorso l'attacker abbia utilizzato in questo caso.

Perché una whitelist da sola non è sufficiente per la sicurezza di un vault

Una whitelist è un controllo di perimetro, non uno stack di difesa in profondità. Nella pratica del settore, i controlli di prelievo basati su whitelist sono tipicamente associati a flussi di vault permissioned o istituzionali, in cui un controllo operativo più stretto comporta il rischio di concentrazione delle chiavi admin, la stessa dipendenza ora sotto esame in questo incidente. La sicurezza di un vault dipende inoltre dalla presenza di un meccanismo di pausa funzionante, dal fatto che i prelievi di emergenza siano vincolati a un timelock e dal fatto che la funzione di aggiornamento della whitelist richieda l'approvazione multi-sig o un ritardo di governance. Se uno di questi livelli è assente o configurato male, una singola chiave compromessa o un bug logico può rendere la whitelist irrilevante.

I depositanti che valutano vault con whitelist dovrebbero verificare chi controlla la chiave admin che può aggiornare la whitelist, qual è il ritardo del timelock per l'aggiunta di indirizzi, se il contratto del vault si trova dietro un proxy aggiornabile e se un audit indipendente ha esaminato specificamente il percorso di autorizzazione. Un vault commercializzato come "whitelisted" senza tali informazioni fornisce garanzie più deboli di quanto l'etichetta suggerisca. Lo schema ricorda i problemi legati al percorso di autorizzazione osservati in incidenti di protocolli multi-chain, in cui bug considerati risolti hanno reintrodotto stato sfruttabile.

Controlli immediati per depositanti e operatori

Qualsiasi depositante con fondi in un vault che utilizza la whitelist di indirizzi dovrebbe verificare se il protocollo emesso un annuncio di pausa o di emergenza dopo la divulgazione di Immunefi. Quando il protocollo interessato non è stato reso pubblico, il passo immediato è monitorare il feed delle divulgazioni di Immunefi e il forum ufficiale di governance del protocollo per ulteriori dettagli. Gli sviluppi più probabili per chiarire il quadro sono una divulgazione aggiornata che nomini il protocollo e la chain interessati, una post-mortem pubblicata che identifichi il vettore di exploit e ogni movimento osservabile on-chain dei fondi svuotati.

Gli operatori di vault dovrebbero considerare l'incidente come uno spunto per audrire l'intero percorso di autorizzazione: non solo se esiste una whitelist, ma se ogni punto di ingresso nella logica del vault applica lo stesso controllo, se le funzioni admin sono protette da multi-sig e se gli alert di monitoraggio si attivano sulle transazioni di aggiornamento della whitelist. Una funzione di pausa che non può essere attivata entro pochi minuti da un trasferimento anomalo non offre alcuna protezione significativa. Anche i framework di governance che controllano i parametri del vault dovrebbero verificare se le decisioni architetturali espongono i depositanti al rischio di concentrazione delle chiavi admin.

La perdita di 6 milioni di dollari conferma che le politiche di indirizzi approvati sono un controllo necessario ma insufficiente. La sicurezza di un vault richiede un'applicazione su più livelli: controlli di accesso sulle funzioni admin, timelock sulle operazioni che modificano lo stato, monitoraggio in tempo reale e un percorso di risposta agli incidenti testato che includa una pausa verificabile.