Buongiorno a tutti, ringrazio innanzi tutto Roy Reale per lo spazio concessomi su questo blog. Con questo articolo inizierò a parlare di aspetti più “tecnici” della nostra blockchain preferita, tentando però di semplificare il contenuto in maniera da renderlo accessibile a tutti. Probabilmente ogni tanto pubblicherò anche qualche considerazione personale sull’argomento, dato che oramai che ne ho lo spazio, perché non utilizzarlo a pieno!

Detto questo, iniziamo con un tema caldo in questi ultimi giorni: l’ultimo hack del wallet multisign (a firma multipla) di Parity.

Cos’è Parity e cos’è un wallet a firma multipla?

Probabilmente il software Parity lo conoscerete tutti, è uno dei maggiori wallet e full-node oggi adoperati nell’ecosistema Ethereum. Prodotto dalla Parity Technologies, fondata da Gavin Woods, oggi offre una delle esperienze d’uso più complete nel mondo Ethereum, e molti lo preferiscono al browser/wallet Mist realizzato dalla stessa Fondazione.

Parity, tra le altre cose, offre una funzionalità di wallet multifirma. Cos’è? In sostanza altro non è che un wallet dove, per poter estrarre gli ether depositati, è necessario che vi sia la firma consensuale di più di una delle parti coinvolte. Data l’elevata programmabilità dei contratti di Ethereum, questa funzionalità (come altre) viene gestita attraverso l’uso di contratti.

Cos’è successo?

Il wallet multifirma di Parity è stato lo sfortunato protagonista di due importanti attacchi negli ultimi mesi. Il primo, avvenuto il 19 luglio 2017, e il secondo (ultimo) avvenuto il 6 novembre 2017. In entrambi i casi è stata sfruttata una vulnerabilità simile, ma andiamo per ordine.

Nel primo caso abbiamo assistito ad un furto di circa 153.000 ether, pari a $30M, per una vulnerabilità che permetteva di reimpostare proprietari e chiavi del contratto. In quel caso un gruppo di hacker “buoni” ha tentato di anticipare l’attaccante, provvedendo a rubare prima i fondi rimanenti e restituendoli in seguito, riuscendo di fatto ad arginare i danni. Nel secondo caso invece è stata sfruttata una vulnerabilità simile, che ancora permetteva di reimpostare il proprietario, ma che ha permesso di congelare instantaneamente l’equivalente di circa  513.700 ether, pari a $280M, che forse non verranno mai liberati.

Tra i due casi vi sono però somiglianze e differenze: in comune hanno l’incapacità di realizzare un software adeguatamente testato e revisionato dalla community, prima di consigliarlo come soluzione sicura per lo storage finanziario. Di differente hanno che in questo secondo caso non è in atto una corsa contro il tempo: i danni che si poteva fare sono stati fatti, tutti, e non vi è alcun furto in corso da contrastare.

Magra consolazione? Beh, almeno qui abbiamo tutto il tempo che vogliamo per decidere SE e COME procedere con la risistemazione del danno. Che è sempre possibile, ma non necessariamente voluto.

In questo ultimo caso sono stati coinvolti tutti i wallet creati dal 20 luglio in poi, data in cui è stato rilasciato il fix della versione precedente del contratto.

L’attacco nel concreto

Stando a quanto dichiarato dall’attaccante, tale “devopps199” (prima modificato in “ghost”, poi rimosso da Github), il suo operato è stato accidentale. Altri sostengono che si è trattato probabilmente di un tentativo di furto andato male, ma ai fini pratici poco importa… Fatto sta che dopo aver commesso l’atto pubblica sul repository di Parity questa Issue https://github.com/paritytech/parity/issues/6995.

Da qui si ripercorre l’accaduto. L’utente avrebbe avuto alcuni problemi con la creazione di un proprio wallet, e cercando di eliminarlo, avrebbe invece eliminato la libreria centrale alla quale invece tutti i wallet sono collegati https://etherscan.io/address/0x863df6bfa4469f3ead0be8f9f2aae51c91a907b4.

Come funziona un wallet multisign:

• ciascun wallet è assegnato ad un contratto
• ciascun contratto, per motivi di ottimizzazione, si collega ad una libreria comune che ne implementa le funzioni
• la libreria è (in teoria) immutabile
• la libreria (in teoria) non possiede autonomia ed alcun dato relativo a singoli wallet

Quel che è venuto meno sono questi ultimi due assunti. La libreria comune infatti implementava pubblicamente il metodo in grado di inizializzare un nuovo wallet (lo stesso metodo sfruttato dall’attacco precedente!). Questo metodo, poichè richiamabile solamente a wallet non inizializzato, era di fatto richiamabile da chiunque in qualsiasi momento, poichè la libreria non era inizializzata.

L’attaccante ha quindi eseguito due transazioni:

1. ha inizializzato la libreria impostandosi come owner (proprietario) della stessa, trasformandola di fatto in un wallet multisign a tutti gli effetti

   // throw unless the contract is not yet initialized.
   modifier only_uninitialized { if (m_numOwners > 0) throw; _; }
   
   // constructor - just pass on the owner array to the multiowned and
   // the limit to daylimit
   function initWallet(address[] _owners, uint _required, uint _daylimit) only_uninitialized {
     initDaylimit(_daylimit);
     initMultiowned(_owners, _required);
   }

2. ha chiamato la funzione kill, a questo punto a lui accessibile, che ha distrutto il codice, ed ha reso inservibile la libreria

   // kills the contract sending everything to `_to`.
   
   function kill(address _to) onlymanyowners(sha3(msg.data)) external {
     suicide(_to);
   }

Di riflesso, ogni nuovo wallet che riferisse a questa, ha smesso di funzionare, bloccando di fatto i crediti.

Possibile soluzione

Il team di Parity ha pubblicato un bollettino di sicurezza in cui analizza l’accaduto https://paritytech.io/blog/security-alert.html, ma poichè il codice del wallet non è aggiornabile (https://github.com/paritytech/parity/blob/e06a1e8dd9cfd8bf5d87d24b11aee0e8f6ff9aeb/js/src/contracts/snippets/enhanced-wallet.sol), e non sembra vi sia un semplice workaround al problema, vi sono fondamentalmente 2 possibili vie d’azione:

• eseguire un fork di ethereum, dove può essere ad esempio ripristinata una versione funzionante (E TESTATA!) del contratto libreria all’indirizzo precedente
• non fare nulla

Da una parte il fork potrebbe essere proposto come un EIP (Ethereum Improvement Proposal) da includere nella prossima release Constantinople, dall’altra però quello che si vuole evitare è che si venga a creare un nuovo “The DAO” 2.0, in cui il consenso prenda due strade differenti, creando di fatto un nuovo Ethereum Classic^2. Anche in questo caso però, rispetto al caso di The DAO, non vi è urgenza per prendere alcuna decisione. Il danno è fatto. Dalla Fondazione questa volta sembra che arrivi un messaggio di “responsabilità ai responsabili” e di lasciare quindi tutto immutato, il che non sarebbe nemmeno concettualmente sbagliato. C’è una leziona da imparare qui, sull’assicurarsi superficialmente ad un contratto non adeguatamente revisionato.

Aggiornamento:

Nel periodo di scrittura dell’articolo, il team di Parity ha pubblicato il seguente bollettino (https://blog.ethcore.io/parity-technologies-multi-sig-wallet-issue-update/) nel quale si invoca la possibilità di applicare una modifica come l’EIP156 (https://github.com/ethereum/EIPs/issues/156) o simile, che sia quindi in grado di rilasciare i fondi in determinati casi specifici, aggirando i limiti del contratto. Una proposta come questa, se sufficientemente generalizzata e considerata razionale, potrebbe trovare un consenso generale e non richiederebbe un hard-fork ad-hoc potenzialmente contenzioso. Sarebbe comunque richiesto un hard-fork programmato per l’applicazione, che potrebbe essere il sopracitato Constantinople, o un suo successivo.

Considerazioni finali

Il primo attacco è avvenuto il 19 luglio 2017, il giorno dopo, il 20 luglio, veniva rilasciata quest’ultima versione. Quindi solo dopo 1 giorno di sviluppo e test, evidentemente il primo colpo non è bastato. Le verifiche effettuate si sono rivelate assolutamente inefficienti, e non adeguate al caso d’uso previsto dal contratto stesso. L’exploit è sopravissuto pubblicamente 109 giorni, senza che venisse sfruttato. Questo significa che tale tempo può quindi essere ancora considerato all’interno di una finestra di potenziale vulnerabilità per un contratto del genere, 1 giorno non è assolutamente sufficiente.

Quello che poteva essere fatto dal team di Parity, nel momento del primo attacco, era:

• Bloccare immediatamente la libreria precedente
• Disattivare la funzione multifirma del wallet, in attesa di una versione adeguatamente testata
• Rilasciare solo dopo adeguate procedure di verifica la nuova versione, possibilmente supportate da un bug bounty pubblico

Quello che invece la comunità intera di utilizzatori e sviluppatori dovrebbe imparare è:

• Mai affidarsi ciecamente a contratti che non sono stati revisionati adeguatamente e pubblicamente in precedenza
• Vanno potenziati i pattern comuni di sviluppo su Solidity e altri linguaggi per Smart Contract
• Tali pattern vanno quindi rafforzati da strumenti di analisi automatica del codice
• Va quindi portata avanti la ricerca, ed incentivato l’uso della verifica formale sul codice. L’innalterabilità dei contratti li rende infatti applicazioni maggiormente critiche rispetto ad un normale software medio

Per ora è tutto, fatemi sapere cosa ne pensate nei commenti. Eventuali aggiornamenti verranno trattati negli articoli successivi.

Clicca qui per accedere alla guida gratuita su come comprare, vendere, trasferire e conservare in sicurezza gli Eth