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

Le opinioni espresse in questo articolo sono quelle del contributore/autore e non riflettono necessariamente le opinioni di Binance Academy.

In breve

I ponti blockchain rappresentano la base per raggiungere l’interoperabilità nel settore blockchain. Pertanto, proteggere i ponti è molto importante. Alcune vulnerabilità comuni della sicurezza del bridge includono un'autenticazione debole in catena e fuori catena, una gestione impropria dei token nativi e configurazioni errate. Il bridge dovrebbe essere testato per garantire che possa resistere a tutti i vettori di attacco e garantire una logica di verifica adeguata.

Introdurre 

Un ponte blockchain è un protocollo che collega due blockchain per consentire l'interazione tra loro. Se possiedi bitcoin ma vuoi partecipare alle attività DeFi sulla rete Ethereum, i ponti blockchain ti consentiranno di farlo senza vendere i tuoi bitcoin. 

I ponti blockchain costituiscono la base per raggiungere l'interoperabilità nello spazio blockchain. Funzionano utilizzando diverse convalide on-chain e off-chain, presentando quindi diverse vulnerabilità di sicurezza.

Perché la sicurezza dei ponti è importante? 

In genere i bridge contengono token che gli utenti desiderano trasferire da una catena all'altra. Spesso utilizzati come contratti intelligenti, i bridge contengono quantità significative di token man mano che si accumulano trasferimenti tra catene, il che li rende un bersaglio redditizio per gli hacker. 

Inoltre, i ponti blockchain hanno un'ampia superficie di attacco perché coinvolgono molti componenti. Data la loro natura, gli autori di attacchi sono fortemente motivati ​​a prendere di mira le applicazioni cross-chain per sottrarre ingenti somme di denaro. 

Secondo le stime di CertiK, entro il 2022 gli attacchi ai ponti causeranno danni per oltre 1,3 miliardi di dollari, pari al 36% delle perdite totali dell'anno. 

Vulnerabilità di sicurezza del Common Bridge

Per migliorare la sicurezza dei bridge, è importante comprenderne le vulnerabilità più comuni e testarli prima di lanciarli. Tali vulnerabilità possono essere classificate nei quattro tipi seguenti. 

Autenticazione on-chain debole

Per i bridge semplici, in particolare quelli progettati per DApp specifiche, la convalida on-chain è spesso minima. Questi bridge si basano su un backend centralizzato per eseguire operazioni di base come la creazione, la combustione e il trasferimento 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 la verifica on-chain. In questo caso, quando un utente deposita fondi in una catena, lo smart contract crea un messaggio firmato e restituisce la firma nella transazione. Questa firma funge da prova di deposito e viene utilizzata per verificare la richiesta di prelievo dell'utente su un'altra catena. Questo processo sarà in grado di prevenire vari attacchi alla sicurezza, tra cui attacchi di replay e falsi registri di deposito. 

Tuttavia, se è presente una vulnerabilità nel processo di convalida on-chain, un aggressore può causare gravi danni. Ad esempio, se un bridge utilizza un albero di Merkle per autenticare i record delle transazioni, un aggressore potrebbe creare prove false. Ciò significa che possono aggirare la convalida della prova e coniare nuovi token nei loro account se il processo di convalida è vulnerabile.

Alcuni bridge implementano il concetto di "token incartati". Ad esempio, quando un utente trasferisce DAI da Ethereum a BNB Chain, il suo DAI viene prelevato dal contratto Ethereum e un importo equivalente di DAI wrapper viene emesso su BNB Chain. 

Tuttavia, se questa transazione non viene convalidata correttamente, un aggressore può implementare un contratto dannoso per instradare i token incapsulati dal bridge a un indirizzo errato, manipolando la funzionalità. 

Gli aggressori hanno anche bisogno che la vittima approvi il contratto bridge per trasferire i token utilizzando la funzione "transferFrom" per prelevare risorse dal contratto bridge. 

Sfortunatamente, la situazione è peggiorata dal fatto che molti bridge richiedono infinite approvazioni di token da parte degli utenti DApp. Si tratta di un metodo diffuso che riduce le commissioni del gas, ma crea rischi aggiuntivi consentendo ai contratti intelligenti di accedere a una quantità illimitata di token dal portafoglio dell'utente. Gli aggressori possono sfruttare la mancanza di autenticazione e l'approvazione eccessiva per trasferire token da altri utenti a loro.

Validazione off-chain debole

In alcuni sistemi bridge, i server backend off-chain svolgono un ruolo importante nella verifica della legittimità dei messaggi inviati dalla blockchain. In questo caso ci concentriamo sulla verifica delle transazioni di deposito. 

Un ponte blockchain con convalida off-chain funziona in questo modo: 

1. Gli utenti interagiscono con la DApp per depositare token nello smart contract sulla catena di origine.

2. Questa DApp invierà quindi la stringa hash della transazione di deposito al server backend tramite API.

3. La catena di hash delle transazioni è soggetta ad una certa autenticazione del server. Se ritenuto legittimo, il firmatario firma un messaggio e invia la firma all'interfaccia utente tramite l'API.

4. Una volta ricevuta la firma, la DApp la verificherà e consentirà all'utente di prelevare i propri token dalla catena di destinazione.

Il server backend deve garantire che la transazione di deposito elaborata sia effettivamente avvenuta e non sia stata manomessa. Questo server backend determina se gli utenti possono prelevare token sulla catena di destinazione e rappresenta 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 si ignora il secondo, un aggressore può 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, considera questa una transazione valida e firma il messaggio. L'aggressore può quindi inviare l'hash della transazione al backend, aggirando la verifica e potendo così prelevare i token dalla catena di destinazione.

Gestione impropria dei token nativi

I bridge hanno approcci diversi per gestire i token nativi e i token di utilità. Ad esempio, sulla rete Ethereum, il token nativo è ETH e la maggior parte degli utility token è conforme allo standard ERC-20. 

Quando un utente intende trasferire i propri ETH su un'altra catena, deve prima depositarli in un contratto bridge. Per raggiungere questo obiettivo, l'utente deve semplicemente allegare ETH alla transazione e l'importo di ETH può essere ottenuto leggendo il campo "msg.value" della transazione.

L'invio di token ERC-20 è notevolmente diverso dall'invio di ETH. Per inviare un token ERC-20, l'utente deve prima autorizzare il contratto bridge a spendere i propri token. Una volta approvata la richiesta e inviati i token al contratto bridge, quest'ultimo brucerà i token dell'utente utilizzando la funzione "burnFrom()" oppure trasferirà i token dell'utente al contratto utilizzando la funzione "transferFrom()". 

Un modo per distinguerlo è utilizzare un'istruzione if-else all'interno della stessa funzione. Un altro approccio consiste nel creare due funzioni distinte per gestire ogni situazione. Il tentativo di depositare ETH utilizzando la funzione di deposito ERC-20 potrebbe comportare la perdita di questi fondi.

Durante l'elaborazione delle richieste di deposito ERC-20, gli utenti in genere forniscono l'indirizzo del token come input alla funzione di deposito. Ciò rappresenta un rischio significativo poiché durante la transazione potrebbero verificarsi chiamate esterne inaffidabili. Un modo comune per mitigare i rischi è implementare una whitelist che includa solo i token supportati dal bridge. È consentito passare come argomenti solo gli indirizzi inseriti nella whitelist. In questo modo si evitano chiamate esterne perché il team del progetto ha filtrato l'indirizzo del token.

Tuttavia, possono sorgere problemi anche quando i bridge gestiscono trasferimenti cross-chain di token nativi, poiché i token nativi non hanno indirizzi. L'indirizzo 0 (0x000...0) rappresenta il token originale. Ciò può rivelarsi problematico perché il passaggio dell'indirizzo 0 a una funzione può aggirare 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 perché non è implementata alcuna funzione "transferFrom" nell'indirizzo zero. Tuttavia, una transazione può comunque verificarsi se il contratto non gestisce correttamente il valore di ritorno. Ciò offre agli aggressori l'opportunità di effettuare transazioni senza trasferire alcun token al contratto.

Configurazione non corretta

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 importanti. È importante assicurarsi che tutte le configurazioni siano corrette, poiché anche errori apparentemente piccoli possono causare perdite significative.

Si sono verificati infatti casi in cui gli aggressori sono riusciti a bypassare il processo di verifica del record di trasferimento a causa di una configurazione errata. Il team del progetto ha effettuato un aggiornamento del protocollo qualche giorno prima dell'attacco hacker, che ha comportato la modifica di una variabile. Variabile utilizzata per rappresentare il valore predefinito del messaggio attendibile. Questa modifica fa sì che tutti i messaggi vengano automaticamente considerati come provati, consentendo così a un aggressore di inviare un messaggio arbitrario e di aggirare il processo di verifica.

Come migliorare la sicurezza dei ponti

Le quattro comuni vulnerabilità di bridging sopra spiegate dimostrano le sfide nel garantire la sicurezza in un ecosistema blockchain interconnesso. Per gestire ciascuna di queste vulnerabilità occorre tenere in considerazione alcuni aspetti importanti e non esiste un'unica strategia valida per tutte le vulnerabilità. 

Ad esempio, fornire linee guida generali per garantire una verifica priva di errori è una sfida, perché ogni bridge ha i propri requisiti di verifica. L'approccio più efficace per prevenire i bypass della verifica è testare accuratamente il bridge contro tutti i possibili vettori di attacco e garantire una solida logica di verifica. 

In breve, è fondamentale eseguire test rigorosi contro potenziali attacchi e prestare particolare attenzione alle vulnerabilità di sicurezza più comuni dei bridge.  

Riepilogo 

A causa del loro elevato valore, i bridge cross-chain sono da tempo un bersaglio per gli aggressori. Gli sviluppatori possono migliorare la sicurezza dei loro bridge eseguendo test approfonditi prima della distribuzione e avvalendosi della partecipazione di terze parti per l'audit, riducendo il rischio di attacchi devastanti che hanno afflitto i bridge negli ultimi anni. I bridge sono una componente essenziale in un mondo multi-catena, ma la sicurezza deve essere una preoccupazione fondamentale nella progettazione e nella costruzione di un'infrastruttura Web3 efficace.

Per saperne di più:

Che cos'è Blockchain Bridge?

Che cosa si intende per interoperabilità cross-chain?

Tre popolari ponti di criptovaluta e come funzionano

Che cosa è un token avvolto?

Dichiarazione di esclusione di responsabilità e avvertenza sui rischi: questo contenuto ti viene presentato "così com'è" esclusivamente a scopo informativo e didattico, senza dichiarazioni o garanzie di alcun tipo. Non deve essere interpretato come consulenza finanziaria, legale o professionale di altro tipo, né è inteso come raccomandazione all'acquisto di uno specifico prodotto o servizio. Dovresti cercare personalmente il consiglio di consulenti professionisti adeguati. Nel caso in cui un articolo sia stato scritto da un collaboratore terzo, tieni presente che le opinioni espresse sono quelle del collaboratore terzo e non riflettono necessariamente le opinioni di Binance Academy. Per maggiori dettagli leggi la nostra completa informativa qui. I prezzi delle attività digitali possono fluttuare. 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. Il presente materiale non deve essere interpretato come consulenza finanziaria, legale o professionale di altro tipo. Per maggiori informazioni, consulta i nostri Termini di utilizzo e l'Avvertenza sui rischi.