Questo articolo è stato inviato dalla community. L'autore è Minzhi He, si occupa di audit per CertiK.
Le idee di questo articolo sono del collaboratore/autore e non riflettono necessariamente quelle di Binance Academy.
TL;DR
I bridge blockchain sono fondamentali per raggiungere l'interoperabilità nell'ecosistema blockchain. Di conseguenza, la sicurezza dei bridge è di fondamentale importanza. Alcune vulnerabilità comuni relative alla sicurezza di un bridge includono una debole convalida on-chain e off-chain, una gestione impropria dei token nativi e configurazioni errate. È raccomandato testare il bridge contro tutti i possibili vettori di attacco per garantire una solida logica di verifica.
Introduzione
Un bridge blockchain è un protocollo che collega due blockchain per consentire le interazioni tra loro. Se possiedi bitcoin ma vuoi partecipare a delle attività DeFi sulla rete Ethereum, un bridge blockchain ti permette di farlo senza vendere i tuoi bitcoin.
I bridge blockchain sono fondamentali per raggiungere l'interoperabilità nell'ecosistema blockchain. Funzionano utilizzando diverse convalide on-chain e off-chain e presentano quindi diverse vulnerabilità relative alla loro sicurezza.
Perché la sicurezza dei bridge è fondamentale?
Un bridge solitamente detiene il token che un utente vuole trasferire da una catena all'altra. Spesso sono distribuiti come smart contract, i bridge detengono una quantità significativa di token man mano che si accumulano i trasferimenti tra le catene, rendendoli degli obiettivi molto succosi per gli hacker.
Inoltre, i bridge blockchain possono essere colpiti in vari modi poiché sono costituiti da molti componenti. In quest'ottica, i malintenzionati sono molto motivati a prendere di mira le applicazioni cross-chain per rubare grandi somme di denaro.
Secondo le stime di CertiK, gli attacchi ai bridge hanno causato perdite per oltre 1,3 miliardi di dollari nel 2022, pari al 36% delle perdite totali dell'anno.
Vulnerabilità di sicurezza comuni dei bridge
Per migliorare la sicurezza dei bridge, è importante comprendere le vulnerabilità comuni relative alla loro sicurezza e testarle prima del lancio. Queste vulnerabilità possono essere classificate nelle seguenti quattro aree.
Convalida on-chain debole
Nei bridge più semplici, in particolare quelli progettati per specifiche DApp, la convalida on-chain è ridotta al minimo. Questi bridge si affidano a un backend centralizzato per eseguire le operazioni di base come il minting, il burning e il trasferimento dei token, mentre tutte le verifiche vengono eseguite off-chain.
Al contrario, altri tipi di bridge utilizzano gli smart contract per convalidare i messaggi ed eseguire le verifiche on-chain. In questo scenario, quando un utente deposita i fondi su una catena, lo smart contract genera un messaggio firmato e restituisce la firma nella transazione. Questa firma serve come prova del deposito e viene utilizzata per verificare la richiesta di prelievo dell'utente sull'altra catena. Questo processo dovrebbe essere in grado di prevenire vari attacchi, tra cui gli attacchi replay e la falsificazione dei record di deposito.
Tuttavia, se c'è una vulnerabilità nel processo di validazione on-chain, l'hacker può causare gravi danni. Ad esempio, se un bridge utilizza un Merkle tree per convalidare il record della transazione, un hacker può generare dei record falsificati. Ciò significa che possono aggirare la convalida della prova e coniare nuovi token sul proprio account se il processo di convalida è vulnerabile.
Alcuni bridge implementano il concetto di "wrapped token" (token wrappati). Ad esempio, quando un utente trasferisce DAI dalla rete Ethereum a BNB Chain, i suoi DAI vengono prelevati dal contratto Ethereum e una quantità equivalente di DAI wrappati viene emessa su BNB Chain.
Tuttavia, se questa transazione non viene convalidata correttamente, un utente malintenzionato potrebbe distribuire un contratto dannoso per indirizzare i token wrappati dal bridge a un indirizzo errato manipolando la funzione.
Gli aggressori hanno anche bisogno che le vittime approvino il contratto del bridge per trasferire i token utilizzando la funzione "transferFrom" per spostare gli asset dal contratto del bridge.
Purtroppo, la situazione è peggiorata dal fatto che molti bridge richiedono agli utenti delle DApp un'approvazione infinita dei token. Si tratta di una pratica comune che abbassa le commissioni del gas, ma crea ulteriori rischi consentendo a uno smart contract di accedere a un numero illimitato di token del wallet dell'utente. Gli aggressori sono in grado di sfruttare la mancanza di convalide e l'eccessiva approvazione per trasferire i token dai wallet degli utenti a se stessi.
Convalida off-chain debole
In alcuni sistemi di bridge, il server backend off-chain svolge un ruolo fondamentale nella verifica della legittimità dei messaggi inviati dalla blockchain. In questo caso, ci concentriamo sulla verifica delle transazioni di deposito.
Un bridge blockchain con convalida off-chain funziona come segue:
Gli utenti interagiscono con la DApp per depositare i token nello smart contract sulla catena di origine.
La DApp invia quindi l'hash della transazione di deposito al server backend tramite un'API.
L'hash della transazione è soggetto a diverse convalide da parte del server. Se ritenuto legittimo, il firmatario firma un messaggio e invia la firma all'interfaccia utente tramite l'API.
Una volta ricevuta la firma, la DApp la verifica e consente all'utente di prelevare i propri token dalla chain di origine.
Il server backend deve assicurarsi che la transazione di deposito che elabora sia effettivamente avvenuta e non sia stata falsificata. Questo server backend determina se un utente può ritirare i token sulla catena di destinazione ed è quindi un obiettivo di alto valore per gli aggressori.
Il server di backend deve convalidare la struttura dell'evento emesso dalla transazione e l'indirizzo del contratto che ha emesso l'evento. Se quest'ultimo viene trascurato, un aggressore potrebbe utilizzare un contratto dannoso per falsificare un evento di deposito con la stessa struttura di un evento di deposito legittimo.
Se il server di backend non verifica quale indirizzo ha emesso l'evento, lo considera una transazione valida e firma il messaggio. L'attaccante potrebbe quindi inviare l'hash della transazione al backend, aggirando la verifica e consentendo di ritirare i token dalla catena di destinazione.
Gestione impropria dei token nativi
I bridge adottano approcci diversi per la gestione dei token nativi e degli utility token. Ad esempio, sulla rete Ethereum, il token nativo è ETH e la maggior parte degli utility token aderiscono allo standard ERC-20.
Quando un utente intende trasferire i propri ETH su un'altra catena, deve prima depositarli nel contratto bridge. A tale scopo, l'utente deve semplicemente allegare ETH alla transazione e l'importo di ETH può essere recuperato leggendo il "msg.value" della transazione.
Il deposito di token ERC-20 differisce in modo significativo dal deposito di ETH. Per depositare un token ERC-20, l'utente deve prima consentire al contratto bridge di spendere i propri token. Dopo l'approvazione e il deposito dei token nel contratto bridge, il contratto brucerà i token dell'utente usando la funzione "burnFrom()" oppure trasferirà i token dell'utente al contratto usando la funzione "transferFrom()".
Un approccio per differenziare questo aspetto è quello di utilizzare un'istruzione if-else all'interno della stessa funzione. Un altro approccio consiste nel creare due funzioni separate per gestire ogni scenario. Il tentativo di depositare ETH utilizzando la funzione di deposito ERC-20 può comportare la perdita di questi fondi.
Quando si gestiscono le richieste di deposito ERC-20, gli utenti di solito forniscono l'indirizzo del token come input alla funzione di deposito. Ciò comporta un rischio significativo, poiché durante la transazione possono verificarsi chiamate esterne non attendibili. L'implementazione di una whitelist che includa solo i token supportati dal bridge è una pratica comune per ridurre al minimo i rischi. È possibile passare come argomenti solo gli indirizzi inseriti nella whitelist. In questo modo si evitano le chiamate esterne, poiché il team di progetto ha già filtrato l'indirizzo del token.
Tuttavia, possono sorgere problemi anche quando i bridge gestiscono il trasferimento di token nativi tra le catene, poiché il token nativo non ha un indirizzo. Un indirizzo zero (0x000...0) rappresenta il token nativo. Questo può essere problematico, poiché il passaggio dell'indirizzo zero alla funzione può aggirare la verifica della whitelist anche se viene implementato in modo non corretto.
Quando il contratto bridge chiama "transferFrom" per trasferire gli asset dell'utente al contratto, la chiamata esterna all'indirizzo zero restituisce false, poiché non esiste una funzione "transferFrom" implementata nell'indirizzo zero. Tuttavia, la transazione può comunque avvenire se il contratto non gestisce in modo appropriato il valore di ritorno. Questo crea un'opportunità per gli aggressori, che possono eseguire la transazione senza trasferire alcun token al contratto.
Configurazione errata
Nella maggior parte dei bridge blockchain, un ruolo privilegiato è responsabile della whitelist o della blacklist di token e indirizzi, dell'assegnazione o della modifica dei firmatari e di altre configurazioni critiche. Assicurarsi che tutte le configurazioni siano accurate è fondamentale, poiché anche sviste apparentemente banali possono portare a perdite significative.
In effetti, si è verificato un caso in cui l'aggressore è riuscito a bypassare la verifica del record di trasferimento a causa di una configurazione errata. Il team del progetto ha implementato un aggiornamento del protocollo pochi giorni prima dell'hacking, che prevedeva la modifica di una variabile. La variabile era utilizzata per rappresentare il valore predefinito del messaggio di fiducia (trusted message). Questa modifica ha fatto sì che tutti i messaggi venissero automaticamente considerati come verificati, consentendo così a un utente malintenzionato di inviare un messaggio arbitrario e superare il processo di verifica.
Come migliorare la sicurezza dei bridge
Le quattro vulnerabilità comuni relative ai Bridge, che sono appena state spiegate, dimostrano quanto sia sfidante garantire la sicurezza in un ecosistema blockchain interconnesso. Esistono riflessioni significative per la gestione di ciascuna di queste vulnerabilità e non esiste una guida applicabile a tutte.
Ad esempio, fornire linee guida generali per garantire un processo di verifica privo di errori è difficile, poiché ogni bridge ha requisiti di verifica unici. L'approccio più efficace per prevenire i bypass di verifica consiste nel testare a fondo il bridge contro tutti i possibili vettori di attacco e garantire che la logica di verifica sia solida.
In sintesi, è essenziale eseguire test rigorosi contro i potenziali attacchi e prestare particolare attenzione alle vulnerabilità di sicurezza più comuni relative ai bridge.
In chiusura
Visto il loro valore elevato, i bridge cross-chain sono da tempo un obiettivo per gli aggressori. Gli sviluppatori possono rafforzare la sicurezza dei loro bridge conducendo test approfonditi prima dell'implementazione e impegnandosi in audit di terze parti, riducendo così il rischio di hack devastanti come quelli che hanno colpito i bridge negli ultimi anni. I bridge sono fondamentali in un mondo multi-chain, ma la sicurezza deve essere una preoccupazione primaria quando si progetta e si costruisce un'infrastruttura Web3 efficace.
Letture consigliate
Cos'è l'interoperabilità cross-chain?
Tre crypto bridge popolari e come funzionano
Disclaimer e Avvertenza sui rischi: questo contenuto viene presentato all'utente «così com'è» solo a scopo informativo e didattico, senza rappresentazioni o garanzie di alcun tipo. Non deve essere interpretato come una consulenza finanziaria, legale o di altro tipo professionale, né intende raccomandare l'acquisto di prodotti o servizi specifici. Dovresti chiedere una consulenza a consulenti professionali appropriati. Laddove l'articolo sia fornito da un collaboratore terzo, tieni presente che le opinioni espresse appartengono al collaboratore terzo e non riflettono necessariamente quelle di Binance Academy. Leggi il nostro disclaimer completo qui per ulteriori dettagli. I prezzi degli asset digitali possono essere volatili. Il valore del tuo investimento potrebbe aumentare o diminuire e potresti non recuperare l'importo investito. Sei l'unico responsabile delle tue decisioni di investimento e Binance Academy non è responsabile per eventuali perdite che potresti subire. Questo materiale non deve essere interpretato come consulenza finanziaria, legale o di altro tipo professionale. Per ulteriori informazioni, consulta i nostri Termini di utilizzo e l'Avvertenza sui rischi.