CertiK analizza l’incidente della rete Axion e il conseguente crollo dei prezzi

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 il periodo intermedio che conduce all’airdrop di AXN, cinque team separati presumibilmente hanno esaminato il codice del token; beniamini del settore come CertiK e Hacken erano tra coloro che hanno condotto gli audit. 

Poche ore dopo l’evento di rivendicazione gratuita del protocollo, tuttavia, è 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, del 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:

Siamo ancora qui.

Verranno accreditate tutte le persone AXN / HEX2T detenute al momento dell’exploit.

Lanceremo un portale di ricompensa della liquidità per aumentare anche la liquidità.

Stiamo lavorando duramente per rilanciare AXN il prima possibile.

– Axion (@axion_network) 2 novembre 2023

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 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 2023 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 proceduto a scaricare i token sull’exchange AXN Uniswap per Ether, ripetendo questo processo fino a quando 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 in quanto è stata aggiunta dopo aver unito il codice di Axion con il codice di OpenZeppelin tramite “appiattimento” e iniettato 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, accennando a un attacco premeditato. 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 ~ 700k 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 suo attacco creando una puntata “vuota” sul contratto di Staking della rete Axion invocando la funzione di puntata con un importo 0 e una durata della puntata di 1 giorno circa 09:00 AM + UTC. Ciò ha creato una voce di sessione per l’attaccante con un importo 0 e un valore di condivisioni 0 all’ID di 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’aggressore non hanno comportato modifiche alla mappatura sessionDataOf, abbiamo concluso che si trattava di un attacco multi-indirizzo.

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

Non siamo stati in grado di rilevare eventuali incarichi ad esso o membri di esso al di fuori delle funzioni di palo che ci hanno spinto a chiederci se lo spiegamento dei contratti sia 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 in quanto non esiste nell’implementazione di OpenZeppelin AccessControl, il che significa che i membri della rete Axion coinvolti nella distribuzione 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 rapporti di audit dovrebbero standardizzarsi per includere indirizzi di contratti intelligenti 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 distribuiti per abbinare le versioni controllate.