Questo articolo è un contributo della comunità. L'autore è Minzhi He, revisore dei conti di 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 fondamentali per raggiungere l’interoperabilità nello spazio blockchain. Pertanto, la sicurezza della tecnologia di cross-chain bridging è fondamentale. Alcune comuni vulnerabilità della sicurezza del bridge blockchain includono un'insufficiente verifica on-chain e off-chain, una gestione impropria dei token nativi e un'errata configurazione. Per garantire che la logica di verifica sia valida, si consiglia di testare il ponte a catena incrociata rispetto a tutti i possibili vettori di attacco.

introduzione

Un ponte blockchain è un protocollo che collega due blockchain e consente loro di interagire. Attraverso il ponte blockchain, se gli utenti vogliono partecipare ad attività DeFi sulla rete Ethereum, devono solo detenere Bitcoin e non hanno bisogno di venderlo per raggiungere i propri obiettivi.​

Il bridge Blockchain è la base per l’interoperabilità nel campo blockchain. Per funzionare utilizzano varie verifiche on-chain e off-chain, quindi potrebbero esserci anche diverse vulnerabilità di sicurezza.

Perché la sicurezza dei ponti blockchain è fondamentale?

I bridge blockchain in genere contengono token che gli utenti desiderano trasferire da una catena all'altra. I bridge blockchain vengono solitamente implementati sotto forma di contratti intelligenti. Poiché i trasferimenti cross-chain continuano ad accumularsi, un gran numero di token verrà trattenuto sul bridge. Questa enorme ricchezza li renderà un obiettivo ambito per gli hacker.

Inoltre, la superficie di attacco dei bridge blockchain tende ad essere ampia a causa dei numerosi componenti coinvolti. Pertanto, i criminali hanno forti incentivi a prendere di mira le applicazioni cross-chain per ottenere grandi quantità di fondi.

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

Vulnerabilità comuni della sicurezza del bridge cross-chain

Per migliorare la sicurezza di un bridge blockchain, è importante comprendere le vulnerabilità comuni della sicurezza dei bridge cross-chain e testare il bridge blockchain prima di avviarlo. Queste vulnerabilità derivano principalmente dai seguenti quattro aspetti:

Verifica on-chain insufficiente

Per i bridge blockchain semplici, in particolare quelli progettati per una dApp specifica, di solito esiste solo un livello minimo di verifica on-chain. Questi bridge si basano su un backend centralizzato per eseguire operazioni di base come il conio, la masterizzazione e i trasferimenti di token, con tutte le verifiche che avvengono off-chain.

Mentre altri tipi di bridge utilizzano contratti intelligenti per convalidare i messaggi e verificarli sulla catena. In questo caso, quando un utente deposita fondi nella catena, lo smart contract genera un messaggio firmato e restituisce la firma nella transazione. Questa firma verrà utilizzata come prova del deposito e utilizzata per verificare la richiesta di prelievo dell'utente su un'altra catena. Questo processo dovrebbe prevenire vari attacchi alla sicurezza, inclusi attacchi di riproduzione e record di ricarica falsificati.

Tuttavia, se esiste una vulnerabilità nel processo di verifica sulla catena, un attacco potrebbe causare gravi danni. Ad esempio, se la blockchain utilizza gli alberi Merkle per verificare i record delle transazioni, un utente malintenzionato può generare prove contraffatte. Ciò significa che se il processo di verifica è vulnerabile, un utente malintenzionato può ignorare la verifica di prova e coniare nuovi token nel proprio account.

Alcuni bridge blockchain implementano il concetto di "token avvolti". Ad esempio, quando un utente trasferisce DAI da Ethereum a BNB Chain, il suo DAI viene tolto dal contratto Ethereum e una quantità uguale di DAI incapsulati viene emessa su BNB Chain.

Tuttavia, se questa transazione non viene convalidata correttamente, un utente malintenzionato può implementare un contratto dannoso che manipola questa funzionalità per instradare i token incapsulati dal bridge all'indirizzo sbagliato.​

L'aggressore ha inoltre bisogno che la vittima approvi il contratto di cross-chain bridge prima di utilizzare la funzione "TransferFrom" per trasferire i token, sottraendo così risorse dal contratto di cross-chain bridge.

Ma la parte difficile è che molti bridge cross-chain richiedono agli utenti della dApp di approvare una quantità illimitata di token. Questa pratica è molto comune e può ridurre le tariffe del gas, ma consente ai contratti intelligenti di accedere a una quantità illimitata di token dal portafoglio dell'utente. che comporterà ulteriori rischi. Gli aggressori sfrutterebbero queste sottoverifiche e approvazioni eccessive per trasferire token da altri utenti a se stessi.

Verifica fuori catena insufficiente

In alcuni sistemi bridge cross-chain, i server backend off-chain svolgono un ruolo cruciale nel verificare la legittimità dei messaggi inviati dalla blockchain. In questo caso bisogna concentrarsi sulla verifica dell'operazione di ricarica.

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

1. Gli utenti interagiscono con la dApp e depositano token in contratti intelligenti sulla catena di origine.

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

3. L'hash della transazione deve essere verificato più volte dal 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 verifica e consente all'utente di prelevare token dalla catena target.

Il server backend deve garantire che le transazioni di ricarica gestite siano reali e non contraffatte. Questo server backend determina se un utente può ritirare i token sulla catena di destinazione, rendendola il primo bersaglio degli attacchi.

Il server backend deve verificare la struttura dell'evento di avvio della transazione e l'indirizzo del contratto che ha avviato l'evento. Se quest’ultimo viene ignorato, gli aggressori potrebbero implementare contratti dannosi per falsificare eventi di ricarica con la stessa struttura degli eventi di ricarica legittimi.

Se il server backend non verifica quale indirizzo ha avviato l'evento, presumerà che si tratti di una transazione valida e firmerà il messaggio. Un utente malintenzionato può quindi inviare l'hash della transazione al server backend, aggirando la verifica e consentendogli di ritirare token dalla catena di destinazione.

Gestione impropria dei token nativi

I bridge a catena incrociata adottano un approccio diverso rispetto ai token nativi e ai token di utilità. Ad esempio, sulla rete Ethereum, il token nativo è ETH e la maggior parte dei token di utilità è conforme allo standard ERC-20.

Se un utente intende trasferire i suoi ETH su un'altra catena, deve prima depositarli nel contratto Cross-Chain Bridge. Per fare ciò, l'utente allega semplicemente ETH alla transazione e può recuperare l'importo di ETH leggendo il campo della transazione "msg.value".

Depositare token ERC-20 è molto diverso dal depositare ETH. Per depositare i token ERC-20, gli utenti devono prima consentire al contratto di bridge a catena incrociata di utilizzare i propri token. Dopo aver approvato e depositato i token nel contratto di cross-chain bridge, il contratto utilizzerà la funzione "burnFrom()" per distruggere i token dell'utente, o la funzione "transferFrom()" per trasferire i token dell'utente al contratto.

Per distinguere di quale operazione si tratta, è possibile utilizzare le istruzioni if-else nella stessa funzione. Oppure crea due funzioni separate per gestire ogni scenario. A causa dei diversi metodi di elaborazione, se un utente tenta di depositare ETH utilizzando la funzione di deposito ERC-20, gli ETH potrebbero andare persi.

Quando elaborano le richieste di deposito ERC-20, gli utenti solitamente forniscono l'indirizzo del token come parametro di input per la funzione di deposito. Ciò rappresenta un rischio significativo, poiché durante le transazioni potrebbero verificarsi chiamate esterne non attendibili. L'utilizzo di una whitelist per includere solo i token supportati da un bridge a catena incrociata è una pratica comune per ridurre al minimo i rischi. Come parametri vengono passati solo gli indirizzi inseriti nella whitelist. Ciò impedisce chiamate esterne perché il team di progetto ha filtrato gli indirizzi dei token.

Tuttavia, si verifica anche un problema quando il cross-chain bridge gestisce il trasferimento cross-chain di token nativi, poiché i token nativi non hanno indirizzi. I token nativi possono essere rappresentati da un indirizzo speciale, l'"indirizzo zero" (0x000... 0). Ma c'è un problema con questo, se la logica di verifica della whitelist non è implementata correttamente, il passaggio di un indirizzo zero alla funzione potrebbe ignorare la verifica della whitelist.

Quando il contratto del ponte a catena incrociata chiama "TransferFrom" per trasferire le risorse dell'utente al contratto, la chiamata esterna all'indirizzo zero restituirà false perché la funzione "transferFrom" non è implementata nell'indirizzo zero. Tuttavia, se il contratto non gestisce correttamente il valore restituito, la transazione potrebbe comunque continuare a verificarsi. Ciò crea l'opportunità per un utente malintenzionato di eseguire una transazione senza trasferire alcun token al contratto.

Errore di configurazione

Nella maggior parte dei bridge blockchain, esiste un ruolo privilegiato responsabile della whitelist o della blacklist di token e indirizzi, dell'assegnazione o della modifica dei firmatari e di altre configurazioni chiave. È fondamentale garantire che tutte le configurazioni siano accurate, poiché sviste apparentemente banali possono causare danni significativi.

In effetti, si sono verificati incidenti in cui gli aggressori hanno 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 giorni prima dell'hacking in cui è stata modificata una determinata variabile. Questa variabile è il valore predefinito utilizzato per rappresentare i messaggi attendibili. Questa modifica fa sì che tutti i messaggi vengano automaticamente considerati autenticati, consentendo così a un utente malintenzionato di inviare un messaggio casuale e superare la convalida.

Come migliorare la sicurezza dei ponti a catene incrociate

Le quattro vulnerabilità comuni dei ponti cross-chain sopra descritte dimostrano che le sfide affrontate dalla sicurezza in un ecosistema blockchain connesso non possono essere sottovalutate. Per affrontare queste vulnerabilità, dobbiamo considerare "in base alle condizioni locali". Nessun metodo può essere una panacea per affrontare tutte le vulnerabilità.

Ad esempio, poiché ogni ponte a catena incrociata ha requisiti di verifica unici, sarebbe difficile garantire che il processo di verifica sia privo di errori semplicemente fornendo linee guida generali. Il modo più efficace per impedire il bypass della verifica è testare accuratamente il bridge cross-chain contro tutti i possibili vettori di attacco e garantire che la logica di verifica sia ragionevole.

Nel complesso, devono essere condotti test rigorosi contro potenziali attacchi, con particolare attenzione alle vulnerabilità di sicurezza più comuni nei cross-chain bridge.

Conclusione

A causa dell’enorme volume di fondi, i ponti a catena incrociata sono da tempo presi di mira dagli aggressori. I costruttori possono rafforzare la sicurezza dei ponti a catena incrociata conducendo test completi prima dell'implementazione e incorporando audit di terze parti, riducendo così il rischio di attacchi informatici catastrofici che si sono profilati sui ponti a catena incrociata negli ultimi anni. I bridge cross-chain sono cruciali in un mondo multi-chain, ma la sicurezza deve essere una considerazione primaria quando si progetta e costruisce un'infrastruttura Web3 efficace.

Ulteriori letture

Cos’è un ponte blockchain?

Cos’è l’interoperabilità cross-chain?

Tre popolari ponti di criptovaluta e come funzionano

Cos'è un token avvolto?

Dichiarazione di non responsabilità e avvertenza sui rischi: i contenuti di questo articolo sono fatti e sono solo a scopo informativo generale e didattico e non costituiscono alcuna dichiarazione o garanzia. Questo articolo non deve essere interpretato come consulenza finanziaria, legale o di altro tipo e non costituisce una raccomandazione all'acquisto di alcun prodotto o servizio specifico. Dovresti chiedere il tuo consiglio a consulenti professionali appropriati. Se questo articolo è stato fornito da un collaboratore di terze parti, tieni presente che le opinioni espresse in questo articolo appartengono al contributore di terze parti e non riflettono necessariamente le opinioni di Binance Academy. Per ulteriori informazioni, fare clic qui per leggere il nostro disclaimer completo. I prezzi delle risorse digitali possono variare. Il valore del vostro investimento potrebbe diminuire così come aumentare e potreste non recuperare il capitale investito. Sei l'unico responsabile delle tue decisioni di investimento e Binance Academy non è responsabile per eventuali perdite che potresti subire. Questo articolo non costituisce consulenza finanziaria, legale o di altro tipo. Per ulteriori informazioni, consultare i nostri Termini di utilizzo e Avvertenza sui rischi.