Come giudicare se un cosiddetto "HACK" accaduto a un progetto crittografico o blockchain è legittimo o se è solo un meccanismo per nascondere un tappeto?

Ripubblicato da Platone

Seguaci: 0

Ovviamente, dopo quello che è successo con MtGox o QuadrigaCX o casi simili in cui i fondatori hanno affermato di aver perso le chiavi private che detengono la maggior parte delle risorse digitali dei loro scambi scomparendo o ritrovati morti in seguito, le persone nella sfera crittografica sono sempre più sospettose quando sentono parlare di un hack su un progetto, e il primo pensiero che viene in mente è che i fondatori hanno sostanzialmente svuotato il fondo e se ne sono andati via, questo è ciò che comunemente viene chiamato RUG.

Questo è stato probabilmente il caso di molti progetti, ma non necessariamente di tutti, quindi oggi esaminiamo un caso che riteniamo essere un vero e proprio hack a causa della natura della situazione.

Pensiamo che sia un caso interessante da analizzare perché aiuterà a comprendere meglio l'importanza della sicurezza e degli audit nei progetti smart-contract o blockchain in generale.

Analizzeremo obiettivamente il dramma accaduto al progetto RING Financial, un token lanciato sulla BSC (Binance Blockchain).

Prima di arrivare all'hack, riassumeremo prima il progetto e la sua situazione prima di esso:

RING Financial prima dell'attacco

RING financial era un progetto DeFi con l'obiettivo di rendere la DeFi più accessibile alla comunità DeFi e crypto. Un progetto ambizioso che voleva creare un protocollo di rendimento dei nodi che sarebbe stato governato dai titolari dei nodi e allocare la liquidità in più di 300 protocolli contemporaneamente. L'obiettivo era ottenere l'accesso a tutti i protocolli tramite un nodo RING e tramite RING Dapp.

Questi protocolli sono stati verificati dal team e quindi la comunità li avrebbe votati dove assegnarli. Lo stesso concetto di voto che avresti in un DAO che ha reso RING piuttosto attraente.

RING Financial ha anche semplificato parecchio il processo di ricerca e il processo di implementazione per un singolo titolare del nodo. Una Dapp per accedere a tutte le altre Dapp quindi avresti bisogno di una sola interfaccia invece di 300 diverse con i propri accessi e propri nodi.

Infine, l'obiettivo di RING Financial era quello di ridurre le commissioni per l'implementazione su diversi protocolli, con il volume che comporta commissioni di transazione inferiori per i singoli titolari, che era uno dei principali punti di forza del progetto. Un progetto con talento e ambizione per rendere le cose più facili per la comunità e ancora più mainstream per coloro che non conoscono Defi.

Tuttavia, l'estro e l'ambizione non sono sempre sufficienti e sono necessarie esperienza e conoscenza che nei mercati nuovi e immaturi è una scoperta rara ed è per questo che RING Financial non è riuscita a mantenere completamente la sua promessa.

Quindi cosa è successo veramente con RING Financial? E perché è stato violato? Grazie alla blockchain abbiamo tutte le prove forensi necessarie per approfondire e vedere dove erano le vulnerabilità e perché RING Financial non era una truffa.

Il RING Financial HACK si è verificato il 5 dicembre 2021 tra le 2:01 e le 2:06 UTC.

Sì, tutto è successo letteralmente in soli 5 minuti! Grazie al blockchain scanner per questi dettagli, tra l'altro, vi forniamo poco sotto i link delle transazioni relative all'HACK oltre che l'indirizzo del contratto per chi vorrà cercare più nel dettaglio.

Ecco il riepilogo che spiega il difetto che l'attaccante ha sfruttato:

Devi capire che lo smart-contract di RING Financial era composto da più parti, una per il token e tutti i dati ad esso correlati e un'altra per tutto ciò che riguardava la contabilità dei nodi e dei premi. La parte del token aveva una sicurezza in modo che solo l'amministratore del contratto possa modificare i dati importanti di questo, per mostrarti del codice, ecco un'intestazione di una funzione del contratto che è protetta tramite l'attributo "onlyOwner" che prevede che la funzione possa essere eseguita solo dall'amministratore:

Una funzione che non ha un onlyProprietario attribute (o attributo equivalente per proteggere l'accesso alla funzione) può essere eseguito letteralmente da chiunque.

Ora, indovina un po'? Le funzioni nella parte Nodi e Ricompense non avevano questo attributo, come puoi vedere osservando i nomi delle funzioni di seguito (il onlyProprietario manca l'attributo):

E come potete immaginare, un hacker ha sfruttato e truffato questa falla per ottenere un numero esponenziale di premi in RING, per poi scaricarli nel pool di liquidità e svuotarlo quasi violentemente in pochi minuti. Così, ha perpetrato le sue truffe.

Ora probabilmente ti starai ponendo due domande:

Come hanno potuto gli sviluppatori lasciare una simile scappatoia?

Dopo aver parlato con gli sviluppatori di Solidity (linguaggio utilizzato per codificare gli smart-contract su Ethereum), questo è un errore relativo all'ereditarietà del ruolo tra due smart-contract, l'ereditarietà è una nozione del linguaggio di programmazione e per non farti venire il mal di testa, noi rimarrò in parole semplici: Fondamentalmente, è molto probabile che la persona che ha codificato il contratto pensasse che le funzioni della parte Node ereditassero i ruoli di sicurezza delle funzioni della parte Token, ma sfortunatamente non è così in Solidity, e è necessario ridefinire i ruoli di ciascuna funzione di ciascun contratto, qualunque sia il loro collegamento. Quindi la nostra conclusione su questo punto è che lo sviluppatore non era un esperto e che probabilmente ha pubblicato il contratto SENZA prendersi il tempo di rileggerlo, probabilmente di fretta.

Come fai a sapere che non è lo stesso sviluppatore che ha lasciato apposta questo difetto e non è stata una truffa?

Obiezione molto buona ed è facile presumere una truffa quando non sei sicuro di come smart contract funziona ma in realtà è molto facile presumere l'innocenza dello sviluppatore, perché ha pubblicato e verificato pubblicamente l'intero codice dello smart-contract su BSCSCAN.COM (lo scanner più popolare della Blockchain di Binance), il 19 novembre 2021, che vale a dire, più di due settimane prima che si verificasse il RING Financial HACK. E come spiegato prima, il difetto era scritto in NERO SU BIANCO nel contratto, e qualsiasi sviluppatore esperto se ne sarebbe accorto e avrebbe reagito, ma sfortunatamente, il primo a non avere pietà. È quindi ovvio che lo sviluppatore non fosse a conoscenza di questa falla perché non si sarebbe preso il rischio di permettere a nessuno di uccidere il progetto RING Financial in qualsiasi momento.

Per tornare alla continuazione del RING Financial HACK, lo sviluppatore si è reso conto del suo errore e ha semplicemente bloccato il contratto per interrompere qualsiasi distribuzione di premi in modo che l'attaccante non svuoti completamente il pool. Ha quindi ridistribuito un contratto Node, questa volta con l'attributo di sicurezza "onlyOwner". Questo nuovo contratto Node è stato in grado di gestire correttamente la nuova distribuzione della ricompensa, tranne per il fatto che era troppo tardi, perché a seguito dell'HACK si era persa tutta la fiducia nel progetto e nel team, e la pressione di vendita ha ucciso e messo fine al token e il progetto.

Per concludere, abbiamo scelto questa storia perché mostra due cose importanti sui contratti intelligenti e sui progetti crittografici, non codificare mai un contratto in fretta e contattare sempre le società di revisione, perché una volta che si verifica l'hack, è troppo tardi per salvare la barca, e Il progetto RING Financial è un buon esempio, inoltre, secondo la loro comunicazione, hanno contattato le società di revisione per questo secondo contratto Node e non lo hanno pubblicato pubblicamente su BSCSCAN fino a quando non erano certi della sua sicurezza. Ma come detto prima, era troppo tardi per RING Financial e il danno era irreversibile.