L’hack di Polymarket trasferisce 2,64 milioni di dollari tramite uno script dirottato
L’hack di Polymarket del 29 ottobre ha utilizzato JavaScript malevolo caricato dal sito web del mercato delle previsioni per vendere le posizioni di alcuni trader che avevano già effettuato l’accesso e trasferire i fondi a un wallet controllato da un aggressore. Il codice ha sostituito uno script di terze parti per il monitoraggio delle prestazioni fornito da DebugBear. Polymarket afferma che sta rimborsando circa 2,7 milioni di dollari a 726 wallet interessati, mentre i record della blockchain esaminati dai ricercatori mostrano che circa 2,64 milioni di dollari in criptovalute hanno raggiunto il wallet degli aggressori in meno di un’ora.
Il file legittimo apparteneva al servizio RUM (real user monitoring) di DebugBear, che misura le prestazioni di caricamento delle pagine per i visitatori reali. DebugBear ha dichiarato che i propri record DNS, che indirizzano il traffico internet verso la destinazione online corretta, sono stati compromessi attraverso il registrar del dominio. I primi risultati dell’azienda suggeriscono che sia stato preso di mira il sito web di un singolo cliente. Non aveva trovato prove di una violazione dei propri sistemi, anche se l’indagine era ancora in corso.
I ricercatori di Hudson Rock hanno scaricato il file malevolo il 29 ottobre dall’indirizzo utilizzato da Polymarket per lo script di DebugBear. Hanno inoltre individuato una successiva modifica al codice del sito di Polymarket che ha rimosso l’integrazione. I ricercatori di Ohey hanno rilevato un server diverso che rispondeva per gli indirizzi web di DebugBear alle 18:13 UTC, mentre il file ostile era ancora disponibile. Nelle prime ore dello stesso giorno, lo script normale proveniva da Google Cloud Storage. DebugBear fornisce a ogni cliente una copia separata del file di monitoraggio e la copia sostituita era quella caricata da Polymarket.
Hudson Rock ha esaminato il file senza eseguirlo e ha scoperto che riutilizzava le autorizzazioni già disponibili all’interno di una pagina Polymarket aperta e autenticata. Leggeva le informazioni dell’account conservate nel browser, comprese le API keys per il trading, ossia credenziali utilizzate dal software per comunicare con un servizio online. Queste chiavi non erano sufficienti per inviare un ordine, perché Polymarket richiedeva anche una wallet signature, cioè l’approvazione crittografica di una transazione da parte di un account.
I ricercatori non hanno trovato codice che trasmettesse al server remoto contattato dallo script le API keys, una password, una seed phrase o una private key. Il codice malevolo cercava invece nella pagina le funzioni di Polymarket per l’inserimento degli ordini e il signer responsabile dell’approvazione delle transazioni dell’account. Ciò significa che l’hack di Polymarket ha tentato di utilizzare il processo di transazione esistente e considerato affidabile del sito web, invece di estrarre le credenziali più sensibili del wallet del trader.
Lo script seguiva percorsi diversi a seconda del modo in cui il trader aveva effettuato l’accesso. Per le persone che utilizzavano i propri crypto wallet, tentava di trasferire direttamente le posizioni di trading al wallet degli aggressori. Per gli account basati sull’email, vendeva le posizioni a prezzi progressivamente peggiori prima di trasferire i fondi ottenuti. In entrambi i casi, il codice chiedeva al signer dell’account di approvare le proprie istruzioni e le passava al relayer di Polymarket, un servizio che invia le transazioni firmate.
Hudson Rock ha avvertito che una richiesta inviata a un signer non dimostra che una transazione sia stata completata senza che il trader vedesse una richiesta di approvazione. Un fornitore di wallet poteva comunque mostrare un avviso, rifiutare la richiesta o applicare altre regole di sessione. La lezione pratica per i trader è che le richieste di transazione inattese possono essere pericolose anche quando compaiono all’interno di un sito web nel quale l’utente ha già effettuato l’accesso.
Il tracciamento della blockchain effettuato da Ohey ha rilevato che il wallet incorporato nel codice malevolo ha ricevuto i primi fondi alle 17:10 UTC e gli ultimi alle 18:02 UTC. Durante quel periodo ha raccolto 28,6 milioni di token POL e posizioni di trading da 33 wallet. DefiPrime ha calcolato che i soli POL valevano circa 2,64 milioni di dollari alle 18:19 UTC, utilizzando il prezzo di DefiLlama pari a 0,0922 dollari. Questa valutazione non includeva le posizioni trasferite. I record delle transazioni mostrano che tutti i 28,6 milioni di POL sono stati poi inviati ad altri tre indirizzi tra le 18:28 e le 18:38 UTC.
Polymarket ha pubblicato il primo aggiornamento sullo stato relativo all’attività non autorizzata nei wallet alle 17:38 UTC. Alle 18:05 UTC ha impostato l’exchange in modalità cancel-only, consentendo di annullare gli ordini esistenti ma interrompendo il normale trading, e ha sospeso le operazioni del relayer. L’azienda ha dichiarato di aver rimosso lo script interessato entro un’ora, svuotato le cache, terminato ogni sessione di accesso attiva e sospeso il trading mentre verificava che il sito fosse privo di minacce. Ha segnalato l’incidente alle forze dell’ordine.
Entro il 30 ottobre, Polymarket ha dichiarato che 689 dei 726 wallet interessati avevano ricevuto rimborsi completi. I pagamenti ai restanti 37 erano in fase di elaborazione durante la verifica dei rispettivi casi. Separatamente, l’azienda sta pagando 1,19 milioni di dollari a circa 5.500 wallet che hanno perso denaro durante l’interruzione del trading o ai quali sono state sottratte posizioni, portando a 3,9 milioni di dollari il totale che prevede di restituire ai trader. Gli utenti non devono presentare richieste di rimborso, anche se la pagina di stato mette a disposizione un modulo per chi ritiene che un pagamento sia mancante o errato.
DebugBear ha consigliato ai clienti RUM di rimuovere il proprio codice di incorporamento dai loro siti web. Quando The Hacker News ha effettuato una verifica il 1° novembre, cdn.debugbear.com non aveva più un record DNS. Polymarket ha dichiarato che avrebbe ripristinato gli script di terze parti con controlli aggiuntivi, tra cui versioni bloccate, sandboxing e una Content Security Policy (CSP) più rigorosa, che limita le risorse esterne che un browser è autorizzato a caricare o eseguire.
Hudson Rock consiglia di tenere il codice esterno non necessario lontano dalle pagine in cui gli utenti effettuano operazioni di trading o approvano transazioni. Quando un file può essere fissato a una versione nota, i siti possono utilizzare Subresource Integrity (SRI), un controllo del browser che rifiuta il file quando il suo contenuto non corrisponde più a un valore previsto. Consentire semplicemente un indirizzo affidabile per la distribuzione dei contenuti attraverso una policy di sicurezza non verifica ogni file fornito da quell’indirizzo. I gestori dei siti dovrebbero inoltre esaminare quali operazioni il codice eseguito su una pagina autenticata può chiedere a un signer di approvare.
Questo incidente evidenzia inoltre l’importanza di comprendere dove risieda la fiducia nel DNS all’interno della supply chain di un sito web; AEU DNS fornisce un DNS privato e sicuro per tutti, anche se la compromissione qui segnalata riguardava record gestiti dal registrar e utilizzati da un fornitore esterno di script. Per i proprietari di siti web, il problema centrale è che il codice caricato da un altro dominio può ereditare l’accesso a una pagina sensibile con una sessione già autenticata: la rimozione degli script, controlli rigorosi del browser e un’attenta approvazione delle transazioni sono quindi elementi importanti per limitare l’esposizione.