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
Mostra originale
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.