L'indexer Kasplex KRC-20 con bypass della firma prosciuga due pool di token

Cinque transazioni, nessuna chiave privata

La chiave privata dovrebbe rappresentare la linea di demarcazione tra il possesso effettivo di criptovalute e la semplice conoscenza della loro ubicazione. Il 20 settembre, qualcuno ha trovato un modo per aggirare tale presupposto per i token KRC-20 senza compromettere in alcun modo la catena di base di Kaspa.

L’autore dell’attacco ha trasferito 186.425.259 ZEAL e 54.397.983.246 NACHO da un indirizzo di custodia del bridge, pur non controllandone la chiave privata. Tali token sono stati poi rispediti allo stesso indirizzo di custodia come normali depositi del bridge, coniati sul livello EVM di Igra Labs e su Kasplex L2, e riversati nei pool di liquidità di Zealous Swap.

Una volta che la situazione si è stabilizzata, i saldi L2 di ZEAL e NACHO dell’autore dell’attacco erano vuoti, mentre i pool colpiti avevano perso tra il 94% e il 99,6% del loro valore sul lato KAS. Ecco il punto cruciale: il livello uno (L1) di Kaspa ha fatto esattamente ciò che doveva fare.

Una firma vuota che è stata comunque accettata

La proprietà dei token KRC-20 non è imposta direttamente dal consenso di Kaspa. Le istruzioni relative ai token sono contenute nelle transazioni di Kaspa, mentre un indicizzatore off-chain di Kasplex legge tali istruzioni e determina chi possiede cosa. Normalmente, un trasferimento KRC-20 contiene una chiave pubblica, le istruzioni relative ai token e una firma valida. L’autore dell’attacco 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 "false" anziché bloccare immediatamente la transazione. L’OP_NOT aggiuntivo ha ribaltato quel risultato riportandolo a "true", lasciando a Kaspa una transazione valida. A livello di consenso non si era verificato alcun errore. L’indicizzatore, invece, era tutta un’altra storia. Ha riconosciuto l’involucro KRC-20 ma non ha richiesto che lo script corrispondesse esattamente al formato canonico. Di conseguenza, ha considerato legittimo il trasferimento contraffatto. La stessa API di Kasplex ha persino restituito opAccept: 1 sulla prima transazione ZEAL contraffatta.

Chiunque avrebbe potuto creare la contraffazione

La svolta più insidiosa è stata che l’autore dell’attacco non ha avuto bisogno di scoprire alcuna credenziale nascosta. Un indirizzo Kaspa standard espone la chiave pubblica necessaria per costruire l’operazione KRC-20 contraffatta. Ciò significa che spostare i token su un altro indirizzo non risolve il problema di fondo. Finché l’indicizzatore non verrà aggiornato e la sua cronologia reindicizzata, lo stesso difetto può teoricamente essere sfruttato contro i saldi KRC-20 altrove.

Cinque transazioni hanno falsificato i trasferimenti di ZEAL e NACHO. Nove piccoli prelievi di una sola unità, al contrario, sono stati firmati in modo autentico dal servizio di custodia e sembrano essere stati dei test per verificare se la via di fuga funzionasse. È interessante notare che le transazioni legittime erano proprio quelle di importo minimo. Il portafoglio di custodia conteneva circa altri 50 token KRC-20. L’autore dell’attacco ne ha scelti due.

I token ci sono ancora, ma la copertura no

Domenica mattina, Igra ha dichiarato che l’intero patrimonio di ZEAL e NACHO del portafoglio di custodia è stato sottratto, lasciando 97.651.212 ZEAL e 42.570.879.908 NACHO sulle reti di Livello 2 senza piena copertura L1. Altri 4,5 miliardi di NACHO sono rimasti in possesso dell’autore dell’attacco su L1.

Igra ha sospeso i prelievi da iKAS verso Kaspa L1 e i trasferimenti su Hyperlane, mentre gli utenti sono stati avvertiti di non effettuare il bridging di token KRC-20, di non acquistare ZEAL o NACHO sugli exchange decentralizzati (DEX) di L2 e di non aggiungere liquidità ai pool interessati. Il KAS nativo, il consenso Kaspa e gli asset di Igra che non erano token KRC-20 sottoposti a bridging sono stati descritti come non interessati. La sola correzione del software non basterà a risolvere il problema. Zealous Swap afferma che gli operatori devono applicare una patch all’indicizzatore e reindicizzare la sua cronologia, rifiutando le firme vuote, i tag malformati e gli script che proseguono oltre OP_ENDIF. Nacho the Kat, nel frattempo, afferma che la comunità intende passare al KCC-20, uno standard progettato per inserire le regole dei token in script applicati dalla rete stessa.

Il problema fa seguito a una serie di exploit, bug, attacchi hacker e violazioni dei dati verificatisi nelle ultime settimane. Sabato, Blink Wallet, fornitore di infrastrutture custodiali e non custodiali per la Lightning Network, ha reso noto che “alcune dozzine” di conti custodiali sono stati svuotati. Anche la società di sicurezza informatica DCENT ha riscontrato questa settimana prelievi non autorizzati dai portafogli dell’app DCENT. Questo episodio giunge in un momento in cui gli attacchi alla sicurezza informatica si sono intensificati e alcuni sospettano che l’intelligenza artificiale stia favorendo questa ondata di hacker.