Ripristino delle Operazioni di Prelievo di Liquid Network
Liquid Network si sta avvicinando al ripristino delle operazioni di prelievo dopo aver avviato un audit di sicurezza indipendente per Elements v23.3.4 e coordinato modifiche alle chiavi di autorizzazione utilizzate nel processo di prelievo. Nel suo aggiornamento dell’ecosistema del 28 settembre, Liquid Network ha comunicato che l’audit di sicurezza esterno di Elements v23.3.4 è attualmente in corso, come parte del lavoro per ripristinare in sicurezza i prelievi dopo l’incidente di sicurezza avvenuto a settembre.
Attività dell’Ecosistema – Aggiornamento del 28 Settembre 2026
Stato al 28 settembre 2026, 05:48 UTC
Audit di Sicurezza e aggiornamento PAK
Un audit di sicurezza esterno indipendente di Elements v23.3.4 è attualmente in corso, fornendo un ulteriore livello di validazione mentre lavoriamo per il ripristino sicuro dei prelievi. Allo stesso tempo, la Liquid Federation sta aggiornando la sua lista delle Chiavi di Autorizzazione per i Prelievi (PAK). Le voci esistenti vengono sostituite e la federazione sta lavorando per garantire che tutte le chiavi di ricezione Bitcoin associate ai prelievi siano adeguatamente protette in cold storage.
Liquid non ha fornito una data per la ripresa dei prelievi, ma ha dichiarato che l’audit e le modifiche alle PAK sono passi fondamentali verso il ripristino delle operazioni di prelievo in sicurezza, con un ulteriore aggiornamento sul processo di ripristino previsto a breve.
Dettagli sull’Incidente di Sicurezza
Elements v23.3.4 è stato rilasciato all’inizio di questo mese per affrontare il difetto software sfruttato durante l’incidente del 6 settembre, quando un attaccante ha creato circa 4.000 LBTC non garantiti e ha utilizzato il normale processo di prelievo di Liquid per ritirare Bitcoin dalla riserva della federazione. L’ultimo audit esterno aggiunge un’ulteriore revisione di quel rilascio prima che i prelievi vengano riattivati.
Elements è la piattaforma blockchain open source alla base di Liquid. La rete utilizza transazioni riservate, che nascondono gli importi delle transazioni, mentre le prove crittografiche consentono ai nodi di verificare che quegli importi siano validi. La valutazione post-incidente di Liquid ha dichiarato che la vulnerabilità riguardava il modo in cui Elements memorizzava nella cache i risultati della verifica delle prove di intervallo.
Una modifica precedente aveva rimosso alcuni contesti di transazione dalla chiave della cache, creando un difetto di consenso che poteva consentire a un risultato di verifica memorizzato nella cache di essere riutilizzato in circostanze diverse. Una successiva correzione ha affrontato il problema inizialmente identificato, ma un secondo problema riguardante il modo in cui i campi erano combinati nella chiave della cache è rimasto. L’attaccante del 6 settembre ha sfruttato quella seconda debolezza per creare un output il cui valore non era garantito dai suoi input.
Modifiche e Correzioni Implementate
Elements v23.3.4 ha cambiato il modo in cui le chiavi della cache delle prove di intervallo e delle prove di suriezione sono costruite, serializzando ciascun campo con un prefisso di lunghezza. Liquid ha dichiarato che questa modifica impedisce a diversi set di input di produrre la stessa chiave della cache attraverso il metodo di collisione utilizzato nell’attacco. La correzione rinforzata è stata integrata nel ramo di rilascio Elements 23.3.x l’8 settembre e Elements v23.3.4 è stato pubblicato il giorno successivo.
Come precedentemente riportato da crypto.news, Liquid ha ripreso la produzione di blocchi dopo che i nodi funzionari hanno ricevuto gli aggiornamenti software richiesti, mentre le operazioni di prelievo sono rimaste disabilitate. Le transazioni sono tornate alla rete mentre Liquid procedeva attraverso il suo processo di recupero a fasi. I prelievi sono rimasti sospesi mentre la federazione completava il lavoro sulla parte del sistema che rilascia BTC dalla riserva.
Sistema PAK e Sicurezza
La seconda parte dell’aggiornamento del 28 settembre si concentra sul sistema PAK utilizzato per autorizzare i prelievi da Liquid a Bitcoin. Sotto l’architettura di Liquid, le voci PAK contengono due chiavi con funzioni separate. Un componente offline è derivato dal portafoglio di ricezione Bitcoin di un membro, mentre una chiave online firma le richieste di prelievo.
I nodi funzionari utilizzano il componente offline per verificare che la destinazione Bitcoin appartenga a un’entrata PAK registrata. Le chiavi private che controllano il Bitcoin di ricezione devono rimanere offline. Il componente online svolge un lavoro diverso: la sua chiave privata opera su un nodo Elements perché è necessaria per firmare le richieste di rilascio di Bitcoin attraverso il processo di prelievo.
La valutazione dell’incidente di Liquid ha dichiarato che l’arrangiamento del portafoglio offline è inteso a fornire un ulteriore livello di protezione se un sistema a monte fallisce. Il Bitcoin rilasciato attraverso un prelievo rimarrebbe in un portafoglio freddo e richiederebbe un’azione separata prima di poter essere spostato ulteriormente.
Conclusioni e Prospettive Future
L’incidente del 6 settembre ha esposto una debolezza in quella protezione, insieme alla vulnerabilità di consenso di Elements. Dopo aver creato gli LBTC non garantiti, l’attaccante ha utilizzato SideSwap, un membro della Liquid Federation con un PAK, per elaborare il prelievo. SideSwap ha ricevuto circa 4.000 LBTC attraverso il suo servizio prima che i firmatari della federazione rilasciassero circa 3.996 BTC su Bitcoin.
La valutazione di Liquid ha dichiarato che due problemi separati hanno consentito il prelievo di Bitcoin: le vulnerabilità di consenso di Elements e una lacuna nella configurazione del processo di firma PAK di un membro della federazione. SideSwap ha dichiarato che la federazione sapeva che la sua chiave di autorizzazione per i prelievi operava online e che questo arrangiamento era stato visibile nei suoi prelievi per anni.
SideSwap ha dichiarato di stare rivedendo come viene detenuta la sua chiave di autorizzazione, così come i limiti e i controlli applicati prima dei pagamenti, e non ripristinerà i suoi servizi di prelievo fino a quando non sarà soddisfatta con la nuova configurazione di sicurezza.
L’ultimo aggiornamento di Liquid conferma ora che la federazione sta sostituendo le voci PAK esistenti e lavorando per garantire che le chiavi di prelievo pertinenti siano detenute in cold storage prima che i prelievi riprendano. L’attività normale delle transazioni è tornata all’inizio di settembre, ma il peg di Bitcoin è rimasto soggetto a restrizioni durante il recupero.
Liquid ha inizialmente fermato i nodi bridge il 6 settembre dopo che l’attaccante ha sfruttato il difetto di Elements. La produzione di blocchi è ripresa il 9 settembre utilizzando la catena corretta, seguita dal ritorno dell’attività delle transazioni degli utenti mentre la federazione monitorava la rete. I prelievi sono rimasti disabilitati durante quelle fasi.
L’incidente originale ha comportato l’uscita di circa 4.000 BTC dalla riserva della federazione dopo che l’attaccante ha creato LBTC non garantiti. Gli attori si sono identificati come white hats attraverso un messaggio on-chain e successivamente hanno restituito 3.400 BTC al portafoglio della federazione dopo che Blockstream ha confermato che i nodi interessati erano stati riparati. Circa 602 BTC rimangono soggetti a sforzi di recupero, secondo l’ultima valutazione dettagliata dell’incidente di Liquid.
Blockstream ha successivamente respinto una richiesta di riscatto legata ai fondi rimanenti, affermando che lavorerà con le forze dell’ordine, gli scambi, specialisti forensi e altri fornitori di servizi per perseguire il loro recupero. Il piano di recupero a fasi di Liquid prevede che le operazioni di prelievo riprendano dopo che lo stato della rete è stato ripristinato e il lavoro di sicurezza richiesto è stato completato. L’audit esterno di Elements v23.3.4 e la sostituzione delle voci PAK sono gli ultimi passi divulgati in quel processo.
