Questo articolo è un post della community. L'autore è Minzhi He, un 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.
Riepilogo
I bridge blockchain sono importanti per raggiungere l’interoperabilità nel campo blockchain. Pertanto, la sicurezza del ponte è molto importante. Alcune vulnerabilità di sicurezza comuni dei bridge includono una debole convalida on-chain e off-chain, una gestione impropria dei token nativi e un'errata configurazione. Si consiglia di testare il bridge contro tutti i possibili vettori di attacco per garantire una logica di verifica ragionevole.
introduzione
Bridge blockchain è un protocollo che collega due blockchain per consentire l'interazione tra loro. Se possiedi bitcoin ma vuoi partecipare ad attività DeFi sulla rete Ethereum, i bridge blockchain ti consentono di farlo senza vendere bitcoin.
I ponti blockchain sono essenziali per raggiungere l’interoperabilità nel campo blockchain. Questo bridge funziona utilizzando varie convalide on-chain e off-chain, quindi presenta varie vulnerabilità di sicurezza.
Perché la sicurezza del bridge è importante?
I bridge solitamente memorizzano i token che gli utenti desiderano trasferire da una catena all'altra. I bridge sono spesso implementati come contratti intelligenti e memorizzano grandi quantità di token man mano che i trasferimenti cross-chain si accumulano, rendendoli bersagli allettanti per gli hacker.
Inoltre, i bridge blockchain presentano un ampio gap di attacco perché coinvolgono molti componenti. Pertanto, i criminali sono fortemente motivati a prendere di mira le applicazioni cross-chain per drenare grandi quantità di fondi.
Gli attacchi ai ponti hanno causato perdite per oltre 1,3 miliardi di dollari nel 2022, ovvero il 36% delle perdite totali di quell’anno secondo le stime di CertiK.
Vulnerabilità comuni della sicurezza dei bridge
Per migliorare la sicurezza dei bridge, è importante comprendere le vulnerabilità comuni della sicurezza dei bridge e testarli prima del lancio. Queste vulnerabilità possono essere classificate in quattro aree.
Convalida on-chain debole
Per i bridge semplici, in particolare quelli progettati per DApp specifiche, la convalida on-chain è minima. Il bridge si basa su un backend centralizzato per eseguire operazioni di base come il conio, la masterizzazione e il trasferimento di token, mentre tutta la verifica viene eseguita off-chain.
Al contrario, altri tipi di bridge utilizzano contratti intelligenti per convalidare i messaggi ed effettuare verifiche sulla catena. In questa situazione, quando un utente deposita fondi in una catena, il contratto intelligente genererà un messaggio firmato e restituirà la firma nella transazione. Questa firma serve come prova del deposito e viene utilizzata per verificare le richieste degli utenti su altre catene. Questo processo dovrebbe prevenire vari attacchi alla sicurezza, inclusi attacchi di riproduzione e registrazioni di depositi falsi.
Tuttavia, se esiste una vulnerabilità durante il processo di convalida on-chain, un utente malintenzionato potrebbe causare gravi danni. Ad esempio, se un bridge utilizza un albero Merkle per convalidare i record delle transazioni, un utente malintenzionato potrebbe generare prove false. 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 “token avvolto”. 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 incapsulati viene emesso a BNB Chain.
Tuttavia, se queste transazioni non vengono convalidate correttamente, un utente malintenzionato può implementare un contratto dannoso per instradare i token incapsulati dal bridge all'indirizzo sbagliato manipolandone la funzionalità.
L’aggressore richiede inoltre che la vittima accetti il contratto bridge per trasferire i token utilizzando la funzione “transferFrom” per drenare risorse dal contratto bridge.
Sfortunatamente, la situazione peggiora poiché la maggior parte dei bridge richiede l’approvazione illimitata dei token da parte degli utenti DApp. Questa è una pratica comune che riduce le tariffe del gas, ma introduce rischi aggiuntivi consentendo ai contratti intelligenti di accedere ai token da un numero illimitato di portafogli utente. Gli aggressori possono 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, i server backend off-chain svolgono un ruolo importante nel verificare la validità dei messaggi inviati dalla blockchain. In questo caso, ci concentriamo sulla verifica delle transazioni di deposito.
Il modo in cui un bridge blockchain funziona con la convalida off-chain è il seguente:
Gli utenti interagiscono con la DApp per depositare token in contratti intelligenti sulla catena di origine.
Quindi, la DApp invia l'hash della transazione di deposito al server backend tramite un'API.
Gli hash delle transazioni richiedono una convalida da parte del server. Se ritenuto valido, il firmatario firma il messaggio, quindi invia nuovamente la firma all'interfaccia utente tramite l'API.
Dopo aver ricevuto la firma, la DApp la verifica, quindi consente all'utente di ritirare i token dalla catena target.
Il server di backend deve garantire che la transazione di deposito elaborata sia effettivamente avvenuta e non sia stata falsificata. Questo server backend determina se gli utenti possono ritirare i token sulla catena di destinazione, rendendola un obiettivo di alto valore per gli aggressori.
Il server backend deve convalidare la struttura degli eventi risultante dalla transazione nonché l'indirizzo del contratto che ha generato l'evento. Se l'indirizzo del contratto viene ignorato, un utente malintenzionato può implementare un contratto dannoso per falsificare un evento di deposito utilizzando la stessa struttura di un evento di deposito legittimo.
Se non verifica l'indirizzo che ha generato l'evento, il server backend può presumere che questo contratto sia valido e firmare il messaggio. Quindi, l'aggressore può inviare l'hash della transazione al backend ignorando così la verifica e consentendogli di ritirare token dalla catena di destinazione.
Gestione impropria dei token nativi
Bridge adotta approcci diversi alla 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à segue lo standard ERC-20.
Quando un utente intende trasferire i suoi ETH su un’altra catena, deve prima depositarli nel contratto bridge. Per raggiungere questo obiettivo, gli utenti allegano semplicemente ETH a una transazione, quindi la quantità di ETH può essere recuperata leggendo il campo “msg.value” della transazione.
Depositare token ERC-20 è molto diverso dal depositare ETH. Per depositare i token ERC-20, gli utenti devono prima consentire al contratto bridge di utilizzare i propri token. Una volta che ha accettato e depositato i token nel contratto bridge, il contratto brucerà i token dell'utente utilizzando la funzione "burnFrom()" o trasferirà i token dell'utente al contratto utilizzando la funzione "transferFrom()".
Un approccio per differenziarli è utilizzare le istruzioni 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 fondi.
Quando gestiscono una richiesta di deposito ERC-20, gli utenti in genere forniscono un indirizzo token come input per la funzione di deposito. Questa azione comporta rischi significativi, poiché durante le transazioni possono verificarsi chiamate esterne non attendibili. L'implementazione di una whitelist che includa solo token supportati da bridge è una pratica comune per ridurre al minimo i rischi. È consentito passare come argomenti solo gli indirizzi inseriti nella whitelist. Ciò impedisce chiamate esterne, perché il team di progetto filtra già gli indirizzi dei token.
Tuttavia, sorgono problemi anche quando il bridge gestisce i trasferimenti cross-chain di token nativi, poiché i token nativi non hanno indirizzi. L'indirizzo zero (0x000...0) rappresenta il token originale. Ciò può essere problematico, poiché il passaggio di un indirizzo nullo a una funzione può ignorare la verifica della whitelist anche se implementato in modo errato.
Quando il contratto ponte chiama "transferFrom" per trasferire le risorse dell'utente al contratto, la chiamata esterna all'indirizzo zero restituisce false perché nessuna funzione "transferFrom" è implementata nell'indirizzo zero. Tuttavia, le transazioni possono comunque verificarsi se il contratto non è in grado di gestire correttamente il valore risultante. Ciò crea un’opportunità per gli aggressori di eseguire transazioni senza trasferire token nel contratto.
Errore di configurazione
Nella maggior parte dei bridge blockchain, una posizione privilegiata è responsabile della whitelist o della blacklist di token e indirizzi, dell'assegnazione o della modifica dei firmatari e di altre importanti configurazioni. Garantire che tutte le configurazioni siano accurate è fondamentale, poiché anche errori apparentemente banali possono causare gravi perdite.
In un incidente, infatti, un utente malintenzionato è riuscito a bypassare la verifica del record di trasferimento a causa di un errore di configurazione. Il team del progetto ha implementato un aggiornamento del protocollo diversi giorni prima dell'hacking che includeva la modifica di una variabile. La variabile viene utilizzata per rappresentare il valore predefinito dei messaggi attendibili. Questa modifica fa sì che tutti i messaggi vengano considerati automaticamente provati, consentendo agli aggressori di inviare messaggi a piacimento e ignorare il processo di verifica.
Come migliorare la sicurezza del ponte
Le quattro vulnerabilità comuni dei bridge sopra descritte dimostrano le sfide nel garantire la sicurezza in un ecosistema blockchain interconnesso. Esistono considerazioni significative riguardo alla risoluzione di ciascuna di queste vulnerabilità. Non esiste una linea guida unica che valga per tutto.
Ad esempio, fornire linee guida generali per garantire un processo di verifica privo di errori è difficile, poiché ogni ponte ha requisiti di verifica unici. L’approccio più efficace per prevenire l’elusione della verifica è testare accuratamente il bridge contro tutti i possibili vettori di attacco e garantire che la logica di verifica abbia senso.
In sintesi, è importante condurre test rigorosi per potenziali attacchi e prestare particolare attenzione alle vulnerabilità comuni della sicurezza nei bridge.
Chiusura
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 ponti conducendo test approfonditi prima dell’implementazione e conducendo audit di terze parti per ridurre il rischio di costosi attacchi hacker che hanno afflitto i ponti negli ultimi anni. I bridge sono essenziali 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’è la Bridge 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 per informazioni generali e scopi didattici, senza dichiarazioni o garanzie di alcun tipo. Questo contenuto non deve essere interpretato come consulenza finanziaria, legale o di altro tipo, né è inteso a consigliare l'acquisto di un particolare prodotto o servizio. Dovresti chiedere consiglio a consulenti professionali appropriati. Se l'articolo è un contributo di un collaboratore di terze parti, tieni presente che le opinioni espresse sono quelle del contributore di terze parti e non riflettono necessariamente le opinioni 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 può diminuire o aumentare. Potresti non recuperare l'importo investito. Sei pienamente responsabile delle tue decisioni di investimento. Binance Academy non è responsabile per eventuali perdite che potresti riscontrare. Questo materiale non deve essere considerato consulenza finanziaria, legale o di altro tipo. Per ulteriori informazioni, leggi le nostre Condizioni d'uso e l'Avvertenza sui rischi.