La riorganizzazione di 13 blocchi di Litecoin non era uno zero-day: la cronologia dei commit su GitHub lo smentisce

Una riorganizzazione della blockchain lunga 13 blocchi su Litecoin, avvenuta quando il prezzo si aggirava intorno a 56,25 dollari tra venerdì sera e sabato, ha annullato circa 32 minuti di attività della rete dopo che aggressori hanno sfruttato una vulnerabilità nel Mimblewimble Extension Block (MWEB).

Dettagli dell’attacco

La falla ha consentito un attacco di tipo denial-of-service contro importanti pool di mining, facendo sì che transazioni MWEB invalide scorressero attraverso nodi che non erano stati aggiornati, prima che la catena valida più lunga ripristinasse lo stato corretto della rete.

La Litecoin Foundation ha comunicato che il problema è stato risolto e che la rete è tornata a funzionare normalmente, ma alcune analisi pubbliche successive hanno messo in luce discrepanze nella cronologia delle patch rispetto a quanto dichiarato nel comunicato ufficiale.

Cronologia delle patch e commit

Un ricercatore di sicurezza noto come bbsz, che collabora con il gruppo di risposta alle emergenze SEAL911, ha pubblicato una ricostruzione della timeline ricavata dal registro pubblico dei commit su GitHub.

bbsz said:

“L’analisi post-mortem afferma che un zero-day ha causato un DoS che ha permesso a una transazione MWEB non valida di passare. Il registro git racconta una storia leggermente diversa.”

Secondo i commit pubblicati, la vulnerabilità di consenso che permetteva l’uscita di fondi da MWEB era stata corretta in privato tra il 19 e il 26 marzo, circa quattro settimane prima dell’attacco. Un’altra falla che consentiva un attacco di tipo DoS è stata invece risolta la mattina del 25 aprile. Entrambi gli interventi sono stati poi inseriti nella release 0.21.5.4, emessa lo stesso pomeriggio dopo che l’attacco era già iniziato.

Il termine zero-day indica una vulnerabilità non nota ai difensori al momento dell’attacco; in questo caso, i registri indicano che almeno una delle correzioni era già pronta ma non era stata ancora resa pubblica o adottata universalmente.

Meccanica dell’exploit

I dati on-chain mostrano che l’attaccante ha prefinanziato un portafoglio 38 ore prima dell’exploit tramite un prelievo da Binance, con l’indirizzo destinazione predisposto per convertire LTC in ETH su uno scambio decentralizzato. L’analisi suggerisce che il DoS e il bug del MWEB sono stati usati in combinazione.

Alex Shevchenko said:

“Il DoS e il bug MWEB sono componenti separati: il DoS è stato pensato per mettere offline i nodi aggiornati, così che quelli non aggiornati componessero la catena che includeva le transazioni invalide.”

In pratica, gli aggressori sembrano aver sfruttato il fatto che alcuni miner avevano già applicato la patch mentre altri continuavano a eseguire codice vulnerabile. Il DoS avrebbe servito a ridurre temporaneamente la potenza di mining aggiornata, permettendo alla fork non aggiornata di produrre la catena contenente le transazioni malevoli. Quando l’attacco DoS è terminato, la maggiore potenza di calcolo dei nodi aggiornati ha infine imposto la catena corretta, generando la riorganizzazione di 13 blocchi che ha annullato le transazioni malevoli dopo circa 32 minuti.

Non è stato reso noto l’ammontare preciso di LTC coinvolto nel periodo di blocco invalido né il valore delle conversioni eventualmente effettuate prima che la riorganizzazione le annullasse.

Implicazioni per la sicurezza delle reti proof-of-work

Questo episodio evidenzia differenze operative tra catene più recenti e reti proof-of-work tradizionali. Progetti con insiemi di validatori più piccoli e centralizzati tendono a coordinare gli aggiornamenti rapidamente tramite canali chiusi, riducendo la finestra in cui un attaccante può sfruttare una patch non ancora adottata.

Al contrario, reti storiche basate su proof-of-work come Litecoin e Bitcoin dipendono da pool di mining indipendenti che aggiornano il software in modo asincrono. Questo modello è efficace per cambiamenti non urgenti, ma crea una vulnerabilità significativa se una patch di sicurezza non raggiunge rapidamente tutti gli attori rilevanti.

Per investitori e operatori di mercato, la lezione è chiara: la decentralizzazione operativa migliora la resilienza contro censura e controllo, ma può introdurre fragilità quando la tempestività degli aggiornamenti è cruciale per la sicurezza del protocollo.

Azioni e trasparenza

La vicenda solleva interrogativi sulla trasparenza delle procedure di gestione delle patch e sulla comunicazione tra manutentori del codice e operatori della rete. In assenza di un chiarimento pubblico completo sulla sequenza dei commit e sull’adozione delle correzioni, permangono dubbi sul grado di coordinamento interno e sulla rapidità con cui le patch vengono propagate nell’ecosistema dei miner.

Per ridurre il rischio di situazioni analoghe, gli esperti suggeriscono di rafforzare i protocolli di divulgazione coordinata delle vulnerabilità, migliorare i canali di comunicazione con i pool di mining e valutare strumenti tecnici che consentano una più rapida adozione delle patch critiche senza compromettere la natura decentralizzata della governance.

In sintesi

• La frammentazione nell’adozione delle patch rappresenta un rischio operativo per le reti proof-of-work; per gli investitori italiani ciò significa considerare la qualità della governance tecnica come un fattore di rischio nelle valutazioni di portafoglio.
• Eventi di riorganizzazione come questo possono erodere temporaneamente la fiducia del mercato e aumentare la volatilità dei prezzi di progetto; strategie di gestione del rischio dovrebbero includere la valutazione della resilienza del protocollo alle patch non sincronizzate.
• Un miglior coordinamento tra sviluppatori, pool di mining e operatori di exchange ridurrebbe le finestre di esposizione e limiterebbe l’impatto economico di exploit simili, influenzando positivamente l’attrattiva degli asset digitali per investimenti istituzionali in Europa.