Vulnerabilità nella sicurezza dei bridge
Alice C. · 15 ottobre 2025 · 8m ·
Raggiungere l'interoperabilità nello spazio blockchain richiede la presenza di bridge blockchain, che svolgono un ruolo cruciale. Di conseguenza, dare priorità alla sicurezza di questi bridge diventa essenziale. Discutiamone nel nostro blog.
Le debolezze nella sicurezza dei bridge spesso coinvolgono una convalida on-chain e off-chain inadeguata, la gestione impropria dei token nativi e configurazioni errate. Per garantire una logica di verifica solida, è consigliabile testare accuratamente il bridge contro vari vettori di attacco.
Un bridge blockchain è un protocollo che abilita le interazioni tra due blockchain, facilitando una connettività senza soluzione di continuità. Supponiamo che possiedi Bitcoin ma desideri partecipare a operazioni DeFi sulla rete Ethereum. In questo scenario, un bridge blockchain ti consente di prendere parte a queste attività senza liquidare i tuoi Bitcoin.
I bridge blockchain operano implementando diversi meccanismi di convalida on-chain e off-chain, critici per raggiungere l'interoperabilità nel mondo blockchain. Di conseguenza, presentano vulnerabilità distinte in termini di sicurezza.
Secondo stime del settore, gli attacchi ai bridge hanno causato perdite per circa 1,3 miliardi di USD nel 2022, costituendo il 36% delle perdite totali di quell'anno. Questi attacchi prendono di mira principalmente le applicazioni cross-chain: i bridge, spesso implementati come smart contract, tendono ad accumulare token significativi mentre li trasferiscono tra catene. Di conseguenza, i bridge diventano obiettivi attraenti per gli hacker a causa del loro elevato valore.
Inoltre, i bridge blockchain comprendono numerosi componenti, offrendo una vasta superficie di attacco. Gli attori malintenzionati sono fortemente motivati a sfruttare le vulnerabilità all'interno di questi bridge per dirottare fondi significativi.
Per rafforzare la sicurezza dei bridge, è cruciale comprendere le vulnerabilità comuni che possono emergere nel loro design. Prima del lancio, è consigliabile sottoporre i bridge a test approfonditi per identificare e correggere queste debolezze. Questi rischi di sicurezza possono essere categorizzati in aree distinte.
L'enfasi sulla convalida on-chain è ridotta per alcuni bridge, in particolare quelli progettati per specifiche applicazioni decentralizzate (DApp). Questi bridge si affidano a un backend centralizzato per eseguire operazioni fondamentali come il minting, il burning e i trasferimenti di token. Nel frattempo, i processi di validazione vengono eseguiti off-chain.
Al contrario, altri bridge utilizzano smart contract per convalidare i messaggi ed eseguire verifiche on-chain. Quando un utente effettua un deposito di fondi in una chain, lo smart contract genera un messaggio firmato e include la firma nella transazione.
Questa firma funge da prova del deposito ed è successivamente utilizzata per autenticare la richiesta di prelievo dell'utente sulla chain di destinazione. Questo processo robusto mitiga potenziali attacchi, inclusi replay attack e record di deposito contraffatti.
Tuttavia, se è presente una vulnerabilità durante la fase di convalida on-chain, un aggressore può sfruttarla per infliggere danni significativi. Ad esempio, nel caso di un bridge che utilizza un albero Merkle per la validazione dei record di transazione, un attaccante potrebbe fabbricare prove contraffatte. Questa azione malevola consentirebbe di bypassare la convalida delle prove e mintare illecitamente nuovi token sul proprio account, sfruttando la debolezza nel processo di validazione.
L'incorporazione dei cosiddetti "wrapped token" è una strategia comune impiegata da alcuni bridge. Ad esempio, quando un utente trasferisce DAI dalla blockchain Ethereum alla BNB Chain, i suoi DAI vengono ritirati dal contratto su Ethereum e viene successivamente generata una quantità equivalente di DAI wrapped sulla BNB Chain.
Tuttavia, se la validazione di questa transazione è insufficiente, si apre la porta agli attaccanti. Deployando un contratto malevolo e manipolandone le funzioni, questi attaccanti possono dirottare i token wrapped dal bridge verso un indirizzo non voluto.
Per eseguire con successo tale attacco, i perpetratori fanno affidamento sul fatto che le vittime approvino il contratto del bridge, consentendo il trasferimento di token tramite la funzione "transferFrom". Questo permette loro di svuotare gli asset dal contratto del bridge.
Sfortunatamente, la situazione è ulteriormente aggravata dalla pratica adottata da molti bridge di richiedere l'approvazione infinita dei token agli utenti delle applicazioni decentralizzate. Pur riducendo i costi del gas, questa strategia introduce rischi aggiuntivi permettendo a uno smart contract di accedere a token illimitati dal wallet dell'utente. Sfruttando l'assenza di adeguata validazione e l'eccessiva approvazione concessa, gli attaccanti possono siphonare token dagli utenti ignari a proprio favore.
In alcuni sistemi di bridge, il server backend off-chain svolge un ruolo critico 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:
Il server backend deve assicurarsi che la transazione di deposito che elabora sia effettivamente avvenuta e non sia stata contraffatta. Questo server determina se un utente può ritirare token sulla chain di destinazione ed è quindi un obiettivo di alto valore per gli attaccanti.
Il server 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 attaccante potrebbe deployare un contratto malevolo per falsificare un evento di deposito con la stessa struttura di un evento legittimo.
Se il server backend non verifica quale indirizzo ha emesso l'evento, considererebbe la transazione valida e firmerebbe il messaggio. L'attaccante potrebbe quindi inviare l'hash della transazione al backend, bypassando la verifica e consentendo il prelievo dei token sulla chain di destinazione.
I bridge adottano approcci differenti nella gestione dei token nativi e dei token di utilità. Nel caso della rete Ethereum, il token nativo è ETH, mentre la maggior parte dei token di utilità è conforme allo standard ERC-20. Gli utenti devono inizialmente depositare ETH nel contratto del bridge per trasferirlo a un'altra chain. Ciò viene realizzato allegando l'ETH alla transazione e recuperando l'importo dal campo "msg.value".
Il deposito di token ERC-20 differisce significativamente dal deposito di ETH. Per i depositi di token ERC-20, gli utenti devono autorizzare il contratto del bridge a spendere i loro token. Una volta depositati i token, il contratto brucerà i token dell'utente usando la funzione "burnFrom()" o trasferirà i token al contratto usando la funzione "transferFrom()".
Esistono diversi approcci per distinguere tra i due scenari. Un metodo impiega un'istruzione if-else all'interno della stessa funzione, mentre un altro utilizza funzioni separate per ogni scenario. È fondamentale evitare di tentare di depositare ETH usando la funzione di deposito ERC-20, poiché ciò può comportare la perdita dei fondi.
Quando si gestiscono richieste di deposito ERC-20, gli utenti forniscono tipicamente l'indirizzo del token come input alla funzione di deposito. Tuttavia, questo comporta un rischio poiché durante la transazione possono verificarsi chiamate esterne non attendibili. Per mitigare questo rischio, una pratica comune è implementare una whitelist che includa solo i token supportati dal bridge. Consentendo solo indirizzi in whitelist come argomenti, si prevengono chiamate esterne poiché il team del progetto ha già filtrato gli indirizzi dei token.
Tuttavia, possono sorgere difficoltà quando i bridge gestiscono trasferimenti cross-chain di token nativi, poiché i token nativi non possiedono indirizzi. Invece, un indirizzo zero (0x000...0) rappresenta il token nativo. Questo può essere problematico perché passare l'indirizzo zero alla funzione può bypassare la verifica della whitelist, se implementata in modo errato.
Nei casi in cui il contratto del bridge chiama "transferFrom" per trasferire gli asset dell'utente al contratto, una chiamata esterna all'indirizzo zero restituirà false poiché l'indirizzo zero non implementa la funzione "transferFrom". Tuttavia, se il contratto non gestisce correttamente il valore di ritorno, la transazione potrebbe comunque concludersi senza trasferire alcun token al contratto. Ciò consente agli attaccanti di eseguire transazioni senza trasferire token al contratto.
La responsabilità di inserire in whitelist o blacklist token e indirizzi, assegnare o cambiare i signer e altre configurazioni critiche nella maggior parte dei bridge blockchain ricade su un ruolo privilegiato. Una configurazione accurata è fondamentale, poiché anche piccole svista possono avere conseguenze significative.
Un attaccante ha sfruttato una misconfigurazione per bypassare la verifica dei record di trasferimento. Il team di progetto ha implementato un aggiornamento del protocollo che ha comportato la modifica di una variabile. Questa variabile rappresentava il valore predefinito del messaggio considerato trusted. Questa modifica ha portato a messaggi automaticamente considerati provati, permettendo all'attaccante di inviare qualsiasi messaggio e superare la verifica.
Affrontare le sfide di sicurezza in un ecosistema blockchain interconnesso richiede la comprensione delle quattro vulnerabilità comuni dei bridge discusse in precedenza. Ogni vulnerabilità presenta le sue considerazioni e non esiste una soluzione unica.
Nell'istituire processi di verifica privi di errori, fornire linee guida generiche è difficile a causa dei requisiti di verifica variabili di ogni bridge. La strategia più efficace prevede test completi per identificare e mitigare i potenziali vettori di attacco, assicurando al contempo l'integrità della logica di verifica. In conclusione, test rigorosi contro possibili attacchi e un approccio mirato alle vulnerabilità prevalenti dei bridge sono vitali per mantenere un ambiente sicuro.
I bridge cross-chain sono da tempo un bersaglio per gli attaccanti a causa del loro considerevole valore. I builder possono ridurre il rischio dei gravi cyberattacchi che hanno colpito i bridge negli ultimi anni effettuando test approfonditi prima della distribuzione e partecipando a audit di terze parti. I bridge sono essenziali in un mondo multi-chain, ma nello sviluppo e nella costruzione di un'infrastruttura Web3 la sicurezza deve venire prima di tutto.