L'hack della Liquid Network sottrae 320 milioni di dollari, poi restituisce gran parte dei Bitcoin

L'hack della Liquid Network ha sottratto quasi 4.000 BTC dal wallet della federazione della sidechain il 6 settembre, pari a circa il 95% delle sue riserve dichiarate. Gli autori non identificati si sono definiti white hat e hanno chiesto una correzione software prima di restituire il denaro.

Inizialmente, questa affermazione offriva poche rassicurazioni. Il prelievo aveva già convertito Liquid Bitcoin apparentemente non garantiti in bitcoin reali attraverso un processo di peg-out autorizzato. Liquid ha sospeso l'attività della rete, mentre gli exchange hanno sospeso depositi e prelievi relativi al suo asset garantito da Bitcoin.

Poi la situazione è cambiata. Gli autori hanno restituito 3.400 BTC dopo che Blockstream ha dichiarato di aver corretto i nodi bridge interessati. Tuttavia, circa 598,5 BTC, valutati quasi 47 milioni di dollari al momento della notizia, restavano sotto il loro controllo l'8 settembre.

Non si è trattato di una compromissione della rete Bitcoin stessa. È stato un fallimento all'interno di Liquid, una sidechain federata che usa software e operatori designati per collegare il proprio asset interno a Bitcoin. Questa distinzione protegge il livello base di Bitcoin dall'incidente, ma mette anche in luce la promessa centrale che Liquid deve ora riparare.

L'hack della Liquid Network ha trasformato un prelievo valido in un prosciugamento delle riserve

Il fatto determinante non è semplicemente che i bitcoin si siano mossi, ma che l'ordinario meccanismo di rimborso di Liquid avrebbe approvato il trasferimento.

Liquid Network ha comunicato che circa 4.000 BTC, allora valutati intorno a 320 milioni di dollari, erano stati prelevati dal suo wallet della federazione. Prima dell'incidente, il wallet conteneva secondo quanto riferito circa 4.200 BTC.

Il prelievo ha quindi rimosso all'incirca il 95% del saldo di quel wallet. Secondo le prime notizie sull'incidente di sicurezza, Liquid ha disabilitato i nodi bridge e coordinato con gli exchange l'interruzione di depositi e prelievi di L-BTC.

Liquid Bitcoin, generalmente indicato come L-BTC o LBTC, rappresenta bitcoin trasferiti sulla sidechain Liquid. La documentazione di Liquid afferma che ogni LBTC dovrebbe essere garantito da una quantità equivalente di BTC detenuta dalla federazione.

Il processo di conversione è chiamato peg bidirezionale. Un peg-in blocca bitcoin e crea il corrispondente LBTC. Un peg-out distrugge LBTC e rilascia bitcoin dal wallet della federazione.

Gli autori avrebbero apparentemente attaccato la contabilità prima del prelievo, anziché sottrarre le chiavi di firma del wallet. SideSwap ha dichiarato che 4.000 LBTC sono arrivati al suo servizio di peg-out con autorizzazione valida. Il servizio ha bruciato quei token e la federazione ha rilasciato circa 3.996 BTC all'indirizzo Bitcoin fornito.

SideSwap ha dichiarato che i propri sistemi e la Peg-out Authorization Key non sono stati compromessi. Una Peg-out Authorization Key, o PAK, limita i prelievi agli operatori registrati e ai formati di destinazione approvati.

Questa distinzione è rilevante perché la transazione è passata attraverso canali previsti. La federazione non avrebbe necessariamente rilevato una richiesta di prelievo palesemente falsificata. Al contrario, avrebbe elaborato token che non sarebbero mai dovuti esistere senza garanzie corrispondenti.

Gli autori non identificati hanno poi inserito un breve messaggio in una transazione Bitcoin. Hanno dichiarato: “siamo whitehat. contattateci on-chain.”

Il campo OP_RETURN di Bitcoin consente a una transazione di trasportare una piccola quantità di dati arbitrari. In questo caso, è diventato un canale di comunicazione pubblico tra gli autori e Blockstream.

Blockstream ha risposto con istruzioni per il contatto, seguite da messaggi cifrati e firmati crittograficamente. Gli autori hanno quindi affermato che avrebbero restituito il denaro dopo che ogni nodo interessato avesse ricevuto una correzione.

Questa sequenza ha reso l'exploit della Liquid Network insolitamente visibile. Chiunque poteva ispezionare le transazioni e i messaggi, mentre identità e intenzioni degli autori restavano sconosciute.

Il prosciugamento ha quindi prodotto due registrazioni simultanee. Liquid e SideSwap hanno descritto la risposta operativa, mentre Bitcoin ha conservato il prelievo, i messaggi successivi e l'eventuale restituzione parziale.

Il software ha accettato Bitcoin che non erano mai stati depositati

Il guasto segnalato ha spezzato il rapporto tra l'offerta di LBTC e la riserva di bitcoin senza compromettere le chiavi della federazione.

SideSwap ha dichiarato che Blockstream ha ricondotto l'incidente a un bug in Elements, il software open source alla base di Liquid. Secondo tale ricostruzione, la vulnerabilità ha consentito agli autori di creare LBTC non garantiti.

Questo meccanismo colpisce l'invariante più importante di qualsiasi bridge di asset. Un sistema non deve mai rilasciare una quantità della propria riserva superiore a quella precedentemente bloccata dagli utenti.

La documentazione sul peg di Liquid descrive un modello rigorosamente uno-a-uno. Ogni LBTC dovrebbe corrispondere a bitcoin detenuti dalla federazione. Distruggere un LBTC dovrebbe rilasciare un BTC.

Se il software accetta una transazione non valida che aumenta l'offerta della sidechain, tale garanzia fallisce prima dell'avvio del peg-out. L'attaccante può quindi presentare gli LBTC appena creati a un servizio di prelievo legittimo.

Il servizio di prelievo vede token autorizzati. Li brucia come previsto e chiede alla federazione di rilasciare bitcoin reali. Ogni componente può sembrare svolgere il proprio ruolo assegnato, anche se il risultato a livello di sistema è invalido.

Questo è il ribaltamento centrale nell'hack della Liquid Network. Secondo quanto riferito, i controlli di autorizzazione hanno funzionato, ma hanno autorizzato una richiesta basata su una contabilità dell'offerta corrotta.

Il design multisignature del wallet della federazione non ha impedito tale esito. Multisignature significa che diversi detentori di chiavi designati devono approvare una transazione prima che la riserva possa essere trasferita.

Questa configurazione protegge dal furto di una singola chiave o da un singolo firmatario malevolo. Non rileva automaticamente un fallimento a monte del consenso o della validazione che presenta un prelievo come legittimo.

Un'analisi on-chain pubblicata da Bitquery ha tracciato due piccoli peg-in prima del grande prelievo. I ricercatori hanno inoltre identificato attività di test e pattern crittografici ripetuti su Liquid prima della transazione finale.

La loro ricostruzione delle transazioni ha segnalato un pagamento della federazione di 3.996 BTC alle 14:28 UTC del 6 settembre. L'analisi ha inoltre documentato i messaggi scambiati dopo il prelievo.

Questi risultati suggeriscono una preparazione piuttosto che una transazione accidentale. Tuttavia, gli autori non si sono identificati pubblicamente né hanno fornito una divulgazione tecnica completa.

Alcune notizie hanno collegato il guasto alla validazione delle range proof. Una range proof è una prova crittografica che dimostra che l'importo nascosto di una transazione riservata resta valido e non crea asset in modo improprio.

Liquid utilizza Confidential Transactions, che nascondono gli asset e gli importi trasferiti consentendo al contempo ai nodi della rete di verificare la validità delle transazioni. Un difetto in questo processo di controllo può essere particolarmente grave perché i nodi si affidano alle prove anziché agli importi visibili.

La causa principale esatta richiede ancora un postmortem dettagliato da parte di Blockstream. Le informazioni pubbliche supportano la conclusione più ampia secondo cui LBTC non garantiti sono entrati nel percorso di peg-out, ma non stabiliscono ogni passaggio tecnico.

Questa lacuna di verifica dovrebbe restare esplicita. Una ricostruzione plausibile non equivale a una divulgazione completa del fornitore, a una patch sottoposta ad audit o a una riproduzione indipendente.

La sicurezza di Liquid Bitcoin dipende ora dal dimostrare più della sola integrità delle chiavi. Blockstream deve mostrare perché i nodi hanno accettato lo stato non valido, quali versioni sono state interessate e in che modo la patch blocca varianti correlate.

La promessa uno-a-uno di Liquid è ora sotto pressione

L'incidente mette sotto pressione Liquid perché la promessa del suo prodotto dipende sia dalla validazione crittografica sia dal giudizio operativo della federazione.

Liquid è progettata per offrire regolamenti più rapidi e maggiore riservatezza delle transazioni rispetto alla rete base di Bitcoin. Supporta inoltre asset come stablecoin e titoli tokenizzati.

Queste funzionalità derivano da una blockchain separata con presupposti di fiducia differenti. I miner di Bitcoin non convalidano le transazioni Liquid e le regole di consenso di Bitcoin non impongono l'offerta di LBTC.

Liquid si affida invece a una federazione di functionary per firmare blocchi e gestire il peg bidirezionale. Altri partecipanti alla federazione possono fornire servizi, ma la sicurezza del sistema non rispecchia il mining di Bitcoin.

Questo modello non è intrinsecamente difettoso. Ogni sidechain o bridge introduce ulteriori presupposti relativi a software, governance e custodia. Gli utenti accettano tali presupposti in cambio di capacità non disponibili sul livello base.

L'incidente ha mostrato come tali presupposti interagiscano durante un fallimento. Liquid ha potuto sospendere la rete, disabilitare i nodi bridge, coordinarsi con gli exchange, distribuire una patch e negoziare con gli autori.

Queste azioni hanno limitato ulteriori danni. Hanno anche dimostrato che la risposta d'emergenza di Liquid dipende da operatori identificabili in grado di fermare l'infrastruttura e influenzare il movimento degli asset.

Bitcoin stesso non si è fermato. I suoi miner hanno continuato a elaborare blocchi, incluse le transazioni contenenti i messaggi degli autori e i fondi restituiti.

Questo contrasto non significa che ogni applicazione debba essere eseguita direttamente su Bitcoin. Significa che gli utenti devono distinguere la sicurezza di Bitcoin dalla sicurezza degli asset che rappresentano bitcoin altrove.

La panoramica tecnica di Liquid descrive nodi bridge, hardware dei functionary, controlli di firma e meccanismi di recupero d'emergenza. L'architettura combina crittografia e coordinamento istituzionale.

La pressione ricade ora su Blockstream e sulla federazione, che devono spiegare come questi livelli abbiano fallito insieme. Dire che nessuna chiave privata è stata compromessa risponde solo a una parte della questione.

Gli utenti devono anche sapere perché i firmatari hanno rilasciato bitcoin in cambio di LBTC creati impropriamente. Gli exchange necessitano di prove che la ripresa dei depositi non possa esporli a una discrepanza irrisolta nell'offerta.

Gli emittenti di asset affrontano una preoccupazione correlata. Liquid ha dichiarato che gli altri asset emessi non sono stati coinvolti, ma la sospensione della rete ha comunque interrotto l'infrastruttura condivisa che li trasporta.

Un asset può restare tecnicamente integro pur diventando temporaneamente difficile da trasferire o riscattare. La disponibilità operativa diventa quindi parte della valutazione della sicurezza.

Il recupero parziale ha migliorato la posizione della riserva, ma non ha cancellato l'evento. Un sistema pubblicizzato come garantito uno-a-uno ha perso per breve tempo gran parte dei bitcoin a sostegno di tale affermazione.

I restanti 598,5 BTC lasciano inoltre una questione contabile. Blockstream deve spiegare in che modo l'importo ancora in circolazione influisca sulla copertura degli LBTC, sulle passività e su qualsiasi impegno di recupero.

Un asset restituito non annulla la perdita di disponibilità, l'incertezza del mercato o la necessità di controlli da parte degli exchange. Né dimostra che non resti alcuna vulnerabilità correlata altrove.

Gli operatori di Liquid affrontano sia un audit tecnico sia una prova di credibilità. Il primo chiede se il bug sia stato risolto. Il secondo chiede se gli utenti possano verificare tale risposta in modo indipendente.

Una restituzione parziale non risolve la questione del white hat

La restituzione di 3.400 BTC supporta l'intenzione dichiarata degli autori, ma il mantenimento di quasi 600 BTC impedisce una conclusione netta sul white hat.

Dopo che Blockstream ha dichiarato che i suoi nodi bridge erano stati corretti, gli autori hanno trasferito 3.400 BTC all'indirizzo della federazione. La transazione ha ripristinato circa l'85% dell'importo prelevato.

Un aggiornamento sul recupero dell’8 settembre ha riferito che quasi 47 milioni di dollari in bitcoin restavano ancora da recuperare. Le trattative sul saldo erano in corso.

Gli attori avevano in precedenza chiesto a Blockstream di correggere prima il bug. Hanno affermato che ogni nodo doveva applicare la patch prima che potessero restituire i fondi in sicurezza.

Quel messaggio è coerente con un aspetto del lavoro di sicurezza white hat. Pubblicare o dimostrare una vulnerabilità prima della correzione può esporre altri utenti ad attacchi imitativi.

Tuttavia, la divulgazione responsabile convenzionale inizia normalmente con una segnalazione privata e test coordinati. Non comincia rimuovendo il 95% della riserva di un sistema senza autorizzazione documentata.

L’etichetta scelta dagli attori è quindi un’affermazione, non uno status professionale verificato. L’uso iniziale da parte di Liquid dell’espressione “presunti hacker white hat” ha opportunamente mantenuto questa incertezza.

I fondi rimanenti rendono la questione più netta. Nessuna prova pubblica esaminata per questo articolo stabilisce che Blockstream abbia approvato una taglia di 598,5 BTC.

Senza tale approvazione, trattenere le monete può apparire come una commissione unilaterale, una leva negoziale o il possesso continuato di beni indebitamente sottratti. La restituzione parziale da sola non può determinare il movente o la responsabilità legale.

Non esiste inoltre alcuna identità pubblica sulla base della quale i lettori possano valutare esperienza, autorizzazione o condotta passata. Una firma on-chain dimostra il controllo di un indirizzo, non il carattere etico di chi lo controlla.

Questa ambiguità ha un precedente storico. Nel 2021, un attaccante sottrasse oltre 600 milioni di dollari da Poly Network e in seguito restituì la maggior parte degli asset.

Poly Network definì quell’attaccante un white hat e offrì una taglia. La copertura contemporanea di Poly Network mostrò come una grande restituzione possa cambiare la narrazione pubblica senza eliminare le questioni legali o di governance.

Il caso Liquid non è identico. Il meccanismo riportato, gli asset, gli operatori e le comunicazioni differiscono. Tuttavia, entrambi gli incidenti mostrano quanto rapidamente “hacker” diventi “white hat” quando il recupero dipende dalla cooperazione.

Questo linguaggio può servire a uno scopo pratico durante le trattative. Attaccare pubblicamente una controparte collaborativa potrebbe ridurre le possibilità di recuperare i fondi.

Tuttavia, la diplomazia operativa non dovrebbe sostituire la classificazione di sicurezza. Un ricercatore autorizzato, un sfruttatore opportunista e un estorsore possono tutti restituire fondi per ragioni diverse.

Le prove utili emergeranno dalla destinazione finale dei BTC rimanenti e da qualsiasi accordo divulgato. Un rapporto tecnico completo potrebbe anche chiarire se gli attori abbiano tentato un contatto privato in precedenza.

Fino ad allora, la descrizione più accurata resta quella di white hat autoidentificati o presunti. Definire l’operazione un test di sicurezza approvato andrebbe oltre le prove disponibili.

L’Exploit Riporta in Primo Piano un Vecchio Problema per i Bridge Bitcoin

L’architettura di Liquid differisce da quella di molti bridge crypto, ma il guasto segue uno schema noto: una falsa rivendicazione è entrata in una riserva che custodiva asset reali.

I sistemi cross-chain concentrano il rischio perché traducono attività tra ambienti con regole di sicurezza diverse. Un sistema deve decidere se un evento in un altro sistema giustifichi il rilascio di valore.

Per Liquid, questa decisione collega LBTC sulla sidechain con BTC detenuti su Bitcoin. Il wallet della federazione costituisce la riserva, mentre le regole di validazione di Liquid disciplinano le rivendicazioni su di essa.

Il bug riportato ha creato una discrepanza tra questi due registri. La sidechain ha accettato LBTC senza bitcoin corrispondenti, poi il processo di peg-out ha onorato la falsa rivendicazione.

Uno schema economico simile è comparso in altri incidenti legati ai bridge. L’exploit di Wormhole del 2022 ha consentito a un attaccante di creare asset wrapped senza il deposito che avrebbe dovuto garantirli.

Il bridge di Ronin ha fallito attraverso un percorso diverso. Gli attaccanti hanno ottenuto abbastanza chiavi di validatori per autorizzare prelievi dalla sua riserva.

Questi meccanismi differiscono sul piano tecnico, ma raggiungono lo stesso punto critico. Il bridge deve preservare una relazione rigorosa tra le rivendicazioni emesse e le garanzie bloccate.

I dati storici mostrano perché questo confine riceva un’attenzione costante. Chainalysis ha stimato che gli attaccanti abbiano rubato 2 miliardi di dollari in 13 hack di bridge durante parte del 2022.

La sua analisi del rischio dei bridge affermava che, al momento della pubblicazione, tali incidenti rappresentavano il 69% delle criptovalute rubate quell’anno. Le cifre descrivono il 2022, non il mercato attuale, ma la lezione architetturale resta rilevante.

I bridge accumulano asset in posizioni prevedibili. Il loro codice di validazione e le policy dei firmatari creano inoltre percorsi ristretti attraverso cui possono muoversi grandi riserve.

La federazione di Liquid offre un insieme di operatori più strutturato rispetto a un bridge con smart contract anonimo. Può coordinare aggiornamenti, sospendere servizi e comunicare direttamente con gli exchange.

Questi vantaggi hanno favorito la risposta. Non hanno impedito il drenaggio iniziale della riserva perché la vulnerabilità riportata risiedeva nella logica che stabilisce quali transazioni fossero valide.

Questa distinzione dovrebbe orientare gli audit futuri. Testare soltanto la custodia delle chiavi e i controlli di accesso non rileverà i fallimenti relativi a inflazione, validazione delle prove e coerenza dello stato.

Gli auditor dovrebbero inoltre testare l’intero percorso di rimborso. Tale percorso include creazione dell’asset, validazione, autorizzazione, burning, firma della federazione e pagamento finale su Bitcoin.

L’exploit di Liquid Network dimostra perché la correttezza locale non sia sufficiente. SideSwap afferma che la propria chiave di autorizzazione è rimasta al sicuro, eppure il suo servizio valido è diventato parte di un esito di sistema non valido.

Anche i firmatari della federazione sembrano aver seguito le regole previste. Secondo quanto riportato, il difetto ha modificato le informazioni ricevute da tali regole.

Gli operatori necessitano quindi di controlli che confrontino più fonti di verità. Le variazioni dell’offerta, la cronologia dei peg-in, il volume dei peg-out e i movimenti della riserva dovrebbero essere riconciliati prima del completamento di un prelievo straordinario.

Anche una singola richiesta che coinvolga la maggior parte delle riserve dovrebbe ricevere una revisione eccezionale, persino se le regole del protocollo la considerano valida. La validità software e la plausibilità operativa sono controlli diversi.

Questo approccio introduce attrito, che Liquid è stata progettata in parte per ridurre. Il compromesso in termini di sicurezza è inevitabile quando un regolamento più rapido può spostare quasi un’intera riserva attraverso un solo percorso.

Tre Segnali Decideranno se Liquid Ha Contenuto il Danno

La fase successiva dipende dai bitcoin ancora in sospeso, da una spiegazione tecnica riproducibile e da un ritorno controllato alle operazioni normali.

Il primo segnale sono i 598,5 BTC rimanenti. Una restituzione completa rafforzerebbe la versione white hat degli attori, pur non stabilendo retroattivamente un’autorizzazione.

Anche una taglia negoziata potrebbe risolvere il saldo, ma solo se Blockstream divulgherà informazioni sufficienti a distinguere un accordo da una ritenzione unilaterale. Il silenzio continuato o il trasferimento verso indirizzi non correlati indebolirebbero l’interpretazione white hat.

Il secondo segnale è il postmortem tecnico di Blockstream. Dovrebbe identificare le versioni vulnerabili di Elements, la regola di validazione fallita, il percorso di transazione coinvolto e la protezione precisa introdotta dalla patch.

Una divulgazione utile dovrebbe anche spiegare se sviluppatori indipendenti abbiano riprodotto il bug. La riproduzione è importante perché una descrizione chiusa lascia gli utenti dipendenti dalla stessa organizzazione il cui software ha fallito.

Il rapporto dovrebbe affrontare i tempi di rilevamento. L’analisi pubblica delle transazioni suggerisce che attività preparatorie abbiano preceduto il principale peg-out, sollevando interrogativi sul monitoraggio e sulle soglie per le anomalie.

Il terzo segnale è il processo di riavvio di Liquid. Exchange e utenti necessitano di un percorso definito per depositi, prelievi e verifica della riserva prima della ripresa dell’attività ordinaria.

Riavviare i nodi del bridge non equivale a ripristinare la fiducia. Gli operatori devono riconciliare l’offerta di LBTC con i bitcoin detenuti dalla federazione dopo la restituzione parziale.

Dovrebbero inoltre spiegare come viene coperto il deficit rimanente. Questa risposta determina se i detentori sopportino un’esposizione residua o se la assorba un’altra parte.

Un riavvio accurato includerebbe verifiche della versione tra functionary e nodi del bridge. Fornirebbe inoltre una conferma visibile che il software obsoleto non possa riconnettersi alla rete di produzione.

La più ampia questione della sicurezza di Liquid Bitcoin resterà dopo la ripresa dei servizi. La federazione deve dimostrare di aver aggiunto difese sia contro il difetto divulgato sia contro fallimenti comparabili nella validazione.

Per gli sviluppatori, la lezione è tracciare le garanzie di sicurezza attraverso i confini tra componenti. Una chiave protetta non può salvare un sistema che autorizza la transazione sbagliata.

Per gli exchange, la lezione è monitorare le garanzie in modo indipendente. L’aspetto normale di un token non garantisce che il suo rapporto con la riserva resti intatto.

Per i detentori di asset, la domanda immediata è più semplice. Dovrebbero monitorare gli avvisi ufficiali sui servizi, i dati della riserva e lo stato dei prelievi dagli exchange prima di considerare chiuso l’incidente.

La restituzione parziale ha trasformato una perdita catastrofica in una crisi recuperabile. Non ha tuttavia ripristinato da sola la promessa di un rapporto uno a uno.

L’hack di Liquid Network sarà contenuto solo quando il saldo rimanente sarà risolto, il bug sarà compreso in modo indipendente e i normali prelievi riprenderanno a fronte di riserve riconciliate. Finché tali condizioni non saranno visibili, “la maggior parte dei fondi restituita” è un aggiornamento, non una conclusione.