Exploit Liquid da 320 milioni: 4.000 BTC escono dal peg di Blockstream

🛡️ Executive Summary

• Secondo SideSwap, un bug di Elements avrebbe consentito di creare 4.000 L-BTC poi utilizzati in un peg-out formalmente valido.
• La Liquid Federation ha liberato circa 3.996 BTC, quasi l’intera riserva, senza che risultino compromesse le chiavi PAK o gli HSM.
• Liquid ha sospeso la sidechain; i presunti white-hat promettono di restituire gran parte dei BTC soltanto dopo il completo aggiornamento dei nodi.

Un incidente da circa 320 milioni di dollari ha colpito Liquid Network, la sidechain Bitcoin sviluppata da Blockstream, portando all’uscita di circa 4.000 BTC dal wallet della Liquid Federation e alla sospensione dell’infrastruttura. Il dato più importante, però, non è soltanto la dimensione del drenaggio: dalle prime ricostruzioni non emerge un furto delle chiavi della federazione. Il percorso di peg-out avrebbe invece elaborato come legittimi 4.000 L-BTC creati sfruttando un bug di Elements, il software alla base di Liquid. Gli autori si definiscono white-hat e sostengono di voler restituire gran parte dei fondi, ma al momento questa qualificazione resta una loro dichiarazione.

Come sono usciti 3.996 BTC dal peg senza rubare le chiavi

La sequenza ricostruita da SideSwap è particolarmente rilevante perché separa il problema da un classico furto di credenziali. Alle 14:05 UTC del 6 settembre un cliente avrebbe inviato 4.000 L-BTC al servizio di peg-out di SideSwap. I token sono stati bruciati attraverso una richiesta dotata di autorizzazione valida e, alle 14:28 UTC, la Liquid Federation ha trasferito circa 3.996 BTC verso l’indirizzo Bitcoin indicato. SideSwap sostiene che Blockstream abbia successivamente stabilito che gli L-BTC utilizzati nell’operazione provenivano da un bug nel software Elements e non da una compromissione dei sistemi SideSwap. Liquid, nella propria comunicazione ufficiale sull’incidente, ha confermato che il prelievo è passato attraverso la Peg-out Authorization Key di SideSwap, specificando però che quella chiave e le altre PAK non risultano compromesse. La conseguenza è anomala ma tecnicamente coerente con il funzionamento del sistema: se L-BTC che non avrebbero dovuto esistere vengono accettati dalla sidechain come validi, il successivo peg-out può presentarsi ai componenti della federazione come una normale richiesta di rimborso. È una dinamica diversa ma concettualmente vicina a quella osservata nell’exploit Hyperbridge su Polkadot, dove token sintetici non autorizzati sono stati creati senza compromettere la blockchain nativa.

Leggi anche: Bridge e stablecoin sotto attacco: 40 milioni persi tra AFX, Verus e Balance

Perché multisig, PAK e HSM non hanno fermato il drenaggio

Liquid custodisce i bitcoin associati agli L-BTC attraverso un wallet multisig 11-of-15: quindici functionary conservano ciascuno una chiave in uno Hardware Security Module, mentre undici firme sono necessarie per autorizzare l’uscita dei BTC. Durante un peg-out, secondo la documentazione tecnica di Blockstream sul multisig della Liquid Federation, i functionary controllano che la destinazione appartenga alla lista autorizzata attraverso il sistema PAK, verificano che il corrispondente quantitativo di L-BTC sia stato bruciato e soltanto dopo firmano la transazione Bitcoin. Questo modello protegge efficacemente da diversi scenari di compromissione delle chiavi, ma non necessariamente da un errore precedente nella validazione dell’asset: se il software accetta come autentici L-BTC creati illegittimamente e il servizio autorizzato li brucia regolarmente, gli HSM possono eseguire correttamente una procedura costruita su una premessa falsa. Non significa quindi, sulla base delle informazioni disponibili, che il multisig sia stato “bucato”: significa che il controllo crittografico finale potrebbe avere ricevuto uno stato della sidechain già considerato valido dal software vulnerabile. È proprio il genere di problema emerso anche negli attacchi ai livelli di verifica cross-chain, dove un’informazione falsa accettata come valida può produrre trasferimenti reali.

Il bug di Elements e la pista del range proof cache

La causa tecnica definitiva non è stata ancora pubblicata da Blockstream e su questo punto è necessario separare ciò che è confermato dagli indizi disponibili nel codice. SideSwap attribuisce a Elements la creazione anomala degli L-BTC, mentre analisi indipendenti hanno segnalato comportamenti divergenti nella validazione di almeno un blocco Liquid, elemento compatibile con un problema a livello di consenso o verifica delle transazioni. Parallelamente, nel repository di Elements è comparso il commit c26d719 relativo al range proof cache, intitolato “fix: range proof cache bind to asset and scriptpubkey”. La modifica cambia il modo in cui viene costruita la chiave della cache usata nella verifica dei range proof, aggiungendo al proof e al commitment anche asset commitment e scriptPubKey. Il tempismo e la natura della correzione rendono il commit tecnicamente interessante, soprattutto perché Liquid utilizza Confidential Transactions, ma non esiste ancora una dichiarazione ufficiale che identifichi quella specifica modifica come la root cause dell’exploit. Presentarla già come vulnerabilità sfruttata sarebbe quindi prematuro. Il punto certo resta più limitato e allo stesso tempo più grave: secondo SideSwap, L-BTC non legittimi sono riusciti a raggiungere il normale percorso di peg-out.

Quasi il 95% della riserva e una sidechain praticamente congelata

Prima dell’incidente il wallet della federazione conteneva circa 4.200 BTC; l’uscita di circa 4.000 bitcoin equivale quindi a quasi il 95% della riserva dichiarata. Liquid ha reagito disabilitando temporaneamente i bridge node, impedendo la presentazione di nuove transazioni e rendendo di fatto la sidechain non operativa mentre gli exchange sono stati invitati a sospendere depositi e prelievi di L-BTC. Secondo Liquid, asset emessi sulla rete come USDT, DePix e real world assets non sono stati direttamente compromessi dall’incidente, anche se la sospensione dell’infrastruttura produce inevitabilmente conseguenze operative per gli utenti. La distinzione fondamentale riguarda inoltre Bitcoin: il protocollo e il consenso della mainchain non risultano violati. Liquid utilizza BTC bloccati su Bitcoin come copertura degli L-BTC circolanti sulla propria rete e applica un modello di sicurezza differente, basato sulla federazione e sul software Elements. Proprio questa separazione spiega perché possa verificarsi un drenaggio enorme della riserva della sidechain senza che un attaccante abbia modificato le regole di Bitcoin o sottratto bitcoin direttamente attraverso una vulnerabilità della sua blockchain.

White-hat o attaccanti che negoziano dopo avere svuotato il peg

La definizione di white-hat merita prudenza. Il primo messaggio inserito on-chain dagli autori dichiarava semplicemente che erano white-hat e chiedeva a Blockstream di contattarli attraverso la blockchain. Nelle ore successive è iniziato uno scambio basato su transazioni OP_RETURN e materiale firmato tramite PGP. Gli attori hanno quindi chiesto se fosse accettabile restituire “la maggior parte” dei fondi e hanno condizionato il trasferimento alla correzione del bug e all’aggiornamento di tutti i nodi, sostenendo che la chain sarebbe rimasta a rischio finché la patch non fosse stata distribuita completamente. Alle 06:15 UTC del 7 settembre, però, i bitcoin risultavano ancora sotto il loro controllo e Liquid restava sospesa. Il comportamento potrebbe essere coerente con una disclosure forzata accompagnata dalla restituzione dei fondi, ma l’etichetta white-hat non nasce dall’autoproclamazione: dipenderà dalla restituzione effettiva, dall’eventuale trattenimento di una ricompensa, dalle modalità con cui è stata scoperta e sfruttata la falla e dagli accordi raggiunti con Blockstream. Un precedente utile è quello della Ronin Network, dove circa 12 milioni di dollari furono effettivamente restituiti dopo lo sfruttamento di una vulnerabilità del bridge: in quel caso la restituzione, non la semplice dichiarazione iniziale, trasformò l’incidente in un’operazione white-hat concretamente verificabile.

Continua con:

• Exploit Hyperbridge: un falso messaggio cross-chain permette di creare un miliardo di DOT sintetici
• KelpDAO e LayerZero: 266 milioni persi dopo la manipolazione del livello di verifica

Il caso Liquid sposta il problema dalla custodia alla validazione

L’incidente Liquid mostra perché la sicurezza di una sidechain non possa essere ridotta alla domanda su quante chiavi debbano essere rubate per svuotarne la riserva. Undici firme su quindici, HSM separati e whitelist PAK possono proteggere il percorso di autorizzazione e risultare contemporaneamente insufficienti se la vulnerabilità modifica ciò che il sistema considera un asset valido prima che quel percorso inizi. Il passaggio decisivo dell’analisi sarà quindi la pubblicazione della root cause di Elements: occorrerà stabilire come siano stati creati gli L-BTC privi di copertura, quali versioni del software siano vulnerabili, perché i controlli di supply non abbiano arrestato l’anomalia, se nodi con versioni differenti abbiano prodotto una divergenza di validazione e quali garanzie permetteranno una riapertura sicura della rete. Fino ad allora il numero resta enorme — circa 4.000 BTC e 320 milioni di dollari — ma il dato tecnicamente più importante è un altro: la Liquid Federation potrebbe avere firmato correttamente l’uscita di bitcoin reali perché il livello sottostante le aveva presentato come autentica la distruzione di L-BTC che non avrebbero mai dovuto esistere. È questa, più della retorica sui presunti white-hat, la questione che Blockstream dovrà chiarire.