Crypto Prices

Kasplex KRC-20 Indexer: una vulnerabilità svuota due pool di token

prima di 2 ore
2 minuti letti
1 visualizzazioni

Attacco al Portafoglio Bridge KRC-20 di Kaspa

Questo fine settimana, un attaccante ha prelevato 186,4 milioni di ZEAL e 54,4 miliardi di NACHO da un portafoglio bridge KRC-20 di Kaspa, senza possedere la chiave privata, riciclando poi i token attraverso reti di secondo livello (L2) e vendendoli in pool di liquidità. La parte sorprendente è che Kaspa stessa non è stata hackerata.

Meccanismo dell’Attacco

Cinque transazioni valide hanno ingannato un indicizzatore off-chain, facendogli riconoscere trasferimenti che nessuno aveva effettivamente firmato, lasciando i token bridge non garantiti e alcuni pool privi fino al 99,6% del loro valore in KAS. Una chiave privata dovrebbe essere la linea di demarcazione tra possedere criptovalute e semplicemente sapere dove si trovano.

Il 20 settembre, qualcuno ha trovato un modo per aggirare questa assunzione per i token KRC-20, senza compromettere affatto la catena base di Kaspa. L’attaccante ha trasferito 186.425.259 ZEAL e 54.397.983.246 NACHO da un indirizzo di custodia bridge, pur non controllando la chiave privata. Quei token sono stati poi inviati di nuovo allo stesso indirizzo di custodia come normali depositi bridge, coniati sul layer EVM di Igra Labs e su Kasplex L2, e scaricati nei pool di liquidità di Zealous Swap.

Conseguenze dell’Attacco

Quando la polvere si è posata, i saldi L2 di ZEAL e NACHO dell’attaccante erano vuoti, mentre i pool interessati avevano perso tra il 94% e il 99,6% del loro valore in KAS. Ecco il colpo di scena: il layer uno (L1) di Kaspa ha fatto esattamente ciò che doveva fare. La proprietà dei token KRC-20 non è applicata direttamente dal consenso di Kaspa.

Le istruzioni sui token viaggiano all’interno delle transazioni di Kaspa, mentre un indicizzatore Kasplex off-chain legge quelle istruzioni e determina chi possiede cosa.

Normalmente, un trasferimento KRC-20 contiene una chiave pubblica, istruzioni sui token e una firma valida. L’attaccante ha mantenuto quella struttura familiare, ma ha fornito una firma vuota e ha aggiunto un OP_NOT dopo OP_ENDIF. Una firma vuota fa sì che OP_CHECKSIG restituisca falso, piuttosto che annullare immediatamente la transazione. L’ulteriore OP_NOT ha ribaltato quel risultato tornando a vero, lasciando Kaspa con una transazione valida. Nulla era andato storto a livello di consenso.

Implicazioni Future

Fino a quando l’indicizzatore non sarà corretto e la sua storia riindicizzata, la stessa vulnerabilità può teoricamente essere utilizzata contro i saldi KRC-20 altrove. Cinque transazioni hanno contraffatto i trasferimenti di ZEAL e NACHO. Al contrario, nove piccoli prelievi di una sola unità sono stati effettivamente firmati dalla custodia e sembrano essere stati tentativi per testare se il percorso di uscita funzionasse.

È interessante notare che le transazioni legittime erano quelle piccole. Il portafoglio di custodia deteneva circa 50 altri token KRC-20. L’attaccante ha scelto solo due di essi. Domenica mattina, Igra ha dichiarato che l’intero patrimonio di ZEAL e NACHO del portafoglio di custodia era stato prelevato, lasciando 97.651.212 ZEAL e 42.570.879.908 NACHO sulle reti di Layer 2 senza un pieno supporto L1.

Risposta e Misure di Sicurezza

Igra ha sospeso le uscite di iKAS verso Kaspa L1 e i trasferimenti Hyperlane, mentre gli utenti sono stati avvisati di non effettuare bridging di token KRC-20, di non acquistare ZEAL o NACHO su exchange decentralizzati (DEX) L2, o di non aggiungere liquidità ai pool interessati. Il KAS nativo, il consenso di Kaspa e gli asset di Igra che non erano token KRC-20 bridge sono stati descritti come non interessati.

Risolvere il software da solo non pulirà il disastro. Zealous Swap afferma che gli operatori devono correggere l’indicizzatore e riindicizzare la sua storia, rifiutando firme vuote, tag malformati e script che continuano oltre OP_ENDIF. Nacho the Kat, nel frattempo, afferma che la comunità intende passare a KCC-20, uno standard progettato per inserire le regole sui token in script applicati dalla rete stessa.

Contesto degli Attacchi Recenti

La questione segue una serie di exploit, bug, hack e violazioni di dati nelle ultime settimane. Sabato, il fornitore di infrastrutture custodiali e non custodiali della Lightning Network, Blink Wallet, ha rivelato che “alcuni dozzine” di conti custodiali sono stati svuotati. La società di cybersecurity DCENT ha visto i portafogli DCENT App drenati anche questa settimana. Il tempismo arriva mentre gli attacchi informatici sono aumentati e alcuni sospettano che l’IA stia assistendo a questa ondata di sfruttatori.

Popolare