Questo articolo è un contributo della community. L'autore è Minzhi He, un revisore dei conti presso CertiK.

Le opinioni in questo articolo appartengono al contributore/autore e non riflettono necessariamente quelle di Binance Academy.

TL;DR

I bridge blockchain sono fondamentali per raggiungere l’interoperabilità nello spazio blockchain. Pertanto, la sicurezza del ponte è di fondamentale importanza. Alcune vulnerabilità comuni della sicurezza del bridge includono una debole convalida on-chain e off-chain, una gestione impropria dei token nativi e configurazioni errate. Si consiglia di testare il bridge contro tutti i possibili vettori di attacco per garantire una valida logica di verifica.

introduzione 

Un bridge blockchain è un protocollo che collega due blockchain per consentire interazioni tra di loro. Se possiedi bitcoin ma desideri partecipare all'attività DeFi sulla rete Ethereum, un ponte blockchain ti consente di farlo senza vendere i tuoi bitcoin. 

I bridge blockchain sono fondamentali per raggiungere l’interoperabilità all’interno dello spazio blockchain. Funzionano utilizzando varie convalide on-chain e off-chain e pertanto presentano diverse vulnerabilità di sicurezza.

Perché la sicurezza del ponte è fondamentale? 

Un bridge solitamente contiene il token che un utente desidera trasferire da una catena all'altra. Spesso utilizzati come contratti intelligenti, i bridge contengono una quantità significativa di token man mano che i trasferimenti cross-chain si accumulano, rendendoli obiettivi redditizi per gli hacker. 

Inoltre, i bridge blockchain hanno un’ampia superficie di attacco poiché coinvolgono molti componenti. Tenendo questo a mente, gli autori malintenzionati sono fortemente motivati ​​a prendere di mira le applicazioni cross-chain per drenare ingenti somme di fondi. 

Secondo le stime di CertiK, gli attacchi ai ponti hanno causato perdite per oltre 1,3 miliardi di dollari nel 2022, pari al 36% delle perdite totali dell’anno. 

Vulnerabilità comuni della sicurezza del bridge

Per migliorare la sicurezza dei bridge, è utile comprendere le vulnerabilità comuni della sicurezza dei bridge e testarli prima del lancio. Queste vulnerabilità possono essere classificate nelle quattro aree seguenti. 

Convalida on-chain debole

Per i bridge semplici, in particolare quelli progettati per DApp specifiche, la convalida on-chain è ridotta al minimo. Questi bridge si basano su un backend centralizzato per eseguire operazioni di base come conio, masterizzazione e trasferimenti di token mentre tutte le verifiche vengono eseguite off-chain.

Al contrario, altri tipi di bridge utilizzano contratti intelligenti per convalidare i messaggi ed eseguire verifiche sulla catena. In questo scenario, quando un utente deposita fondi in una catena, il contratto intelligente 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 alla sicurezza, inclusi attacchi di riproduzione e registrazioni di depositi falsificati. 

Tuttavia, se si verifica una vulnerabilità durante il processo di convalida on-chain, l’aggressore può causare gravi danni. Ad esempio, se un bridge utilizza l'albero Merkle per convalidare il record della transazione, un utente malintenzionato può generare prove contraffatte. Ciò significa che possono ignorare la convalida della prova e coniare nuovi token sul proprio account se il processo di convalida è vulnerabile.

Alcuni bridge implementano il concetto di “gettoni wrappati”. Ad esempio, quando un utente trasferisce DAI da Ethereum alla catena BNB, il suo DAI viene prelevato dal contratto Ethereum e un importo equivalente di DAI incapsulati viene emesso sulla catena BNB. 

Tuttavia, se questa transazione non viene convalidata correttamente, un utente malintenzionato potrebbe implementare un contratto dannoso per instradare i token incapsulati dal bridge a un indirizzo errato manipolando la funzione. 

Gli aggressori hanno inoltre bisogno che le vittime approvino il contratto del bridge per trasferire i token utilizzando la funzione “transferFrom” per drenare risorse dal contratto del bridge. 

Sfortunatamente, la situazione è aggravata dal fatto che molti bridge richiedono l’approvazione infinita dei token da parte degli utenti DApp. Questa è una pratica comune che riduce le tariffe del gas ma crea ulteriori rischi consentendo a un contratto intelligente di accedere a un numero illimitato di token dal portafoglio dell’utente. Gli aggressori sono in grado di sfruttare la mancanza di convalida e l’eccessiva approvazione per trasferire token da altri utenti a se stessi.

Convalida off-chain debole

In alcuni sistemi bridge, il server backend off-chain svolge un ruolo fondamentale nel verificare la legittimità dei messaggi inviati dalla blockchain. In questo caso, ci stiamo concentrando sulla verifica delle transazioni di deposito. 

Un bridge blockchain con convalida off-chain funziona come segue: 

1. Gli utenti interagiscono con la DApp per depositare token nel contratto intelligente sulla catena di origine.

2. La DApp invia quindi l'hash della transazione di deposito al server backend tramite un'API.

3. L'hash della transazione è soggetto a diverse convalide da parte del server. Se ritenuto legittimo, un firmatario firma un messaggio e invia la firma all'interfaccia utente tramite l'API.

4. Dopo aver ricevuto la firma, la DApp la verifica e consente all'utente di ritirare i propri token dalla catena di origine.

Il server backend deve garantire che la transazione di deposito elaborata 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 backend deve convalidare la struttura dell'evento emesso dalla transazione, nonché l'indirizzo del contratto che ha emesso l'evento. Se quest’ultimo viene trascurato, un utente malintenzionato potrebbe implementare un contratto dannoso per falsificare un evento di deposito con la stessa struttura di un evento di deposito legittimo. 

Se il server backend non verifica quale indirizzo ha emesso l'evento, considererà la transazione valida e firmerà il messaggio. L’aggressore potrebbe quindi inviare l’hash della transazione al backend, aggirando la verifica e consentendogli di ritirare i token dalla catena di destinazione.

Gestione impropria dei token nativi

I bridge adottano approcci diversi verso la gestione dei token nativi e dei token di utilità. Ad esempio, sulla rete Ethereum, il token nativo è ETH e la maggior parte dei token di utilità aderisce allo standard ERC-20. 

Quando un utente intende trasferire i propri ETH a un'altra catena, deve prima depositarli nel contratto bridge. Per raggiungere questo obiettivo, l’utente allega semplicemente l’ETH alla transazione e l’importo di ETH può essere recuperato leggendo il campo “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 averlo approvato e depositato i token nel contratto bridge, il contratto brucerà i token dell'utente utilizzando la funzione "burnFrom()" o trasferirà il token dell'utente al contratto utilizzando la funzione "transferFrom()". 

Un approccio per differenziarlo consiste nell'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 gestiscono le richieste di deposito ERC-20, gli utenti solitamente forniscono l'indirizzo del token come input per la funzione di deposito. Ciò rappresenta 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. È consentito passare come argomenti solo gli indirizzi inseriti nella whitelist. Ciò impedisce chiamate esterne poiché il team di progetto ha già filtrato l'indirizzo del token.

Tuttavia, potrebbero sorgere problemi anche quando i bridge gestiscono il trasferimento cross-chain di token nativi, poiché il token nativo non ha un indirizzo. Un indirizzo zero (0x000...0) è rappresentativo del token nativo. Ciò può essere problematico poiché il passaggio dell'indirizzo zero alla funzione può ignorare la verifica della whitelist anche se implementato in modo errato. 

Quando il contratto bridge chiama "transferFrom" per trasferire le risorse dell'utente al contratto, la chiamata esterna all'indirizzo zero restituisce false poiché non è implementata alcuna funzione "transferFrom" nell'indirizzo zero. Tuttavia, la transazione potrebbe comunque verificarsi se il contratto non gestisce il valore restituito in modo appropriato. Ciò crea un'opportunità per gli aggressori di eseguire la transazione senza trasferire alcun token al contratto.

Errata configurazione

Nella maggior parte dei bridge blockchain, un ruolo privilegiato è responsabile dell'inserimento nella whitelist o nella blacklist di token e indirizzi, dell'assegnazione o della modifica dei firmatari e di altre configurazioni critiche. Garantire che tutte le configurazioni siano accurate è fondamentale, poiché anche sviste apparentemente banali possono portare a perdite significative.

In effetti, si è verificato un incidente in cui l'aggressore ha aggirato con successo la verifica del record di trasferimento a causa di un'errata configurazione. Il team del progetto ha implementato un aggiornamento del protocollo pochi giorni prima dell’hacking, che prevedeva la modifica di una variabile. La variabile è stata utilizzata per rappresentare il valore predefinito del messaggio attendibile. Questa modifica ha comportato che tutti i messaggi venissero automaticamente considerati provati, consentendo così a un utente malintenzionato di inviare un messaggio arbitrario e superare il processo di verifica.

Come migliorare la sicurezza del ponte

Le quattro vulnerabilità comuni del bridge spiegate sopra dimostrano le sfide per garantire la sicurezza in un ecosistema blockchain interconnesso. Esistono considerazioni significative per la gestione di ciascuna di queste vulnerabilità e non esiste un unico manuale applicabile a tutte. 

Ad esempio, fornire linee guida generali per garantire un processo di verifica privo di errori è impegnativo poiché ogni ponte ha requisiti di verifica unici. L’approccio più efficace per prevenire il bypass della verifica è testare accuratamente il bridge contro tutti i possibili vettori di attacco e garantire che la logica di verifica sia valida. 

Per riassumere, è essenziale eseguire test rigorosi contro potenziali attacchi e prestare particolare attenzione alle vulnerabilità di sicurezza più comuni nei bridge.  

Pensieri conclusivi 

A causa del loro elevato valore, i ponti a catene incrociate sono stati a lungo un bersaglio per gli aggressori. I costruttori possono rafforzare la sicurezza dei loro ponti conducendo approfonditi test pre-implementazione e impegnandosi in audit di terze parti, riducendo il rischio degli attacchi devastanti che hanno afflitto i ponti negli ultimi anni. I bridge sono fondamentali in un mondo multi-catena, ma la sicurezza deve essere una preoccupazione primaria quando si progetta e costruisce un'infrastruttura Web3 efficace.

Ulteriori letture

Cos’è un ponte Blockchain?

Che cos'è l'interoperabilità cross-chain?

Tre popolari ponti crittografici e come funzionano

Cosa sono i token wrappati?

Dichiarazione di non responsabilità e avviso di rischio: questo contenuto viene presentato "così com'è" solo a scopo informativo generale e didattico, senza dichiarazioni o garanzie di alcun tipo. Non deve essere interpretato come consulenza finanziaria, legale o di altro tipo, né è inteso a raccomandare l'acquisto di alcun prodotto o servizio specifico. Dovresti chiedere il tuo consiglio a consulenti professionali appropriati. Laddove l'articolo sia fornito da un collaboratore di terze parti, tieni presente che le opinioni espresse appartengono al contributore di terze parti e non riflettono necessariamente quelle di Binance Academy. Si prega di leggere il nostro disclaimer completo qui per ulteriori dettagli. I prezzi degli asset digitali possono essere volatili. Il valore del tuo investimento potrebbe diminuire o aumentare 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. Per ulteriori informazioni, consultare i nostri Termini di utilizzo e Avvertenza sui rischi.