Cos’è un exploit di un bridge cross-chain e come nascono questi attacchi?

Cos’è un exploit di un bridge cross-chain?

Un exploit di un cross-chain bridge è lo sfruttamento di una vulnerabilità in un bridge: un’infrastruttura che permette a blockchain diverse di comunicare tra loro. Sfruttando questa vulnerabilità, un attaccante può per esempio sbloccare token senza un deposito valido, fare il mint di token senza un collaterale sufficiente oppure prelevare riserve dal bridge.

Un bridge cross-chain permette di spostare token, messaggi o altri dati tra blockchain separate. Questo serve perché una blockchain non può controllare automaticamente cosa è successo su un’altra blockchain.

Un exploit può nascere in punti diversi. Pensa a un errore nel controllo dei messaggi, a permessi troppo ampi, a una vulnerabilità negli smart contract oppure a chiavi private rubate di validator o amministratori. In alcuni bridge, per esempio, i validatori confermano che un messaggio proveniente da una blockchain è reale e valido prima che succeda qualcosa sull’altra blockchain.

Cosa importante da sapere: un bridge aggiunge un ulteriore livello di sicurezza sopra le blockchain a cui si collega. In alcuni bridge, per esempio, ci si affida a un gruppo esterno di validator o a un multisig. Altri bridge usano light client e prove crittografiche, come le prove di Merkle, per verificare che una transazione o un evento sia davvero avvenuto sull’altra blockchain. Il modello di sicurezza, e quindi i rischi, possono cambiare molto da bridge a bridge.

Tra l’altro, una pagina di phishing durante il bridging non è automaticamente un exploit del bridge. Una pagina del genere può però indirizzarti verso un contratto malevolo o farti firmare un’autorizzazione indesiderata, ma questo non significa per forza che il bridge sottostante sia stato compromesso.

In breve

• Un bridge cross-chain rende possibile la comunicazione e il trasferimento di valore tra blockchain separate.
• Un exploit di bridge sfrutta una vulnerabilità tecnica o operativa in un bridge di questo tipo.
• Gli attaccanti possono, tra le altre cose, causare pagamenti non autorizzati o fare il mint di token senza un collaterale sufficiente.
• La verifica dei messaggi cross-chain è un punto di sicurezza fondamentale di un bridge.
• Il modello di sicurezza cambia da bridge a bridge e determina quali rischi aggiuntivi corrono gli utenti.

Come funziona un bridge cross-chain?

Un bridge cross-chain osserva un evento sulla blockchain di origine e, dopo aver verificato quell’evento, esegue un’azione corrispondente sulla blockchain di destinazione.

Immagina di voler inviare un token dalla blockchain A alla blockchain B. La blockchain B non può controllare automaticamente se hai davvero inviato quel token sulla blockchain A. Per questo il bridge deve osservare e verificare l’evento sulla blockchain A prima che succeda qualcosa sulla blockchain B.

Un modello molto usato si chiama lock-and-mint. I tuoi token originali vengono bloccati sulla blockchain di origine. Sulla blockchain di destinazione viene poi mintato un wrapped token: una rappresentazione del token originale. Se torni indietro, il wrapped token viene bruciato e i token originali possono essere rilasciati di nuovo.

Esempio: blocchi 1 token sulla blockchain A. Dopo la verifica, ricevi 1 wrapped token sulla blockchain B. Il tuo token originale quindi non si sposta letteralmente sulla blockchain B, ma resta bloccato come collaterale per il token che ricevi lì.

Un altro approccio usa i liquidity pool. Dopo una transazione verificata sulla blockchain di origine, un pool sulla blockchain di destinazione può pagare una quantità equivalente di token.

Il passaggio cruciale è sempre la verifica. Il bridge deve per esempio controllare che un messaggio sia autentico, che provenga dalla blockchain giusta, che rispetti le condizioni corrette e che non sia già stato elaborato in precedenza. Il modo in cui questo avviene cambia da bridge a bridge.

Alcuni bridge supportano anche il generalised message passing. In quel caso possono non solo spostare token, ma anche trasmettere e far eseguire altri dati o comandi tra blockchain. Questo offre più possibilità, ma può anche aumentare la superficie d’attacco.

Quali modelli di sicurezza diversi usano i bridge?

Non tutti i bridge decidono nello stesso modo se un messaggio è valido. Per questo anche il modello di sicurezza può cambiare molto.

Un bridge può per esempio affidarsi a:

• Validator esterni o multisig: un gruppo di soggetti firma i messaggi prima che vengano eseguiti su un’altra blockchain.
• Light client: una blockchain controlla informazioni crittografiche sullo stato dell’altra blockchain.
• Prove crittografiche: un bridge usa per esempio prove di Merkle o altre costruzioni crittografiche per dimostrare gli eventi.
• Verifica ottimistica: i messaggi vengono accettati subito, ma c’è un periodo in cui altre parti possono contestare un messaggio non valido.

Questi modelli hanno compromessi diversi. Un gruppo esterno di validator può per esempio essere più semplice, ma aggiunge un ulteriore livello di fiducia. Un bridge che controlla gli eventi in modo crittografico ha invece altri rischi tecnici. Per questo la sola parola “bridge” dice ancora poco su quanto sia davvero sicuro il sistema.

Come può essere attaccato un bridge cross-chain?

Di solito un attaccante prova a aggirare la verifica del bridge oppure a ottenere il potere di approvare comunque un messaggio cross-chain non valido.

L’idea di base è semplice: se la blockchain di destinazione crede per errore che sulla blockchain di origine siano stati depositati o bloccati dei token, il bridge può per esempio fare il mint di nuovi token o rilasciare riserve senza che ci sia un collaterale sufficiente.

Questo può succedere in diversi modi:

• Un errore fa sì che un messaggio non verificato o falsificato venga comunque accettato.
• Un attaccante ottiene abbastanza chiavi private di validator, firmatari del multisig o amministratori.
• Un bug in uno smart contract salta un controllo importante o assegna troppi permessi a un account.
• La verifica di una prova crittografica, come una prova di Merkle o una prova di light client, contiene un errore.
• Una configurazione sbagliata o un upgrade fanno sì che messaggi non validi vengano comunque trattati come validi.

Una prova di Merkle è un modo crittografico compatto per dimostrare che certi dati fanno parte di un insieme più grande, per esempio dei dati contenuti in un blocco. Se un bridge controlla male questa prova, un attaccante potrebbe far accettare un evento che in realtà non è mai avvenuto in modo valido.

Quindi non tutti gli attacchi passano da chiavi rubate e non tutti i bridge funzionano allo stesso modo. Per capire il rischio bisogna guardare al modello specifico di verifica e di sicurezza del bridge.

Quali vulnerabilità si vedono spesso?

Molti attacchi ai bridge rientrano, in generale, in alcune categorie: errori nei permessi, errori nella logica, problemi nella verifica dei messaggi e problemi di sicurezza operativa.

I permission issues riguardano chi può fare cosa. Magari un account amministrativo ha troppi permessi, gli account dei validator non sono protetti abbastanza oppure i privilegi possono essere modificati in modo errato. Soprattutto con un set piccolo di validator o di multisig, questo può diventare un rischio grande. Se abbastanza firmatari collaborano o vengono compromessi, possono autorizzare pagamenti non validi.

I logic issues sono errori nelle regole degli smart contract. Per esempio, un contratto elabora un messaggio senza controllare tutte le condizioni oppure il mint e il rilascio sono configurati male. Anche gli errori durante un upgrade o nella fase di inizializzazione di un contratto possono rientrare qui.

I message verification issues nascono quando un bridge non controlla abbastanza bene se un messaggio cross-chain è davvero valido. Per esempio, un bridge può accettare la fonte sbagliata, controllare male una prova crittografica oppure eseguire un messaggio che non è mai nato in modo valido sulla blockchain di origine.

I key management issues nascono quando le chiavi private di validator, amministratori o firmatari del multisig vengono rubate o non sono protette bene. Gli smart contract possono anche funzionare correttamente dal punto di vista tecnico, ma un attaccante può comunque produrre firme valide usando chiavi rubate.

Anche i replay attack sono un rischio noto. In questo caso un messaggio già valido viene riutilizzato. Per questo un bridge deve controllare che ogni messaggio possa essere elaborato una sola volta. Un message ID unico, una nonce o un hash possono aiutare.

Un audit può aiutare a trovare vulnerabilità, ma non garantisce che un bridge sia senza errori. Soprattutto dopo upgrade, modifiche alle impostazioni o cambiamenti nell’infrastruttura off-chain, possono nascere nuovi rischi.

Che ruolo hanno frontend e phishing?

Non tutte le perdite durante l’uso di un bridge significano che il bridge stesso sia stato sfruttato. Gli attaccanti possono anche provare a ingannare gli utenti con un sito o un’interfaccia falsi.

Un’interfaccia falsa può per esempio farti inviare una transazione a uno smart contract sbagliato oppure farti dare il permesso di usare i token nel tuo wallet. In questo caso l’infrastruttura tecnica del bridge può restare completamente intatta.

La distinzione è importante: in un bridge exploit viene sfruttato un punto debole nel bridge o nell’infrastruttura intorno ad esso. Nel phishing, invece, di solito l’utente viene ingannato per approvare da solo un’azione dannosa.

Come possono entrare in gioco chiavi private e smart contract?

Le chiavi private e gli smart contract sono componenti importanti di molti bridge. Un problema in uno dei due può già avere conseguenze gravi.

Una chiave privata è una chiave segreta con cui si possono creare transazioni o firme crittografiche. Se un bridge, per esempio, esegue un pagamento solo dopo che più validator hanno firmato, il rischio diventa grande quando un attaccante riesce a mettere le mani su abbastanza di quelle chiavi. L’attaccante può così far approvare istruzioni fraudolente del bridge come se fossero legittime.

Un multisig richiede che più parti firmino prima che un’azione venga eseguita. Questo può essere più sicuro di un singolo account amministrativo, ma non è automaticamente sicuro. La soglia deve essere scelta bene, i firmatari devono essere abbastanza indipendenti e le chiavi private devono essere protette bene.

Nell’attacco al Ronin Bridge, nel marzo 2022, sono state compromesse abbastanza chiavi dei validator da permettere l’approvazione di prelievi non autorizzati. Alla fine sono stati sottratti dal bridge 173.600 ETH e 25,5 milioni di USDC. In seguito il design del bridge è stato modificato e sono state introdotte misure di sicurezza aggiuntive.

Nel caso Harmony Horizon Bridge, nel giugno 2022 sono state compromesse almeno due delle quattro chiavi private dei validator del bridge. Harmony ha comunicato che non c’erano prove che gli smart contract del bridge o il protocollo blockchain stesso fossero stati compromessi. L’incidente mostra che un bridge può essere violato senza che ci sia per forza un errore nel contratto on-chain.

Gli smart contract, nel frattempo, costituiscono le regole on-chain di molti bridge. Controllano per esempio firme o prove crittografiche e poi eseguono azioni come mintare, bruciare, bloccare o rilasciare token. Se questi controlli sono progettati o implementati male, un attaccante può a volte creare token o prelevare riserve senza una transazione sottostante valida.

Una buona protezione richiede quindi sia smart contract sicuri sia una gestione forte delle chiavi.

Quali sono le conseguenze di un exploit di un bridge cross-chain?

Un exploit di un bridge cross-chain può far sparire le riserve, svuotare i liquidity pool o lasciare i wrapped token non più completamente coperti.

Quest’ultimo punto può avere conseguenze pesanti. In un bridge lock-and-mint, un wrapped token dovrebbe normalmente essere coperto da riserve su un’altra blockchain. Se quel collaterale sparisce, la possibilità di riscattare il wrapped token contro l’asset originale può essere messa sotto pressione. Questo può colpire anche i protocolli in cui il token viene usato come collaterale, strumento di trading o liquidità.

I team dei progetti possono a volte mettere temporaneamente in pausa un bridge per limitare ulteriori danni. Dopo l’exploit di Nomad nell’agosto 2022, per esempio, l’elaborazione è stata bloccata dopo che un errore nell’inizializzazione aveva permesso di trattare messaggi non validi come validi. Nell’incidente sono stati sottratti circa 190 milioni di dollari in asset dal bridge.

Nell’exploit di BSC Token Hub nell’ottobre 2022 è stata usata una prova crittografica falsificata, che ha permesso di creare circa 2 milioni di BNB extra. BNB Chain ha coordinato i validator per fermare temporaneamente la blockchain e limitare ulteriori danni. In questo modo gran parte dei BNB coinvolti è rimasta sotto controllo.

Le transazioni blockchain di solito non possono essere semplicemente annullate da una parte centrale come succede, per esempio, con un bonifico bancario tradizionale. Però questo non significa che non si possa mai intervenire. A seconda della rete, validator, team di progetto, emittenti dei token o governance possono a volte prendere misure per fermare ulteriori transazioni, bloccare asset o applicare altre misure di recupero.

Una pausa temporanea può limitare ulteriori danni, ma ha anche degli svantaggi. Gli utenti possono per esempio non riuscire temporaneamente a fare bridging o a recuperare i propri token. Inoltre, uno stop d’emergenza significa che certi amministratori, validator o guardian hanno il potere di rallentare o fermare parti del sistema.

Se gli utenti vengano rimborsati dopo un exploit non è garantito. Dipende tra le altre cose dalle riserve disponibili, dalle assicurazioni, dalle decisioni del progetto, dalla governance e dal fatto che i fondi rubati possano essere recuperati.

Un grande exploit di bridge può anche danneggiare la fiducia in un progetto o in un asset bridged. Questo può influire sulla liquidità e forse anche sul prezzo di mercato, ma l’effetto cambia da incidente a incidente e in base alle condizioni di mercato.

Oltre alla perdita finanziaria diretta, un bridge può quindi diventare meno utile per molto tempo. La liquidità può diminuire, i wrapped token possono essere più difficili da riscattare e gli utenti possono essere più cauti nel riutilizzare il bridge.

Quali exploit famosi di bridge cross-chain ci sono stati?

Ci sono stati diversi grandi exploit di bridge. La causa tecnica è cambiata da incidente a incidente.

• Poly Network: nell’agosto 2021, su Poly Network sono stati spostati oltre 600 milioni di dollari in crypto sfruttando l’infrastruttura cross-chain. In seguito gran parte dei fondi è stata restituita.
• Wormhole: nel febbraio 2022 è stata sfruttata una vulnerabilità in Wormhole su Solana per creare wrapped ETH senza la copertura sottostante richiesta. L’attaccante ha poi spostato una parte degli asset su Ethereum.
• Bridge Ronin: nel marzo 2022 sono state compromesse le chiavi dei validator, permettendo all’attaccante di approvare prelievi non autorizzati. In totale sono stati sottratti dal bridge 173.600 ETH e 25,5 milioni di USDC.
• Harmony Horizon Bridge: nel giugno 2022 sono state compromesse almeno due chiavi private dei validator del bridge. Nell’incidente sono stati rubati circa 100 milioni di dollari in crypto.
• Nomad: nell’agosto 2022 un errore legato all’inizializzazione del contratto Replica ha fatto sì che messaggi non verificati potessero essere trattati come validi. Così diversi indirizzi hanno potuto copiare transazioni e prelevare asset dal bridge. La perdita totale è stata di circa 190 milioni di dollari.
• BNB Chain Token Hub: nell’ottobre 2022 è stato colpito il bridge nativo tra BNB Beacon Chain e BNB Smart Chain. Falsificando una low-level proof, sono stati creati circa 2 milioni di BNB extra.

Gli importi di questi incidenti vanno però letti nel giusto contesto. Una cifra citata può riferirsi al valore di mercato dei token mintati, alle riserve effettivamente sottratte, agli asset bloccati temporaneamente o agli importi poi recuperati. Siccome i prezzi delle crypto si muovono, anche il valore in dollari riportato può cambiare a seconda del momento della rilevazione.

Come si possono prevenire gli exploit dei bridge cross-chain?

Gli exploit dei bridge cross-chain non si possono prevenire del tutto, ma più livelli di sicurezza indipendenti possono ridurre la probabilità di un attacco riuscito e limitare il danno massimo.

La base è una verifica rigorosa. Un bridge deve controllare tra le altre cose da dove arriva un messaggio, se è valido, per quale azione è stato pensato e se non è già stato usato in precedenza. Solo dopo un contratto può per esempio fare il mint di token o rilasciare riserve.

Conta anche il trust model. Un bridge che dipende da un piccolo set esterno di validator o da un multisig ha un profilo di rischio diverso rispetto a un bridge che verifica le informazioni cross-chain tramite, per esempio, light client. Nessun design è completamente privo di rischi.

In più, alcune misure possono aiutare a limitare il danno massimo:

• Rate limit limitano quanta valore può essere spostata in un certo periodo.
• Limiti di prelievo fissano un massimo ai pagamenti.
• Circuit breaker possono rallentare o fermare automaticamente attività anomale.
• Funzioni di pausa possono bloccare temporaneamente alcune attività del bridge durante un incidente.
• Monitoraggio può segnalare più rapidamente messaggi del bridge molto grandi o insoliti.

Un freno d’emergenza di questo tipo non risolve la vulnerabilità di fondo. Però può impedire che un attaccante porti via tutte le riserve disponibili in poco tempo.

Anche audit, bug bounty, code review e test approfonditi sono importanti. Funzionano meglio insieme a un monitoraggio continuo, a una gestione sicura delle chiavi e a un piano di risposta agli incidenti preparato in anticipo.

Quali misure di sicurezza possono prendere gli sviluppatori?

Gli sviluppatori possono ridurre il rischio impostando in modo rigoroso fin dall’inizio verifica, permessi, gestione delle chiavi e misure di emergenza.

1. Controlla ogni messaggio in modo completo. Controlla tra le altre cose la blockchain di origine, il mittente, la nonce o il message ID univoco, la destinazione e la funzione consentita. Così eviti che un messaggio arrivi dalla fonte sbagliata o venga riutilizzato per un’altra azione.

2. Integra una protezione contro i replay. Segna un messaggio già elaborato come usato e non accettarlo di nuovo. Questo aiuta contro i replay attack, in cui lo stesso comando viene eseguito più volte.

3. Concedi il minor numero possibile di permessi. Usa il principio del least privilege. Non tutti gli account devono poter aggiornare i contratti, modificare i validator, fare mint di token o attivare uno stop d’emergenza. Meno poteri ha un singolo account, minore è il danno potenziale se viene compromesso.

4. Proteggi gli account amministrativi con un multisig. Per le operazioni amministrative sensibili, quando ha senso, usa più firmatari indipendenti invece di un solo externally owned account con una sola chiave privata. Un multisig è utile solo se i firmatari e le loro chiavi sono davvero abbastanza indipendenti.

5. Usa un timelock per le modifiche rischiose. Un timelock inserisce un tempo di attesa prima che un upgrade o una decisione di governance venga eseguita. In questo modo le modifiche possono essere controllate in anticipo e le attività sospette possono essere notate prima.

6. Testa più del solo percorso normale. Fai eseguire audit indipendenti, ma testa anche upgrade, inizializzazione, input errati, casi limite e verifica delle prove. L’exploit di Nomad mostra quanto può essere grave un errore durante un upgrade o nella fase di inizializzazione.

7. Prepara in anticipo la risposta agli incidenti. Usa monitoraggio, rilevamento delle anomalie, rate limit e, quando serve, uno stop d’emergenza controllato. Decidi prima chi può intervenire, quali azioni sono possibili e come comunicare durante un incidente.

8. Gestisci con attenzione le chiavi private. Tieni separate e ben protette le chiavi dei validator e degli amministratori. Inoltre, definisci procedure per aggiungere, rimuovere e sostituire i firmatari in modo controllato.

Un audit o un bug bounty non sono un certificato di sicurezza. Nuovi upgrade, relayer off-chain, cambi di configurazione e la sicurezza quotidiana delle chiavi private restano rischi separati.

Come possono limitare il rischio gli utenti?

Come utente non puoi decidere tu la sicurezza di un bridge, ma puoi limitare quanto rischio ti assumi usando un bridge.

1. Guarda il trust model. Controlla quale bridge stai usando e come vengono verificati i messaggi cross-chain. Per esempio, verifica se viene usato un gruppo esterno di validator, un multisig, un light client o un altro modello di verifica.

2. Usa l’interfaccia giusta. Apri il bridge tramite un canale di progetto affidabile e controllato. Prima di firmare una transazione, controlla tra le altre cose l’URL, la blockchain, l’indirizzo di ricezione e il token che stai inviando.

3. Non firmare alla cieca. Controlla cosa fa una transazione o un messaggio prima di firmarlo. La blind signing può esporti a phishing, a un contratto malevolo o ad autorizzazioni indesiderate.

4. Limita le token approval. Quando possibile, concedi solo l’autorizzazione per l’importo necessario. Una token approval può restare attiva on-chain finché non viene modificata o revocata.

5. Revoca le approval non usate. Controlla i vecchi spending cap e revocali se non ti servono più. Scollegare solo il tuo crypto wallet da una dApp non rimuove le approval dei token già esistenti.

6. Limita la tua esposizione. Una piccola transazione di prova può aiutarti a controllare per esempio l’indirizzo, l’interfaccia e il percorso scelto. Però una prova del genere non dimostra che il bridge sia sicuro.

7. Tieni conto del rischio dei token bridged. Dopo un exploit, i wrapped token possono diventare temporaneamente difficili da riscattare o meno liquidi. Più a lungo e più valore dipende da un solo bridge e dalle sue riserve sottostanti, maggiore è l’esposizione a quel rischio specifico.

Controlla inoltre gli avvisi ufficiali aggiornati sugli incidenti e le segnalazioni di sicurezza prima di usare un bridge.

Conclusione

Un bridge cross-chain permette di scambiare token, messaggi e altri dati tra blockchain, ma aggiunge anche un ulteriore livello di sicurezza. Le vulnerabilità possono nascere, tra le altre cose, nella verifica dei messaggi cross-chain, nei permessi, nelle chiavi private, nella configurazione e negli smart contract.

Le conseguenze possono essere pesanti, perché i bridge spesso gestiscono quantità importanti di crypto o sono responsabili della copertura dei wrapped token. Gli incidenti su Poly Network, Wormhole, Ronin, Harmony, Nomad e BNB Chain mostrano inoltre che gli exploit dei bridge possono nascere in modi molto diversi.

Per gli sviluppatori, una buona sicurezza significa quindi più livelli indipendenti: verifica rigorosa, protezione contro i replay, gestione limitata, gestione sicura delle chiavi, monitoraggio e un piano di risposta agli incidenti già pronto. Per gli utenti, invece, è soprattutto importante capire quale trust model usa un bridge, controllare l’interfaccia giusta e tenere conto dei rischi aggiuntivi degli asset bridged.

I bridge hanno un ruolo importante in un ecosistema con più blockchain, ma non sono privi di rischi. Più capisci come un bridge controlla gli eventi su un’altra blockchain e da quali parti o sistemi dipende quella verifica, meglio puoi valutarne il modello di sicurezza.