Timestamp, algoritmi di Mining, difficoltà e tanto altro!L’attacco subito da Verge

Premessa: questo articolo riprende quanto scritto da Daniel Goldman al seguente indirizzo, clicca qui. L’argomento ci è sembrato particolarmente interessante e pertanto abbiamo deciso di riportarlo.

 

La questione della sicurezza è fondamentale per le blockchain.

Al giorno d’oggi i cripto-sostenitori non fanno altro che spiegare alle persone comuni quanto siano sicure le proprie criptovalute preferite.

Di fatti, alcune monete come Bitcoin ed Ethereum, sono state in grado di mantenere un ottimo livello di sicurezza – in misura, consentitemelo, anche superiore ai tradizionali sistemi di pagamento digitale – il che è notevole, dato che queste valute digitali non sono sottoposte al controllo di terze parti, banche o governi e che hanno effettivamente delle taglie multimiliardarie sulle proprie teste. Alcuni sono disposti ad andare oltre e dichiarare tali criptovalute come “impossibili da hackerare”. Questo, tuttavia, causa imbarazzo quando in realtà questo tipo di situazioni accadono. Come nel caso di un attacco hacker.

Prendiamo il caso di Verge. Il mese scorso, un hacker è stato in grado di attaccare Verge e compromettere il network. Per chi non la conoscesse, Verge è una criptovaluta sviluppata con un focus sulla privacy, la cui capitalizzazione ammonta a circa $600 milioni.

L’hacker misterioso è riuscito a guadagnare il controllo del network per ben tre volte, a intervalli di alcune ore, tra il 4 ed il 6 aprile, impedendo agli altri utenti di effettuare pagamenti. E come se non fosse abbastanza, l’hacker è anche riuscito a compromettere l’algoritmo di mining, stampando Verge ad un ritmo di 1560 monete al secondo (circa $80) – riuscendo ad emettere monete per un importo superiore al milione di dollari. Senza girarci troppo intorno.. Un completo disastro!

Ma di chi è la colpa?
È possible che sia colpa degli sviluppatori?
O si tratta di una falla comune a tutte le criptovalute?
È possibile che simili episodi si ripetano anche in criptovalute più conosciute, come Bitcoin ed Ethereum?

Andiamo ad analizzare le cause del problema – anzi, dei problemi.

Forgiatura dei Timestamp

L’exploit in questione non è proprio da considerare come un bug, ma piuttosto come una caratteristica che è stata inserita deliberatamente nel codice.

Per essere inserite in una blockchain, le singole transazioni vengono raggruppate all’interno di un blocco, che viene poi confermato. Ogni blocco viene marchiato con un “timestamp”, un bollo che indica l’ora precisa in cui è stato confermato. Anche quando una blockchain funziona correttamente, può accadere che l’ordine dei timestamp sia fuori sequenza, ad esempio: che il blocco #100 possa essere dopo il blocco #101.

Questo accade in quanto la sincronizzazione in un corretto ordine cronologico è molto difficile da coordinare in un network decentralizzato. Data l’imprevedibile varietà con la quale un blocco viene propagato nel network peer-to-peer è possibile che i timestamp non siano nell’ordine corretto – anche nel caso in cui tutte le parti siano oneste. In poche parole, la possibilità di modificare i timestamp è stata inserita per garantire un minimo di flessibilità; nel caso di Verge il protocollo consente ai nodi di poter non essere d’accordo sul corretto timestamp per una finestra massima di due ore.

L’attacco in questione si è svolto nella seguente maniera: l’attaccante ha iniziato a modificare i timestamp dei blocchi che minava, facendo apparire questi ultimi come se fossero blocchi passati, ma comunque entro la finestra massima di due ore – e quindi considerati validi. Il motivo per il quale questo procedimento è stato utilizzato dall’hacker ha a che vedere con gli algoritmi di proof-of-work utilizzati da Verge.

 

La difficoltà del mining

(O: I cancelli funzionano solamente quando sono chiusi)

Per garantire al network Verge il massimo grado di decentralizzazione è necessario assicurare che anche dispositivi di piccola scala possano eseguire il software.

Questo implica limitare il volume di transazioni che possono aver luogo, ad esempio limitando arbitrariamente la distanza tra i blocchi (e di conseguenza il numero di transazioni al secondo). Nel caso di Verge, il tempo medio tra un blocco e l’altro è di 30 secondi.

Ma vista la decentralizzazione del network, come si può far rispettare questo limite? Cosa impedisce alle parti in questione di minare blocchi ad un ritmo più alto?

Questo tipo di problemi è risolto mediante l’impiego di incentivi economi: ogni blocco valido risulta in un “premio” a chi lo inserisce nella blockchain; è quindi nell’interesse dei miner di confermare i blocchi nella maniera più veloce possibile.

Il processo di validazione avviene grazie alla proof-of-work, lo stesso algoritmo impiegato nella maggior parte delle blockchain – tra cui Bitcoin. Per considerare un blocco come valido, esso deve contenere la soluzione di una specie di lotteria matematica, risultato dalle informazioni contenute all’interno del blocco stesso. La natura del problema è tale da permettere l’aggiustamento della difficoltà in caso di variazioni straordinarie nella tempistica di inserimento dei blocchi.

Dato che l’obiettivo di Verge è un tempo di 30 secondi, la difficoltà è costantemente modificata, basandosi sul ritmo di conferme dei blocchi; nel caso in cui un numero maggiore di persone decidesse di devolvere maggior potere computazionale per generare nuovi blocchi, aumentando così la velocità di conferma dei blocchi, il protocollo riconfigurerà la difficoltà di mining. Allo stesso modo, nel caso opposto, la difficoltà verrà diminuita. Pertanto, il network Verge reagisce costantemente, cercando di mantenere l’equilibrio – un tempo di 30 secondi.

L’algoritmo utilizzato da Verge per calcolare la difficoltà del network è chiamato Dark Gravity Wave (Onda Gravitazionale Oscura, in italiano – molto sci-fi). Funziona calcolando la media del tempo di conferma del blocco in una finestra di due ore. Senza andare nelle tecnicalità, possiamo estrapolare quanto segue: la difficoltà di mining è una funzione della recente frequenza delle conferme di un blocco; quindi, eseguire calcoli matematici sulla frequenza dei blocchi implica tener conto dei timestamp dei blocchi.

È proprio qui che sorge il problema: il network può essere ingannato nel caso in cui vengano emessi un numero abbastanza importante di finti timestamp.

Questa è esattamente la tattica adottata dall’hacker: per tutta la durata dell’attacco egli minava dei nuovi blocchi, ma con un timestamp di circa un’ora nel passato (t-1), confondendo così l’algoritmo di aggiustamento della difficoltà:

“Oh no, nell’ultima ora non sono stati confermati abbastanza blocchi! Questo vuol dire che la difficoltà di mining è troppo alta, bisogna renderla più facile!”

Dato che i timestamp continuavano ad essere manipolati utilizzando la stessa tecnica, la difficoltà ha continuato ad essere ridimensionata, rendendo il mining incredibilmente semplice. Per dare un’idea, la difficoltà media nelle ore precedenti all’attacco era di 1393093.39131, mentre durante l’attacco ha raggiunto un minimo di 0.00024414 – una diminuzione del 99,99%, rendendo l’attaccante in grado di minare circa un blocco al secondo.

La particolarità di questo attacco sta nel fatto che invece di provare a penetrare la barriera di sicurezza del network, l’hacker è invece riuscito a trovare un punto debole, rendendo le mura intorno al castello da saccheggiare un semplice cancelletto da poter scavalcare con facilità.

Come potete facilmente intuire, una violazione del protocollo così evidente non mette la sicurezza di Verge in buona luce.

Ma questo non è tutto, anzi, l’abbassamento della difficoltà è solamente metà della storia, in quanto questo trucchetto da solo non avrebbe garantito all’hacker alcun vantaggio.

Infatti, con la riduzione della difficoltà per minare i blocchi diventa più facile per chiunque, e non solamente per l’attaccante – i miner sono sempre e comunque in competizione tra di loro. Sarebbe quindi razionale pensare che, nonostante i blocchi vengano minati più velocemente, le identità dei miner in questione saranno distribuite e altrettanto democratiche. Un hacker avrebbe ancora bisogno del 51% del potere computazionale per poter dominare il network.

Fatto sta che l’hacker in questione è riuscito a prendere il controllo del network con molto meno del 51% dell’hash rate, grazie al secondo componente dell’attacco, che riguarda l’utilizzo di molteplici algoritmi di mining da parte di Verge.

Il mining di Verge

(O: Quando cinque algoritmi non sono meglio di uno)

In un tradizionale network basato sul proof-of-work, le criptovalute vengono minate con un singolo algoritmo – il più utilizzato è chiamato SHA-256. Tuttavia, Verge impiega ben 5 diversi algoritmi (Scrypt, X17, Lyra2rev2, myr-groestl and blake2s.).

La scelta di impiegare diversi algoritmi può essere ricondotta al seguente ragionamento:

Una delle –tante– critiche mosse a Bitcoin è il fatto che l’industria del mining sia diventata troppo specializzata e centralizzata. Al momento, la maggioranza del mining sul network Bitcoin avviene tramite l’utilizzo di ASICs, dispositivi creati con l’unico scopo di effettuare operazioni di mining. La maggioranza del mining sul network Bitcoin è quindi effettuato da una manciata di compagnie di mining – in gergo “mining pools”.

Questo tipo di trend verso la “centralizzazione” del mining è deleterio per la value proposition principale delle criptovalute e cioè la loro decentralizzazione. Utilizzare molteplici algoritmi di mining dovrebbe quindi garantire un maggiore livello di sicurezza contro una possibile centralizzazione e lo sviluppo di hardware dedicato – rendendo quindi il network Verge più distribuito e decentralizzato.

Tuttavia, l’impiego di cinque diversi algoritmi introduce altre complessità nell’ecosistema. Di fatti, per evitare che in qualsiasi momento ci sia un algoritmo dominante, la difficoltà di mining viene calcolata individualmente per i singoli algoritmi, in modo tale da raggiungere l’equilibrio dei 30 secondi.

Di fatto, la riduzione della difficoltà causata dall’hacker non riguarda tutto il network, ma bensì coloro che minavano con l’algoritmo per la quale è stata modificata: Scrypt. Quindi, mentre i miner che utilizzavano l’algoritmo Scrypt godevano di una difficoltà pressocchè nulla, tutti gli altri miner, invece, erano soggetti al livello di difficoltà tradizionale, rendendo il loro hashing power effettivamente inutile per garantire la sicurezza del network.

Questo vuol dire che l’hacker era in competizione solamente con gli altri miner che utilizzavano Scrypt. La necessaria percentuale di hashing power per dominare il network scende quindi dal 50% (per dominare l’intero network) a circa il 10% (per dominare gli altri miner che utilizzano Scrypt).

Per concludere: la modifica dei timestamp ha reso possibile la riduzione drastica della difficoltà; l’utilizzo di cinque algoritmi vuol dire che è possibile ridurre la difficoltà di uno di loro, rendendo molto più facile l’acquisizione di controllo su tutto il network; per finire, il nuovo tempo di blocco – conseguenza della riduzione della difficoltà – ha reso possibile un guadagno superiore di circa 30 volte a quello che i miner avrebbero guadagnato in condizioni normali (difficoltà ridotta da 30 secondi a 1).

Conclusioni

Nei giorni superiori all’hacking, il network è stato soggetto di un hard fork.
Inoltre, in maniera molto curiosa, il prezzo di Verge è aumentato del 30%, grazie alla partnership annunciata con PornHub.

Cosa possiamo imparare da tutto ciò?
Quali conclusioni si possono trarre da questo attacco?

Innanzitutto, l’utilizzo di timestamp per calcolare la difficoltà era, già da molto tempo, considerata una vulnerabilità – il “time-warp exploit”. In questo senso, ciò che ha reso possibile questo attacco è proprio il nuovo algoritmo di aggiustamento della difficoltà (Dark Gravity Wave), dove la difficoltà viene calcolata ad ogni blocco. Questo è in netto contrasto con Bitcoin, dove la difficoltà viene aggiustata ogni 2016 blocchi – circa 2 settimane. Nel caso in cui un hacker riuscisse a diminuire la difficoltà del network Bitcoin, egli potrebbe farlo solamente una volta ogni due settimane, al contrario di Verge dove questo attacco può essere eseguito ogni 30 secondi.

E pensare che uno dei millantati benefici di questo nuovo algoritmo (Dark Gravity) era proprio quello di essere immune ad attacchi time-warp.

Riguardo all’uso di cinque algoritmi: mentre questo può sembrare un esperimento interessante per stimolare la decentralizzazione, introduce nuove complessità che portano, inevitabilmente, alla nascita di nuove vulnerabilità.

In entrambi i casi, questo hack rafforza l’argomento tradizionalista, dove solamente sistemi che sono stati provati sicuri dovrebbero essere impiegati, invece di utilizzare sistemi super complicati che non fanno altro che introdurre rischi non necessari. Il che vuol dire due punti per il team Bitcoin!

Questo è il punto principale di questo articolo: gli sviluppatori, seppur non amino ammetterlo, sono solamente umani. Nonostante essi comprendano perfettamente i presupposti dei principi di sicurezza del proprio network, c’è sempre spazio per degli errori. Nuovi vettori di attacco possono emergere, e spesso i trade-off a riguardo sono stimati con superficialità. Non sempre i software funzionano come ci si aspetta e alcuni malfunzionamenti possono portare alla perdita di fondi, soprattutto nel caso di sistemi che mettono in sicurezza svariati miliardi di dollari.

Dato che molto spesso non si ha il tempo materiale (o le capacità) di poter condurre una propria review del codice, la miglior guardia contro attacchi o eventuali imprevisti è quella di riporre maggior fiducia in quel tipo di sistemi che si sono dimostrati come più sicuri. Nel caso in cui si scegliesse l’utilizzo di sistemi sperimentali bisognerebbe essere a conoscenza dei rischi che si corrono.

N.B. Il 22 maggio la stessa vulnerabilità è stata sfruttata per un altro attacco.
Stavolta l’hacker ha utilizzato due algoritmi invece di uno!

Leave a Comment

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

*