Sette violazioni di ponti, tre cause ricorrenti

Nel giro di pochi anni, i ponti che collegano reti blockchain diverse hanno concentrato una parte sproporzionata delle perdite più gravi del settore, con importi sottratti che in singoli episodi hanno superato le centinaia di milioni di dollari. Non è un caso isolato che si ripete per sfortuna: è una categoria di infrastruttura che, per come è costruita, accumula un rischio diverso da quello di una singola rete blockchain.

Un ponte deve fidarsi di qualcosa fuori dalla propria catena per sapere che cosa è successo su un’altra catena, e quel punto di fiducia, comunque sia costruito, diventa il bersaglio più conveniente per chiunque cerchi di sottrarre fondi su larga scala. Analizzare insieme le violazioni più costose documentate mostra che, dietro dettagli tecnici diversi, ricorrono sostanzialmente tre cause.

Questo testo ricostruisce sette casi resi pubblici, li classifica secondo la causa che li ha resi possibili e ne trae le lezioni progettuali applicabili a qualunque struttura simile. Riguarda l’analisi tecnica di incidenti passati, non un giudizio su quale ponte sia oggi il più sicuro in assoluto.

Le tre cause, in sintesi

• Chiavi compromesse. Un numero insufficiente di firmatari, o firmatari concentrati in un unico punto di attacco.
• Verifica delle prove insufficiente. Il contratto accetta una prova falsa perché non la controlla con lo stesso rigore della catena di origine.
• Errori di logica nel contratto. Un bug che permette di coniare token senza il deposito corrispondente.
• Il fattore comune. In ogni caso, l’attaccante ha sfruttato il punto in cui il ponte deve fidarsi di un’informazione esterna alla catena su cui opera.
• La scala del danno. I ponti custodiscono spesso fondi aggregati di migliaia di utenti in un unico contratto, il che rende ogni violazione riuscita particolarmente costosa.

Perché un ponte è strutturalmente più esposto di una singola rete

Una rete blockchain isolata verifica le proprie transazioni con le regole del proprio protocollo, senza bisogno di fidarsi di nulla al di fuori di sé stessa. Un ponte, per definizione, deve invece comunicare a una seconda rete che un evento è avvenuto sulla prima, e quella comunicazione richiede un meccanismo di attestazione che non fa parte nativamente di nessuna delle due catene coinvolte.

Questo meccanismo di attestazione, qualunque forma assuma, introduce un punto di fiducia aggiuntivo che non esiste in una rete isolata. Che si tratti di un gruppo di validatori che firma collettivamente, di un client leggero che verifica prove crittografiche, o di un’entità centralizzata che custodisce i fondi da entrambi i lati, quel punto diventa l’obiettivo razionale per chiunque cerchi il modo più efficiente di sottrarre il massimo valore con il minimo sforzo.

Gli exploit dei bridge, per questo motivo, tendono a produrre danni molto più concentrati di un attacco equivalente contro una singola rete: mentre compromettere il consenso di una blockchain matura richiede risorse enormi e quasi mai è economicamente conveniente, compromettere il punto di fiducia di un ponte può richiedere risorse di ordini di grandezza inferiori, a fronte di un valore potenzialmente sottratto altrettanto alto.

Prima causa: le chiavi compromesse

La causa più diretta, e in termini di valore sottratto la più costosa nei casi documentati, riguarda schemi in cui un piccolo gruppo di firmatari autorizza i trasferimenti fra le due catene. Quando la soglia di firme necessarie è bassa rispetto al numero totale di firmatari, o quando la gestione delle chiavi di quei firmatari presenta debolezze operative, un attaccante che riesce a compromettere un numero sufficiente di chiavi può autorizzare trasferimenti fraudolenti indistinguibili, per il contratto, da operazioni legittime.

Il vettore d’attacco più ricorrente in questi casi non è una debolezza crittografica ma un errore operativo: ingegneria sociale contro i dipendenti che gestiscono le chiavi, compromissione dei dispositivi usati per firmare, o architetture in cui troppe chiavi risiedono su infrastrutture controllate dallo stesso soggetto, vanificando di fatto il beneficio teorico di uno schema a più firme che dovrebbe distribuire la fiducia.

Un dettaglio che ricorre in più di un’indagine successiva a questi incidenti è la scoperta che, pur avendo il ponte dichiarato pubblicamente un certo numero di firmatari indipendenti, un sottoinsieme di quelle chiavi era in realtà gestito dallo stesso team tecnico, su infrastrutture condivise. La soglia formale di sicurezza dichiarata al pubblico non corrispondeva, in questi casi, alla soglia reale di indipendenza operativa.

Seconda causa: la verifica delle prove insufficiente

Un secondo gruppo di casi riguarda ponti che verificano l’avvenuto deposito su una catena tramite una prova crittografica, invece di affidarsi a firmatari umani. In questi schemi, l’attacco non compromette chiavi ma sfrutta una debolezza nella logica di verifica: il contratto sulla catena di destinazione accetta come valida una prova costruita in modo da soddisfare il controllo senza che il deposito corrispondente sia mai avvenuto realmente.

Questi episodi sono spesso i più istruttivi dal punto di vista tecnico, perché rivelano una distanza sottile fra una specifica di verifica scritta correttamente sulla carta e la sua implementazione effettiva nel codice, dove un singolo controllo mancante o una condizione limite non gestita può invalidare l’intera garanzia di sicurezza teorica del meccanismo. La ricerca accademica su questo tipo di errore, pubblicata regolarmente attraverso conferenze specializzate come quelle organizzate dalla associazione internazionale di ricerca crittografica, mostra che questi bug sono difficili da individuare anche con una revisione attenta, perché richiedono di ragionare su casi limite che il flusso normale di utilizzo non attraversa mai.

Terza causa: gli errori di logica nel contratto

Il terzo gruppo riguarda difetti nella logica di emissione dei token rappresentativi sulla catena di destinazione, indipendenti sia dalle chiavi sia dal meccanismo di verifica delle prove. Un contratto mal scritto può, in circostanze specifiche, permettere di coniare token rappresentativi senza che il deposito corrispondente sia mai avvenuto, o di coniarne una quantità superiore a quella autorizzata dal deposito originale.

Questi bug nascono spesso da funzioni di amministrazione lasciate accessibili oltre il periodo di test, da controlli di overflow numerico non gestiti correttamente, o da interazioni impreviste fra più funzioni del contratto che, prese singolarmente, sembravano corrette. La revisione del codice da parte di terzi indipendenti riduce ma non elimina questo rischio, come dimostrano casi in cui il contratto era già stato sottoposto a una verifica esterna prima dell’incidente.

Un aspetto che rende questa causa particolarmente insidiosa è che il codice difettoso può restare in produzione per mesi senza alcun problema visibile, funzionando correttamente per ogni utilizzo ordinario, finché qualcuno non individua deliberatamente la sequenza esatta di operazioni che attiva il difetto. Non è quindi un indicatore affidabile il fatto che un contratto abbia già gestito un grande volume di transazioni senza incidenti: significa solo che nessuno ha ancora trovato, o sfruttato pubblicamente, la condizione che lo rende vulnerabile.

Gli exploit dei bridge, classificati per causa

L’ultimo caso della tabella è il più istruttivo in assoluto: mostra che le tre cause non sono alternative fra loro, e che un ponte con una singola difesa solida può comunque cadere se un’altra area riceve meno attenzione durante lo sviluppo.

Che cosa hanno in comune gli episodi più gravi

Al di là della causa tecnica specifica, gli episodi con il valore sottratto più alto condividono un tratto: la quantità di fondi aggregati in un unico punto di custodia superava di gran lunga quella che sarebbe stata prudente concentrare in un singolo meccanismo, per quanto ritenuto sicuro al momento del lancio. La scala stessa del ponte, misurata in valore totale bloccato, è diventata l’incentivo economico che ha giustificato lo sforzo di trovare e sfruttare una debolezza.

Un secondo tratto comune è il tempo trascorso fra il lancio del ponte e l’incidente: raramente le violazioni più gravi sono avvenute nei primi giorni di attività. Nella maggior parte dei casi il ponte aveva già gestito con successo un volume considerevole di transazioni, un fatto che ha rafforzato, ingannevolmente, la fiducia degli utenti e ridotto la pressione percepita per ulteriori verifiche di sicurezza.

Le lezioni progettuali che ne derivano

1. Distribuire davvero i firmatari, geograficamente e organizzativamente, non solo nominalmente su carta.
2. Limitare il valore massimo custodito da un singolo meccanismo, preferendo più ponti indipendenti a uno unico con tutto il capitale concentrato.
3. Sottoporre la logica di verifica a più revisioni indipendenti, non solo a un singolo audit formale prima del lancio.
4. Prevedere un periodo di attesa per i trasferimenti di importo elevato, che dia tempo a un sistema di monitoraggio di intercettare comportamenti anomali prima del completamento.
5. Pubblicare un piano di risposta agli incidenti prima che accadano, non improvvisarlo dopo il primo segnale di allarme.

Nessuna di queste misure elimina il rischio in modo assoluto, ma insieme riducono sia la probabilità di un incidente sia la sua gravità nel caso in cui accada comunque, un compromesso più realistico della promessa, spesso fatta e mai mantenuta, di un ponte del tutto invulnerabile.

Come si valuta un ponte prima di usarlo

Un utente che deve trasferire fondi fra reti diverse può applicare un criterio pratico, prima ancora di entrare nei dettagli tecnici che spesso non è in grado di verificare da solo: informarsi sul valore totale bloccato nel ponte, sulla data dell’ultimo audit pubblicato e sulla presenza di un meccanismo di attesa per i trasferimenti di importo elevato. Nessuno di questi tre elementi garantisce sicurezza assoluta, ma la loro assenza è un segnale che merita attenzione prima di affidare fondi rilevanti.

Vale anche la pena distribuire i trasferimenti importanti su più ponti diversi invece di concentrarli su uno solo, applicando lo stesso principio di diversificazione già discusso a proposito di come distribuire un patrimonio digitale, perché la concentrazione del rischio è, in questo ambito come in altri, il fattore che trasforma un problema tecnico in una perdita irreversibile.

Chi segue le notizie del settore avrà notato che ogni nuovo episodio fra gli exploit dei bridge riaccende la stessa discussione sulla necessità di standard di sicurezza condivisi fra progetti diversi. La realtà osservata finora è che ogni team tende a costruire il proprio meccanismo da zero, spesso ripetendo errori già documentati altrove semplicemente perché l’informazione tecnica sugli incidenti passati non circola con la stessa efficienza con cui circolano gli annunci di lancio di nuovi prodotti.

Domande frequenti

I ponti più recenti sono più sicuri di quelli più vecchi?

Non necessariamente. L’età di un ponte non è di per sé un indicatore di sicurezza: conta di più quante revisioni indipendenti ha ricevuto, quanto è distribuita la gestione delle chiavi e quanto valore ha già gestito senza incidenti, un dato che comunque non garantisce l’assenza di rischio futuro.

I fondi sottratti in questi casi sono mai stati recuperati?

In alcuni casi documentati una parte dei fondi è stata recuperata, tramite negoziazione diretta con l’attaccante o grazie a debolezze nel processo di riciclaggio dei fondi sottratti. Nella maggior parte dei casi il recupero è stato solo parziale o assente, ed è per questo che la prevenzione resta più efficace di qualunque rimedio successivo.

Un ponte con più audit pubblicati è automaticamente sicuro?

No, un audit riduce la probabilità di un difetto residuo ma non la azzera, soprattutto per le interazioni complesse fra più componenti che un singolo controllo può non coprire interamente. Più audit indipendenti, condotti da team diversi, offrono una garanzia maggiore di un audit singolo, ma non una certezza assoluta.

Perché non si costruiscono ponti senza alcun punto di fiducia esterno?

Alcune architetture più recenti riducono al minimo il punto di fiducia richiesto, verificando la prova crittografica dell’evento originale direttamente sulla catena di destinazione senza intermediari umani. Anche in questi casi resta comunque necessario verificare correttamente quella prova, che è esattamente il compito in cui la seconda causa di violazione descritta in questo testo si è manifestata più spesso.

Come si comportano le due catene coinvolte dopo un incidente?

Dipende dal caso. Alcune reti hanno mantenuto la propria integrità mentre il ponte veniva compromesso, isolando il danno al solo meccanismo di collegamento. In altri casi l’incidente ha avuto ripercussioni più ampie sulla fiducia generale verso quella particolare combinazione di reti, indipendentemente dalla responsabilità tecnica specifica di ciascuna catena coinvolta.

Sette casi diversi, tre cause che si ripetono: la lezione più importante non è tecnica in senso stretto, è che ogni punto in cui un sistema deve fidarsi di qualcosa fuori dal proprio controllo diretto merita più attenzione di quanta ne riceve di solito, proporzionata al valore che quel punto finisce per custodire.