Questo è il tipo di bug che tiene svegli i team di protocollo la notte.
Un exploit da 5 milioni di dollari su ZKSwap, abilitato da una singola dichiarazione lasciata nel posto sbagliato.
Ecco un'analisi approfondita su come è successo e come il monitoraggio onchain avrebbe potuto fermarlo.
🧵

1/ Il 9 luglio, GMX è stato hackerato per 42 milioni di dollari.
Ma quel giorno è successo qualcos'altro che è passato quasi inosservato: il bridge di ZKSwap è stato silenziosamente prosciugato per 5 milioni di dollari.
La parte interessante? Non c'era alcun exploit sofisticato coinvolto. Solo una funzione critica che non ha fatto... nulla.

2/ ZKSwap è un zk-rollup costruito su Ethereum.
Come molti rollup, utilizza un ponte per spostare asset tra L1 e L2.
Come misura di sicurezza, il ponte include una "Modalità Exodus", un modo per gli utenti di recuperare fondi senza bisogno dell'operatore.
In teoria, è un'ottima idea. Nella pratica…
3/ La modalità Exodus consente agli utenti di dimostrare manualmente di possedere token nell'ultimo stato L2 verificato.
È un meccanismo di fallback: senza fiducia, auto-custodiale, non interattivo.
Ma l'implementazione di ZKSwap aveva un difetto fatale: la funzione responsabile della verifica delle prove non verificava nulla.
Letteralmente.
4/ Ecco il codice che avrebbe dovuto fermare l'attacco 👇
A prima vista, sembra un vero verificatore di zk-proof.
Ma guarda attentamente la prima riga: return true;
Ecco tutto. Nient'altro viene eseguito.

5/ Il risultato? Ogni "prova" di prelievo (non importa quanto falsa) ha superato la validazione.
Il contratto ha accettato affermazioni arbitrarie sui saldi dei token... e li ha accreditati come se fossero reali.
Ha trasformato un meccanismo di fallback senza fiducia in un rubinetto non sorvegliato.
6/ L'attaccante non aveva bisogno di exploit sofisticati - solo chiamate ripetute a exit() con dati inventati.
Hanno eluso i controlli di bilancio, prelevato attraverso più token e abusato della debole logica del nullificatore per evitare il rilevamento.
Tutto mentre il contratto diceva: ✅

7/ Questo non era un caso marginale.
Questa era la logica fondamentale per il recupero degli asset, lasciata completamente aperta.
E poiché la Modalità Exodus viene attivata raramente, il percorso rotto è passato inosservato... per mesi.
8/ Ecco cosa avrebbe dovuto far scattare gli allarmi:
• Attivazione della Modalità Exodus dopo un lungo periodo di inattività
• Decine di richieste di prelievo che avvengono tutte in una volta
• Improvviso aumento delle modifiche ai saldiDaPrelevare
Tutto ciò era visibile e avrebbe potuto essere fermato con un monitoraggio onchain in tempo reale.

9/ Qual è la lezione?
• Il codice di emergenza è comunque codice di produzione
• I percorsi di fallback non aiutano se non funzionano
• Il monitoraggio in tempo reale non è facoltativo, è fondamentale per la sopravvivenza
34.130
379
Il contenuto di questa pagina è fornito da terze parti. Salvo diversa indicazione, OKX non è l'autore degli articoli citati e non rivendica alcun copyright sui materiali. Il contenuto è fornito solo a scopo informativo e non rappresenta le opinioni di OKX. Non intende essere un'approvazione di alcun tipo e non deve essere considerato un consiglio di investimento o una sollecitazione all'acquisto o alla vendita di asset digitali. Nella misura in cui l'IA generativa viene utilizzata per fornire riepiloghi o altre informazioni, tale contenuto generato dall'IA potrebbe essere impreciso o incoerente. Leggi l'articolo collegato per ulteriori dettagli e informazioni. OKX non è responsabile per i contenuti ospitati su siti di terze parti. Gli holding di asset digitali, tra cui stablecoin e NFT, comportano un elevato grado di rischio e possono fluttuare notevolmente. Dovresti valutare attentamente se effettuare il trading o detenere asset digitali è adatto a te alla luce della tua situazione finanziaria.