Un script extern compromis a transformat paginile Polymarket deschise de traderi autentificați într-un canal pentru transferarea pozițiilor și fondurilor către atacatori. Incidentul, produs pe 29 octombrie, a afectat 726 de portofele; platforma anunță rambursări de aproximativ 2,7 milioane de dolari, în timp ce trasarea tranzacțiilor arată că aproximativ 2,64 milioane de dolari în tokenuri POL au ajuns la portofelul atacatorilor în mai puțin de o oră.
Codul malițios a înlocuit scriptul DebugBear pe care site-ul Polymarket îl încărca pentru monitorizarea experienței reale a utilizatorilor (RUM), inclusiv măsurarea vitezei de încărcare a paginilor. Cercetătorii Hudson Rock au descărcat fișierul malițios de la adresa folosită de site și au identificat, separat, o modificare a codului Polymarket prin care scriptul DebugBear fusese eliminat.
Un script de performanță a devenit poarta de intrare
DebugBear a declarat pe X că înregistrările DNS ale domeniului său au fost compromise prin intermediul registrarului de domenii. Primele verificări ale companiei indicau că atacul a vizat site-ul unui singur client, iar DebugBear nu găsise dovezi ale unei intruziuni în propriile sisteme; investigația era însă încă în desfășurare.
Cercetătorii Ohey au observat că, la ora 18:13 UTC, o altă adresă de server răspundea pentru domeniile web DebugBear, în timp ce fișierul malițios era încă disponibil. Mai devreme în aceeași zi, scriptul legitim fusese servit din Google Cloud Storage.
Clienții DebugBear încarcă fiecare câte o copie proprie a scriptului, iar copia înlocuită în acest caz era cea a Polymarket.
Sursă foto: blogger.googleusercontent.com
Hudson Rock a analizat fișierul fără să îl execute și a constatat că acesta reutiliza accesul deja disponibil într-o pagină Polymarket cu o sesiune activă. Codul citea din browser detalii despre cont, inclusiv setul de chei API pentru tranzacționare, însă cercetătorii nu au găsit o funcție care să trimită către serverul atacatorilor cheile, parola, fraza-seed sau cheia privată.
Cum a folosit codul sesiunea traderului
Cheile API nu sunt suficiente, singure, pentru a plasa ordine pe Polymarket: operațiunile necesită și o semnătură de portofel. În loc să extragă chei criptografice, scriptul căuta în pagină componenta site-ului care plasează ordine și semnatarul folosit pentru aprobarea tranzacțiilor contului.
Codul urma apoi una dintre două căi. Pentru conturile conectate direct cu un portofel cripto, muta pozițiile traderului către portofelul atacatorilor; pentru conturile autentificate prin e-mail, vindea pozițiile la prețuri progresiv mai nefavorabile, apoi transfera banii obținuți.
În ambele scenarii, scriptul cerea semnatarului asociat contului să aprobe solicitările și le transmitea relayer-ului Polymarket, serviciul care le trimitea mai departe. Hudson Rock a avertizat că existența unei solicitări de semnare nu dovedește că traderul a aprobat-o fără avertizare: furnizorul portofelului putea afișa o confirmare, putea refuza operațiunea sau putea aplica propriile reguli sesiunii.
Portofelul introdus în cod a primit primele fonduri la 17:10 UTC și ultimele la 18:02 UTC, potrivit trasării blockchain realizate de Ohey. În acest interval, adresa a acumulat 28,6 milioane de tokenuri POL și poziții provenite din 33 de portofele, indicând o fereastră de atac concentrată, nu o scurgere lentă de fonduri.
Banii au fost mutați înainte de oprirea tranzacționării
La 18:19 UTC, cele 28,6 milioane de tokenuri POL valorau aproximativ 2,64 milioane de dolari, folosind prețul de 0,0922 dolari indicat de DefiLlama și calculul DefiPrime. Evaluarea se referă numai la tokenurile POL și nu include valoarea pozițiilor colectate separat, astfel că nu trebuie confundată cu suma totală a prejudiciului rambursat.
Istoricul tranzacțiilor arată că portofelul a trimis toate cele 28,6 milioane de tokenuri către alte trei adrese între 18:28 și 18:38 UTC. Polymarket publicase primul mesaj despre activitate neautorizată în portofele la 17:38 UTC, iar la 18:05 UTC anunța trecerea bursei în modul „cancel-only” și suspendarea acțiunilor relayer-ului.
Compania spune că a eliminat scriptul în decurs de o oră, a golit toate cache-urile, a resetat sesiunile de autentificare active și a suspendat tranzacționarea până când site-ul a fost curățat.
Cazul a fost înaintat autorităților. Măsurile au urmărit atât oprirea operațiunilor, cât și invalidarea sesiunilor care puteau păstra accesul deja obținut de cod.
Până la 30 octombrie, 689 dintre cele 726 de portofele afectate fuseseră rambursate integral, iar pentru celelalte 37 plățile urmau să fie făcute pe măsură ce verificările erau finalizate. Separat, Polymarket a anunțat 1,19 milioane de dolari pentru aproximativ 5.500 de portofele care au pierdut bani în timpul pauzei de tranzacționare sau ale căror poziții au fost preluate; suma totală returnată traderilor ajunge astfel la 3,9 milioane de dolari.
Ce schimbă platforma și ce trebuie să verifice utilizatorii
Traderii nu trebuie să depună o cerere pentru rambursare. Pagina de stare Polymarket include totuși un formular pentru cei care consideră că suma primită este greșită sau că ar fi trebuit să primească o plată, iar această verificare rămâne importantă în cazul conturilor cu pierderi ori poziții afectate.
DebugBear le-a cerut clienților produsului RUM să elimine de pe site-uri codul său de integrare. La verificarea The Hacker News din 1 noiembrie, adresa cdn.debugbear[.]com, de unde fusese servit fișierul malițios, nu mai avea o înregistrare DNS.
Polymarket afirmă că reintroduce scripturile terțe cu verificări suplimentare, inclusiv o politică Content Security Policy (CSP) mai strictă, versiuni fixate și sandboxing.
Hudson Rock recomandă administratorilor să nu încarce cod terț inutil pe paginile unde utilizatorii tranzacționează sau semnează operațiuni. Dacă un fișier poate fi fixat, Subresource Integrity (SRI) permite browserului să îl respingă atunci când conținutul se schimbă; simpla permisiune CSP pentru un CDN de încredere nu verifică fișierele servite de acesta.
Echipele de securitate ar trebui, de asemenea, să verifice ce componente dintr-o pagină autentificată pot solicita acțiuni semnatarului, nu doar ce date pot citi din browser. Pentru traderi, recomandarea practică este să respingă orice solicitare de semnare neașteptată și să trateze prompturile portofelului ca pe o decizie de securitate, nu ca pe un pas automat al sesiunii.
