Il 2 novembre, Axion Network ha lanciato il suo nuovo token, noto come AXN. Il progetto ha pubblicizzato l’asset come un nuovo veicolo di investimento, sostenendo che sarebbe stata la blockchain più redditizia del suo genere fino ad oggi. Durante l’interim prima dell’airdrop di AXN, cinque squadre separate avrebbero esaminato il codice del token; beniamini del settore come CertiK e Hacken sono stati tra coloro che hanno condotto gli audit.

Tuttavia, poche ore dopo l’evento di rivendicazione gratuita del protocollo, è diventato chiaro che qualcosa era andato storto. Un attore non autorizzato ha coniato inaspettatamente 79 miliardi di AXN e li ha scaricati sul mercato. Il prezzo è crollato di oltre il 99%, regalando agli aggressori un fantastico 1300 ETH, per un valore stimato di $ 500.000 al momento della pubblicazione.

Nelle ore successive, il team dietro il progetto Axion ha incoraggiato i partecipanti a stare lontano dal trading o dall’interazione con l’asset, affermando tramite il canale Telegram ufficiale della piattaforma:

“Non acquistare AXN adesso, non interagire con la dashboard”

L’account Twitter di Axion Network ha continuato a pubblicare aggiornamenti, tra cui:

Nonostante queste rassicurazioni, CertiK si sta facendo avanti per offrire alla comunità una spiegazione più chiara di ciò che percepiscono essere andato storto e approfondimenti su come simili attacchi potrebbero essere prevenuti in futuro. Cointelegraph ha contattato via e-mail “Jack Durden” che ci è stato descritto come il CEO di Axion Network, ma non ha ricevuto risposta immediata. Nessun membro del team è elencato nel white paper del progetto o sul sito web e il nome “Jack Durden” è condiviso con il narratore invisibile del film Fight Club.

Si noti che il resto di questo articolo è riprodotto parola per parola, per gentile concessione di CertiK, come servizio pubblico per istruire i lettori sulla comprensione di ciò che è accaduto da parte del team di audit. Cointelegraph non ha verificato il codice e le opinioni riportate di seguito sono quindi esclusivamente quelle di CertiK.

Rapporto dello staff di CertiK sul crollo dei prezzi di Axion

Il 2 novembre 2020 alle circa 11:00 AM + UTC un hacker è riuscito a coniare circa 80 miliardi di token AXN utilizzando la funzione di annullamento dell’assunzione del contratto Axion Staking.

L’hacker ha quindi proceduto a scaricare i token sull’exchange AXN Uniswap per Ether, ripetendo questo processo finché l’exchange Uniswap non è stato svuotato e il prezzo del token è stato portato a 0.

Siamo stati informati dell’incidente entro pochi minuti dall’attacco e i nostri analisti della sicurezza hanno iniziato a valutare immediatamente la situazione.

Abbiamo concluso che l’attacco è stato probabilmente pianificato dall’interno, comportando un’iniezione di codice dannoso nel momento in cui il codice è stato distribuito alterando il codice dalle dipendenze di OpenZeppelin.

La funzione sfruttata non faceva parte dell’audit che abbiamo condotto poiché è stata aggiunta dopo aver unito il codice di Axion con il codice di OpenZeppelin tramite “appiattimento” e averlo inserito nel codice di OpenZeppelin prima della distribuzione.

Pianificazione

L’hacker ha utilizzato fondi anonimi procurati da tornado.cash il giorno prima che si verificasse l’hack, alludendo a un attacco pre-meditato. Presumibilmente per risparmiare alcuni fondi nel caso in cui l’attacco fallisse, 2.1 Ether sono stati ricircolati in tornado.cash subito dopo che l’account ha ricevuto i fondi.

Per finalizzare la configurazione dell’attacco, l’hacker ha acquistato in giro ~ 700.000 token HEX2T dallo scambio Uniswap. Tuttavia, questi fondi alla fine non facevano parte dell’attacco e sono serviti da cortina fumogena per quanto riguarda lo svolgimento dell’attacco.

Impostare

L’hacker ha iniziato la sua strada verso l’attivazione del proprio attacco creando una puntata “vuota” sul contratto di Staking della rete Axion invocando la funzione di stake con un importo 0 e una durata della puntata di 1 giorno su circa 09:00 AM + UTC. Questo ha creato una voce di sessione per l’attaccante con un importo 0 e un valore di condivisioni 0 all’ID sessione 6.

Successivamente, l’attaccante ha pre-approvato una quantità illimitata di AXN allo scambio Uniswap in previsione del successo del loro attacco. Di conseguenza, hanno approvato il contratto NativeSwap di Axion per l’importo di fondi che intendevano convertire in token AXN.

Hanno invocato la funzione di deposito del contratto NativeSwap in circa 10:00 AM + UTC, tuttavia, l’hacker non ha mai chiamato la funzione di ritiro del contratto per rivendicare il suo AXN scambiato come evidente sulla funzione swapTokenBalanceOf del contratto NativeSwap. Successivamente, hanno effettuato un’altra chiamata alla funzione di deposito non riuscito prima di eseguire l’attacco.

Esecuzione

Queste transazioni erano solo cortine fumogene per il modo in cui l’attacco era stato effettivamente eseguito. Poiché le transazioni condotte dall’autore dell’attacco non hanno comportato modifiche alla mappatura sessionDataOf, abbiamo concluso che si trattava di un attacco a più indirizzi.

Abbiamo esaminato il codice sorgente del contratto nel repository GitHub che era stato condiviso con noi per identificare un difetto che avrebbe influenzato la mappatura sessionDataOf.

Non siamo stati in grado di rilevare eventuali incarichi ad essa o ai suoi membri al di fuori delle funzioni di palo che ci hanno spinto a chiederci se lo spiegamento dei contratti fosse stato condotto correttamente.

Vettore di attacco

Dopo aver analizzato il codice sorgente del contratto di Staking distribuito, abbiamo individuato un’iniezione di codice nella libreria AccessControl OpenZeppelin tra L665-L671 del codice sorgente distribuito del contratto di Staking. La funzione checkRole collegata non fa parte di l’implementazione di OpenZeppelin v3.0.1, che era elencato come dipendenza nel repository GitHub del progetto.

All’interno della funzione checkRole, esiste il seguente blocco di assembly:

Questa particolare funzione consente a un indirizzo specifico di eseguire una scrittura arbitraria del contratto in base alle variabili di input che integra tramite chiamate di basso livello. Annotato, il blocco di assemblaggio sarebbe simile a questo:

Questa funzione è stato iniettato durante la distribuzione poiché non esiste nell’implementazione di OpenZeppelin AccessControl, il che significa che i membri della rete Axion coinvolti nell’implementazione del token hanno agito in modo dannoso.

Conclusione

L’attacco ha utilizzato codice che è stato deliberatamente iniettato prima della distribuzione del protocollo. Questo incidente non ha alcuna relazione con gli audit condotti da CertiK e la parte responsabile dell’attacco era una persona che sembrava essere coinvolta nello spiegamento dei contratti della rete Axion.

Come ulteriore grado di sicurezza, i report di audit dovrebbero essere standardizzati per includere indirizzi di smart contract distribuiti il ​​cui codice sorgente è stato verificato per essere lo stesso di quello che è stato controllato.

Il Oracle di sicurezza funge da relayer su catena di intelligence sulla sicurezza, conducendo controlli di sicurezza che includono la verifica degli smart contract implementati per abbinare le versioni controllate.





Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here