LayerZero attribuisce l’exploit da 290 milioni alla configurazione di Kelp e punta il dito sul gruppo Lazarus della Corea del Nord

LayerZero ha imputato la responsabilità dell’exploit da 290 milioni di dollari subito da Kelp DAO a una configurazione di sicurezza adottata dal progetto stesso, affermando che il protocollo di liquid restaking funzionava con un sistema di verifica a singolo verificatore che era stato esplicitamente sconsigliato.

Il vettore d’attacco e l’infrastruttura compromessa

L’attacco ha sfruttato una nuova tipologia di vettore che ha preso di mira lo strato infrastrutturale invece del codice del protocollo: gli aggressori hanno compromesso due nodi RPC su cui si basava il verificatore di LayerZero per confermare transazioni cross-chain. I nodi RPC sono i server che consentono al software di leggere e scrivere dati su una blockchain; il verificatore di LayerZero usava un mix di nodi interni ed esterni per garantire ridondanza.

Gli aggressori hanno sostituito il software binario in esecuzione su due di quei nodi con versioni malevole in grado di comunicare al verificatore che una transazione cross-chain era avvenuta, continuando però a fornire dati corretti a ogni altro servizio che interrogava gli stessi nodi. Questa falsificazione selettiva è stata progettata per restare invisibile ai sistemi di monitoraggio di LayerZero, che interrogano gli stessi RPC da indirizzi IP differenti.

Però la compromissione di due soli nodi non sarebbe stata sufficiente, perché il verificatore interrogava anche RPC esterni non compromessi: i pirati hanno dunque lanciato un attacco di tipo DDoS contro quei nodi esterni per forzare il failover verso i nodi alterati. Quando il passaggio è avvenuto, i nodi controllati hanno segnalato al verificatore l’arrivo di un messaggio cross-chain valido; di conseguenza il bridge di Kelp ha rilasciato 116.500 rsETH agli aggressori. Il software malevolo poi si è autodistrutto, cancellando binari e log locali.

La configurazione del verificatore e la responsabilità

Il successo dell’attacco è stato possibile perché Kelp adottava una configurazione del verificatore di tipo 1-of-1, cioè LayerZero Labs era l’unico soggetto a firmare e verificare i messaggi del bridge di rsETH. La checklist pubblica di integrazione di LayerZero e le comunicazioni dirette avevano raccomandato una soluzione a più verificatori, con ridondanza e consenso fra diversi verificatori indipendenti.

LayerZero ha scritto:

“KelpDAO ha scelto di utilizzare una configurazione DVN 1/1.”

LayerZero ha aggiunto:

“Una configurazione adeguatamente rinforzata avrebbe richiesto il consenso tra più DVN indipendenti, rendendo questo attacco inefficace anche nel caso di compromissione di una singola DVN.”

Impatto sul protocollo e misure adottate

Secondo LayerZero, non si è verificata alcuna contagiosità verso altre applicazioni che usavano il protocollo: tutti i token e le applicazioni che seguono lo standard OFT e che operavano con configurazioni multi-verificatore sono rimasti immuni. Il verificatore di LayerZero Labs è stato rimesso online e l’azienda ha annunciato che non firmerà più messaggi per applicazioni che mantengano configurazioni 1-of-1, obbligando a una migrazione diffusa verso setup con più verificatori.

Questa distinzione architetturale è cruciale per la percezione del rischio: un difetto a livello di protocollo avrebbe implicato che ogni token OFT su ogni catena fosse potenzialmente vulnerabile. Invece, la combinazione di una scelta di configurazione di un singolo integratore e di un attacco mirato all’infrastruttura suggerisce che il protocollo abbia funzionato come progettato e che la falla sia derivata dalle scelte di sicurezza di Kelp, non dal codice di LayerZero.

Contesto più ampio e attribuzione

LayerZero ha attribuito con fiducia preliminare l’operazione al gruppo nordcoreano Lazarus Group e alla sua unità nota come TraderTraitor. Se confermata, questa associazione rafforzerebbe un pattern recente: lo stesso gruppo è stato collegato all’exploit del Drift Protocol del 1 aprile e ora all’attacco contro Kelp del 18 aprile, per un totale di oltre 575 milioni di dollari sottratti in appena 18 giorni tramite vettori diversi.

Il gruppo ha dimostrato una capacità di adattarsi rapidamente, alternando tecniche di ingegneria sociale per compromettere firmatari di governance a operazioni che avvelenano feed infrastrutturali come gli RPC. Questo ritmo di evoluzione mette in evidenza un divario tra le metodologie di attacco e la velocità con cui molte applicazioni DeFi adeguano le proprie difese.

Reazioni e raccomandazioni operative

La vicenda ha portato LayerZero a imporre un cambio di policy: non supporterà più integrazioni che mantengono un singolo verificatore. Gli operatori di applicazioni DeFi sono invitati a implementare reti di verificatori decentralizzate (DVN) multiple e a diversificare i fornitori di RPC per ridurre la superficie di attacco. Inoltre, è fondamentale implementare monitoraggi incrociati che non si basino su un unico insieme di endpoint o su un singolo indirizzo IP.

Al momento della stesura, Kelp non ha fornito una risposta pubblica alla ricostruzione di LayerZero né ha spiegato le ragioni che hanno portato all’adozione della configurazione 1-of-1.

Implicazioni per il mercato e per gli investitori

Dal punto di vista del mercato, episodi di questo tipo accentuano la necessità di valutare non solo il codice sorgente di un progetto, ma anche le scelte operative e d’integrazione fatte dagli sviluppatori. Gli investitori dovrebbero prestare attenzione alle pratiche di sicurezza operative, alla presenza di verificatori indipendenti e alla dipendenza da fornitori centralizzati di infrastruttura.

Per gli operatori italiani del settore finanziario e tecnologico, la vicenda sottolinea l’importanza di politiche di gestione del rischio che considerino attacchi infrastrutturali mirati e la necessità di collaborare con fornitori affidabili e con audit continui delle configurazioni di rete e dei meccanismi di consenso.

In sintesi

• L’evento mostra come rischi infrastrutturali puntuali possano generare perdite sistemiche: per gli investitori è sempre più importante valutare la governance operativa oltre al codice.
• La migrazione forzata da configurazioni a verificatore singolo verso reti multi-verificatore aumenterà i costi di integrazione e potrebbe determinare diversificazione dei fornitori di RPC, con impatti sulle commissioni e sui tempi di sviluppo delle applicazioni.
• Per il mercato italiano, una maggiore attenzione a standard di resilienza e audit indipendenti può favorire progetti più solidi e attrarre capitali privi di esposizione a rischi di configurazione.