Lo smart contract di GUSD consente il furto dei pagamenti antispam

I gemelli Winklevoss sono famosi per aver fondato Facebook (e per questo nel 2008 hanno anche ottenuto 65 milioni di dollari di risarcimento da Mark Zuckerberg). Nel 2013 hanno investito largamente in Bitcoin, acquistando circa l’1% delle monete esistenti di questa criptovaluta, a 120 dollari l’una.

Subito dopo, i fratelli hanno creato l’exchange di criptomonete Gemini e nel 2018 hanno lanciato la stablecoin Gemini dollar (o GUSD). La stablecoin è una criptomoneta a tasso fisso, ovvero 1 token GUSD equivale sempre a 1 dollaro statunitense. Le stablecoin sono comode per “digitalizzare” i dollari veri e propri e consentono il movimento rapido e facile dei dollari blockchain tra i vari exchange. A garantire la conversione inversa in dollari è la compagnia che ha emesso e venduto questa criptomoneta.

Utilizzando il nostro Review, abbiamo analizzato uno smart contract che offre la funzionalità GUSD e abbiamo riscontrato una falla.

Nota

Lo smart contract in questione è già stato esaminato, anche se non sappiamo se nel report siano stati descritti dei difetti nel codice.

Seguendo la nostra politica aziendale di Responsible Disclosure, ci siamo messi in contatto con il team di sicurezza di Gemini per informarli e ci hanno risposto che il problema in questione era già stato preso in considerazione durante la fase di progettazione e che non costituisce un rischio per il GUSD.

Se volete saperne di più sul funzionamento degli smart contract, vi consigliamo di leggere il nostro post su Ethereum e gli ICO,

Gli smart contract di Gemini dollar

In generale, quando si vogliono creare nuovi token basandosi sulla blockchain Ethereum, si scrive uno smart contract (ovvero un miniprogramma) con le seguenti specifiche:

1. Dati (“questi token si trovano a questo indirizzo”);
2. Metodologie (“trasferisci i miei token a questo indirizzo” e altro).

Gli ideatori del sistema Gemini dollar hanno implementato i seguenti miglioramenti:

1. Hanno suddiviso il contratto in tre componenti: proxy (l’interfaccia permanente con la quale si interagisce e si effettuano le operazioni), Store (la mappatura dei possessori di token con I loro bilanci) e Impl (la logica sottostante);
2. Il componente che riguarda la logica può essere aggiornato e vi si possono aggiungere nuove funzionalità come la possibilità di congelare i fondi. Nel frattempo, i dati e l’interfaccia rimangono immutati e l’aggiornamento è trasparente per tutti;
3. In caso di aggiornamento e controllo, viene impiegato uno smart contract custode (“Custodian”) gestito da diverse persone per una maggiore protezione (i custodi, per l’appunto). Se un custode propone un’azione, gli altri devono confermarla affinché possa avere luogo.

Questi miglioramenti servono per aumentare la sicurezza generale del sistema e per incrementare la sua flessibilità.

Pagamenti antispam

Se qualcun altro al di fuori dei custodi principali inoltra una proposta all’interno del contratto custode, deve pagare una quota di 1 EHT (200 dollari circa secondo il tasso di cambio corrente). Come specificato nei commenti al contratto, la misura antispam serve per dissuadere i partecipanti in modo tale che non inoltrino troppe richieste.

I pagamenti antispam sono rivolti a una persona, colei che conferma l’approvazione di quella proposta/richiesta in particolare. L’implementazione non è l’ideale, ma dai commenti si evince chiaramente che i suoi creatori l’hanno concepita proprio in questo modo:

} else {

            if (address(this).balance > 0) {

                // reward sender with anti-spam payments

                // ignore send success (assign to ʹsuccessʹ but this will be overwritten)

                success = msg.sender.send(address(this).balance);

Per quanto ci riguarda, consigliamo l’uso del Solidity Withdrawal Pattern.

Cybercriminali utilizzano il front-running per appropriarsi di tutti i pagamenti antispam

La persona che approva la richiesta riceve anche tutti i pagamenti antispam in ETH.  Per fare ciò, utilizza la funzionalità completeUnlock e passa nei parametri le firme dei due custodi.

Il problema è che Ethereum, come qualsiasi blockchain, esegue le richieste con un certo ritardo. Una transazione di un cliente (come il trasferimento di denaro o l’uso di una funzionalità) restano in coda per un certo tempo (di solito durante una quindicina di secondi o anche più). Durante questo lasso di tempo, chiunque può visualizzare i trasferimenti di denaro previsti da parte di altri utenti Ethereum, comprese informazioni importanti come somme, destinatari e parametri. I cybercriminali possono utilizzare queste informazioni per creare le proprie transazioni e spingerle in cima alla coda pagando una commissione più alta al miner.

Qualsiasi vantaggio ottenuto sbirciando le operazioni degli altri viene considerata come front-running, una particolare forma di attacco.(Attacchi conosciuti: Front-running).

Traduzione estatto da investopedia.com:

Il front-running avviene quando un broker o un’altra entità accede a un affare perché è venuto a conoscenza previamente di una grande transazione non pubblicizzata e che influirà sul prezzo dell’asset, il che probabilmente porterà a un guadagno per il broker. Ciò avviene anche quando un broker o un analista acquistano o vendono azioni per se stessi prima di consigliare la compravendita ai propri clienti a nome dell’azienda.

Nel nostro caso, una persona dall’esterno può configurare un robot affinché vigili il contratto custode. Se rileva che qualcuno richiede la funzionalità completeUnlock (il che vuol dire che un custode sta interagendo con Gemini dollar), il robot copia immediatamente tutti i parametri e richiede la funzionalità per estrarre l’Ether accumulatosi.

Per contrastare un attacco di questo tipo, ancora una volta consigliamo il popolare metodo Solidity Withdrawal Pattern.

E al di là di tutto, consigliamo anche di bloccare la possibilità a sconosciuti di richiedere una funzionalità rivolta ai custodi.

Implementazione pratica dell’attacco

Se in teoria appare come pericolosa, nella pratica questa vulnerabilità riscontrata non è poi così drammatica. Ecco perché:

1. I pagamenti antispam non sono una grande preoccupazione per i custodi di grandi venure come Gemini dollar. La capitalizzazione dei GUSD (ovvero il volume totale di token emessi) ha raggiunto i 100 milioni di dollari come apice e anche adesso supera i 5 milioni di dollari;
2. I pagamenti antispam non sono ancora apparsi in questo contratto e potrebbero non comparire mai in quanto il custode principale non è obbligato in alcun modo a depositari (tutti gli altri invece sì);
3. Dopo essere venuti a conoscenza della vulnerabilità, gli utenti possono semplicemente evitare la funzionalità vulnerabile o aggiornare il contratto;
4. Durante l’analisi, non abbiamo riscontrato vulnerabilità che minaccino i token GUSD.

A tal proposito, Gemini afferma: “Abbiamo scelto questa struttura perché Gemini non ha intenzione di beneficiare Ether in condizioni normali e, di conseguenza, abbiamo preso la decisione (con un certo rischio) di non estendere materialmente la complessità del nostro codice solamente per il beneficio non materiale di un meccanismo di ripristino più robusto, riguardante un’ipotetica quota antispam nominale. La miglior soluzione per Gemini dollar e per i suoi utenti è dare la priorità a un codice semplice e sicuro. In futuro, se ci fossero cambiamenti che portino alla necessità di creare un contratto più complesso e costoso, potremmo rivedere questa decisione”.

Abbiamo deciso di pubblicare questo post coordinandoci con Gemini, poiché le somme antispam sono a rischio solo se si verificano una serie di circostanze specifiche e non così probabili, e perché GUSD non è in pericolo.

Ancora una volta, reiteriamo la necessità di adottare un approccio di sicurezza olistico nei confronti degli ICO e delle altre attività relazionate alle criptomonete e alle blockchain.