Vulnerabilità di Exchange decentralizzate

Nell'ultimo mese, le perdite dovute agli attacchi degli hacker alla comunità crittografica sono salite a $ 1.019 miliardi (24.10), superando gli ultimi mesi (omettendo l'incidente di Terra Luna)

Dando un'occhiata più da vicino, possiamo vedere che i maggiori exploit sono stati condotti su piattaforme DEX (Decentralized Exchange), sommando quasi il 15% delle perdite totali solo nel mese di ottobre.

Con questo in mente, approfondiamo tre casi nel mondo dello sfruttamento di DEX e proviamo a rispondere a queste domande:

• Quali sono le principali cause delle vulnerabilità DEX?
• Come possiamo evitarli in futuro?

Scambio di banane

Il 28 agosto lo scambio di token $DDC, Scambio di banane, é stato attaccato. L'aggressore ha manipolato con successo il prezzo della moneta, rompendo la logica interna del calcolo del prezzo, e di conseguenza ha scambiato 23 $DDC con 110,105 $BUSD.

La vulnerabilità era abbastanza semplice, ma l'impatto aveva un enorme potenziale di profitto:

1. L'attacco è iniziato con una transazione di 26 $DDC sul conto dell'attaccante
2. Quindi è stata avviata una ricerca del portafoglio di una vittima per trovare un portafoglio che contenga una grande quantità di token
3. [Sfruttamento] Quando è stato trovato un account adatto, l'attaccante ha chiamato handleDeductFee che ha eseguito un detrazione di quasi tutti i gettoni dal saldo della vittima
4. Al fine di finalizzare la manipolazione dei prezzi, la funzione sync è stato chiamato per aggiornare il valore/prezzo di $DDC

Di conseguenza, il saldo di $DDC nel pool è stato ridotto a 0.0003 $DDC, dopo che il valore/prezzo è stato aggiornato, il prezzo di $USD corrispondente a $DDC è aumentato in modo significativo e una grande quantità di $USD può essere scambiata tramite una piccola quantità di $DDC. L'hacker ha utilizzato 23 $ DDC per scambiare con 104,600 USD.

Quindi come è stato possibile per un aggressore manipolare il saldo del conto della vittima? Che cos 'era il handleDeductFee funzione in esecuzione?

Diamo un'occhiata al codice:

function handleDeductFee (ActionType actionType, uint256 feeAmount, address from, address user) external override {
	distributeFee(actionType, feeAmount, from, user);
}

// deduct the config fee and transfer to handle fee address which config.
// parameter from
function distributeFee (ActionType actionType, uint feeAmount, address from, address user) internal { 
	_balances [from] = _balances[from].sub(feeAmount);
	...
}

Qui abbiamo una funzione esterna con argomenti controllabili che chiama una funzione interna passando gli stessi argomenti come parametri che esegue subito una deduzione usando questi argomenti.

L'aggressore ha trasmesso l'indirizzo della vittima come il from parametro e il feeAmount era leggermente inferiore al risultato di balanceOf di questo indirizzo.

Questo è tutto! Non una singola convalida sui dati in arrivo. Nessuna teoria complessa dietro a tutto questo.

Cyberspazio Sicurezza 101: non fidarti mai dei dati controllati dall'utente.

Ulteriori informazioni sono disponibili nel post su Twitter di Beosin Alert qui.

Successivamente, esamineremo un protocollo più complesso. Ma come abbiamo già visto, mancare una riga di codice può danneggiare l'intero sistema.

Scambio di transito

Scambio di transito è una piattaforma di aggregazione DEX multi-catena in esecuzione su catene Ethereum e Binance. Il 1° ottobre, la piattaforma è stata vittima di un attacco che ha prosciugato risorse per un valore di quasi 29 milioni di dollari dai portafogli degli utenti del protocollo.

Lo scambio con Transit Swap comporta il passaggio attraverso un paio di contratti che instradano e collegano diversi swapper e impongono la gestione delle autorizzazioni. Ciascuno dei contratti chiama l'altro passando i suoi parametri come argomenti al successivo, ognuno di essi utilizza i parametri per elaborare alcune logiche ed eseguire azioni.

Una versione semplificata del flusso di dati è simile a questa:

Come accennato in precedenza, ciascuno dei contratti chiama il successivo passando gli argomenti come parametri, quindi perché è così importante?

"Il motivo principale di questo attacco è che il protocollo Transit Swap non convalida rigorosamente i dati trasmessi dall'utente durante lo scambio di token, il che si traduce in una chiamata esterna arbitraria". – L'analisi di SlowMist

Nessuno dei contratti ha convalidato correttamente i dati utilizzati per effettuare la transazione. Di conseguenza, l'attaccante ha manipolato con successo l'intera catena passando dati appositamente predisposti per ogni fase della transazione.

Questo è un altro caso di convalida dei dati con una vulnerabilità su larga scala. Passiamo a una delle maggiori perdite di quest'anno:

Scambio Maiar - Rete Elrond

Il terzo attacco DEX più redditizio di tutti i tempi è stato condotto su Maiar DEX. Gli hacker hanno sfruttato una funzione vulnerabile appena implementata sulla rete principale. Hanno svuotato con successo le riserve del protocollo, rubando 113 milioni di dollari di asset.

L'exploit è iniziato con una funzione executeOnDestByCaller che ha consentito al contratto A di eseguire azioni sul contratto C tramite delega B. Il contratto A chiamerà una funzione all'interno di B che consente a B di eseguire azioni su C per conto del contratto A.

Per illustrare ciò, illustreremo i contratti A, B e C. Il contratto A chiama foo che è dentro B. foo chiamate executeOnDestByCaller che consente a B di eseguire la funzione bar del contratto C come impostore di A.

In pratica, il contratto B può eseguire ogni funzione per conto di A se A ha effettuato la prima chiamata a B. Questa idea suona già un po' sospetta.

Per creare un exploit usando questa funzione bisogna capire come fare in modo che la vittima chiami il contratto e poi si può fare quello che vogliono con quel contratto usando le funzioni esterne che fornisce come transferFrom.

Fortunatamente per gli hacker, Elrond ha un concetto chiamato callback. Utilizzando questi callback si può passare una funzione dannosa come callback alla vittima, che non avrà altra scelta che eseguire il callback e il resto è storia.

Se desideri approfondire, fai riferimento a Il rapporto ufficiale di Elrond ed La rottura dell'attacco di Arda.

Quindi non c'era alcuna vulnerabilità nel codice, ma piuttosto un difetto logico. Il pubblico ha riscontrato diversi problemi di sicurezza con questa funzionalità dopo l'implementazione, ma la patch e la correzione potrebbero essere consegnate solo una settimana dopo, esponendo così tutti i contratti a potenziali vulnerabilità per un'intera settimana intera.

Rispondere alle domande

Sapendo ciò che sappiamo ora, possiamo rispondere a queste domande.

Gli incidenti discussi condividono una causa comune: la vulnerabilità degli smart contract. Conosciamo tutti i termini vulnerabilità ed exploit in altri scenari, quindi cosa lo rende diverso nello scenario del contratto intelligente?

1. Open-source - Come tutti sappiamo, la "D" in DEX sta per Decentralized, il che significa che il prodotto è guidato dagli utenti e che rende il codice accessibile al mondo. Questo rende le vulnerabilità più facili da trovare.
2. Difficile da aggiornare: il costo per trovare e aggiornare una vulnerabilità è molto più elevato rispetto a un'applicazione off-chain. Poiché i contratti vengono caricati sulla catena, correggere una vulnerabilità significa caricare una nuova copia del contratto e reindirizzare tutti gli indirizzi da quello vecchio a quello nuovo se non è in uso alcun contratto proxy.

Quindi non abbiamo una seconda possibilità. Dobbiamo assicurarci che il contratto sia privo di bug e sicuro prima di caricarlo nella catena.

I controlli di sicurezza prima del caricamento e il monitoraggio costante delle minacce alla sicurezza sono misure cruciali nel mondo delle app decentralizzate.

Conclusione

Questi esempi coprono solo una parte delle vulnerabilità e dei problemi riscontrati negli smart contract. Con l'avanzare dello sviluppo del Web 3, verranno introdotti nel mondo algoritmi più complessi, algoritmi che potrebbero svolgere un ruolo importante nel prossimo exploit e causare perdite di fondi.

L'analisi degli exploit passati e la mitigazione, l'auditing e il controllo del codice possono prevenire perdite nei fondi e fare un'enorme differenza per il futuro delle applicazioni decentralizzate.