Digital Davide

Cos’è e perché fare l’audit di uno smart contract

In realtà gli audit di sicurezza andrebbero chiamati più correttamente external code reviews. Il termine audit è mutuato dalla finanza dove si intende più genericamente l’analisi contabile e della situazione patrimoniale di un’azienda che deve rispondere ai propri utenti o azionisti del modo in cui gestisce le proprie disponibilità economiche e i fondi dei propri clienti. Questo per il semplice fatto che se un’entità come una banca o altro intermediario finanziario non garantisce una corretta gestione dei fondi suoi e dei propri clienti c’è un forte rischio di causare delle perdite patrimoniali.

Nel caso degli smart contract abbiamo una situazione ibrida in cui in realtà parliamo di software e non di bilanci societari, ma in un certo senso essendo uno smart contract denaro programmabile ecco che la terminologia si confonde.

Come abbiamo già evidenziato in un precedente articolo, quando uno smart contract che gestisce transazioni finanziarie è affetto da un bug i problemi che ne derivano possono essere gravi e non recuperabili.

Emblematico è il caso di TheDao hack nel 2016, che a causa di un reentrancy bug ha causato perdite per centinaia di milioni di dollari e a costretto la community ad attivare un hard fork a livello dell’intera rete Ethereum.

Nella tabella sotto sono riassunte le maggiori differenze tra i danni causati da un bug nel software tradizionale Vs. smart contract.

Attacco/Bug	Software tradizionale	Smart contract
Denial of service	Il danno è proporzionale al tempo in cui persiste il denial-of-service. Minore è il tempo di recupero minore sarà il danno.	Tecnicamente non è possibile mandare il vostro contratto in DoS, ma l’intera rete Ethereum potrebbe rendere difficile l’interaione con il vostro contratto se le gas fee sono molto alte
Data Leak	In questo caso se si tratta di dati personali o segreti industriali, gli hacker possono chiedere un riscatto e causare un danno economico e reputazionale.	Non avrebbe senso immaginare un data leak visto che gli smart contract eseguono codice e dati visibili ed eseguibili pubblicamente. Se tali dati sono offuscati prima di raggiungere la blockchain allora il bug non riguarderebbe lo smart contract
Data corruption	Nel software tradizionale ovviamente la corruzione dei data causa una perdita economica, ma è possibile in genere recuperare da backup e ripristinare lo stato corretto. L’impatto è dunque lineare e proporzionale al tempo di recovery	Data Corruption = LOSS. Questo è il caso più drammatico per lo smart contract. La corruzione di un dato o il valore inaspettato di un registro o variabile di stato può creare un disastro non recuperabile.

Chi dovrebbe fare l’audit dei nostri smart contract

Come evidenziato in precedenza stiamo parlando di codice software e non di bilanci e contabilità, quindi è necessaria una figura professionale con competenze nello specifico linguaggio di programmazione degli smart contract (comunemente solidity) che sia aggiornata e formata sulle best practice e antipattern tipici dello sviluppo software di smart contract.

“La paranoia è una virtù”

E’ necessario anche una specifica attitudine, infatti se lo sviluppatore di software deve stare molto attento alla sicurezza del codice che scrive, auditors e sviluppatori di smart contract dovrebbero esserne ossessionati.

Quanto costa un audit di smart contract e quanto tempo ci vuole

Quello degli “audit degli smart contract” in realtà è un mercato come tutti gli altri. Esistono agenzie con nomi molto blasonati e altri professionisti meno conosciuti.

Da un lato affidarsi ad una grande agenzia può darci la sensazione di andare sul sicuro e può risultare un accreditamento a livello di marketing. Naturalmente il costo in questo caso può essere molto significativo. In alternativa attraverso Google è possibile trovare centinaia di offerte più abbordabili. In questo caso è sempre bene cercare di capire quale sia l’effettiva competenza del professionista che andrà a svolgere il lavoro.

I costi per un audit dipendono ovviamente dalla complessità del progetto. VA da se che un progetto con pochi contratti e poche linee di codice sarà molto meno costoso da verificare di uno con decine di contratti e decine di migliaia di linee di codice.

Per eseguire l’audit infatti, oltre all’utilizzo di strumenti automatici, sono necessarie molte ore di tempo di personale altamente qualificato impiegate nell’ispezione manuale del codice.

I costi possono quindi variare dalle poche migliaia alle decine di migliaia di euro per progetti di media complessità. In alcuni casi di progetti molto complessi l’audit potrebbe richiedere mesi e vari passaggi moltiplicando i costi indicati sopra anche di un fattore x10.

Quali sono le fasi di un audit

L’audit è un’attività abbastanza complessa che può riassumersi nelle seguenti fasi:

Innanzitutto si deve lavorare con il cliente per avere una serie di requisiti stringenti rispettati ancora prima di iniziare l’audit:

• Il codice deve essere disponibile in un repository Git per verificare i vari commit
• La duplicazione del codice deve essere ridotta al minimo.
• Le dipendenze esterne devono essere ben documentate e il codice facilmente eseguibile anche al di fuori del PC dello sviluppatore. “Nel mio computer funzionava” non è accettabile.
• Il codice deve compilare con una versione di solidity che sia considerata affidabile, se non succede allora va giustificato l’uso di una versione precedente o successiva
• Non devono esserci compiler warnings, oppure vanno giustificati a dovere.

Sembra banale ma possono passare giorni prima di ottenere questi requisiti iniziali soddisfatti. Inoltre superati questi dovrebbero essere rispettati anche i seguenti, con priorità più bassa ma utili comunque:

• file di deploy presenti e documentati
• testcase nella directory /tests
• test coverage documentato e possibilmente pari al 100%
• artifacts e builds non inclusi nel git
• separazione fra i file da auditare e quelli da tralasciare
• documentazione del codice completa e accurata
• specifiche funzionali del progetto
• nessun getter per le variabili pubbliche
• aderenza alle code conventions linee guida di Solidity

Sebbene sia importante che il codice venga presentato in un repository git resta il fatto che l’auditor deve sapere esattamente quale commit del repository è oggetto del review e tale sarà anche riportato nella relazione di audit. Infatti in produzione gli utenti dovrebbero poter verificare che il bytecode in esecuzione in blockchain corrisponda esattamente al codice generato dal sorgente oggetto dell’audit e non ad una versione diversa, anteriore o successiva.

A tale scopo riportiamo un flowchart delle fasi dell’audit che vedono coinvolti l’auditor ed il team di sviluppo.

Cos’è il triage dei difetti

Il triage come suggerisce il nome altro non è che una classificazione dei problemi basata sul classico modello di rischio

R = P * D

Dove R è il rischio, P è la probabilità che il problema si verifichi e D è il danno potenziale che il problema potrebbe causare.

In modo trasversale potremmo qualificare i difetti software secondo altre dimensioni:

• Sicurezza, il difetto va corretto assolutamente perché in genere anche se improbabile potrebbe avere conseguenze disastrose
• Trust, il difetto non è legato all’esecuzione di codice scorretto ma al fatto che introduce degli elementi come backdoor o privilegi che possono minare alla base la trasparenza e autonomia dello smart contract.
• Funzionale, il codice e sicuro e non modificabile, tuttavia presente un disallineamento fra l’implementazione effettiva e i business requirement. Questo tipo di difetto dovrebbe essere comunque considerato molto grave, specialmente se in gioco ci sono anche degli adempimenti contrattuali o legali off chain

Il rapporto di audit

Il rapporto è solitamente un file pdf che racchiude i risultati dell’audit.

Tale rapporto normalmente include anche una descrizione rapida e sintetica dell’intero sistema analizzato.

Normalmente l’auditor prepara una versione iniziale del documento che racchiude le indicazioni principali e le criticità rilevate e suggerisce le azioni da intraprendere per mitigare o eliminare il rischio.

A seguito della trasmissione della versione iniziale al team di sviluppo, questo verifica e decide se intraprendere le azioni suggerite nel rapporto. Se una o più azioni vengono intraprese la palla torna all’auditor che ne verifica l’esecuzione e stila una seconda versione, possibilmente finale, del rapporto di audit.

Conclusioni

L’audit di uno smart contract richiede tempo, attenzione e impegno. E’ necessario mettere l’auditor in condizione di avere tutte le informazioni necessarie e poi eseguire i suoi controlli. Questo in genere richiede diverse interazioni tra auditor e team di sviluppo senza contare che il primo rapporto dell’audit è da considerarsi pre-liminare e contiene una serie di suggerimenti che l’auditor si aspetta di vedere implementati dal team di sviluppo.