Un script de monitorizare deturnat a golit circa 2,7 mil. $ de la traderii Polymarket

Pe 29 octombrie, un mic fragment de JavaScript pe care platforma de predicții Polymarket îl încărca pentru a măsura viteza paginilor a fost înlocuit discret cu o versiune malițioasă. Timp de aproximativ o oră, scriptul a folosit sesiunile deja autentificate ale traderilor pentru a le transfera pozițiile și fondurile într-un portofel controlat de atacatori. Polymarket afirmă că rambursează aproximativ 2,7 milioane de dolari către 726 de portofele afectate.

Ce s-a întâmplat

Scriptul aparținea DebugBear, un serviciu de real user monitoring (RUM) care măsoară cât de repede se încarcă paginile pentru vizitatorii reali. Fiecare client DebugBear își încorporează propria copie a scriptului — iar copia înlocuită a fost cea a Polymarket.

DebugBear spune că înregistrările sale DNS au fost compromise prin intermediul registrarului de domeniu. Odată ce atacatorii au controlat DNS-ul, adresa de la care site-ul Polymarket descărca scriptul a ajuns să indice un alt server, care livra fișierul malițios în locul celui legitim, găzduit în mod normal în cloud. Primele constatări ale DebugBear indică faptul că a fost vizat site-ul unui singur client, iar compania nu a găsit până acum semne de intruziune în propriile sisteme; investigația continuă.

Cum au fost luați banii

Codul malițios nu a încercat să fure parole, fraze seed sau chei private. În schimb, a profitat de accesul pe care traderul îl avea deja într-un tab Polymarket deschis și autentificat:

• a citit detaliile contului stocate în browser, inclusiv cheile API de tranzacționare;
• a identificat logica de plasare a ordinelor și semnatarul care aprobă tranzacțiile contului;
• pentru conturile autentificate cu un portofel crypto, a transferat pozițiile direct în portofelul atacatorilor;
• pentru conturile autentificate prin e-mail, a vândut pozițiile la prețuri din ce în ce mai proaste și a scos banii.

În ambele cazuri, codul a cerut semnatarului contului să semneze cererile și le-a trimis către relayer-ul Polymarket. Nu este stabilit că toate victimele au semnat „pe nevăzute” — unii furnizori de portofele ar fi putut totuși afișa o confirmare sau aplica propriile reguli — dar rezultatul arată câtă putere are codul care rulează într-o pagină de încredere.

Înregistrările on-chain arată că portofelul atacatorilor a primit fonduri aproximativ între 17:10 și 18:02 UTC, adunând circa 28,6 milioane de tokeni POL (în valoare de aproximativ 2,64 milioane de dolari la acel moment), plus poziții de tranzacționare. Între 18:28 și 18:38 UTC, tokenii POL au fost mutați în alte trei adrese.

Reacția Polymarket

Polymarket a publicat primul anunț despre activitate neautorizată în portofele la 17:38 UTC și a trecut bursa în modul „doar anulare” la 18:05 UTC, suspendând acțiunile relayer-ului. Compania spune că a eliminat scriptul în decurs de o oră, a golit cache-urile, a resetat toate sesiunile active, a ținut tranzacționarea oprită până când site-ul a fost curat și a sesizat autoritățile.

Până pe 30 octombrie, 689 dintre cele 726 de portofele afectate fuseseră rambursate integral, iar celelalte 37 sunt plătite pe măsură ce sunt verificate. Polymarket compensează și aproximativ 5.500 de portofele — circa 1,19 milioane de dolari — care au pierdut bani în timpul pauzei sau cărora le-au fost luate poziții, ceea ce ridică totalul returnat la aproximativ 3,9 milioane de dolari. Traderii nu trebuie să depună nicio cerere. DebugBear le-a cerut clienților RUM să elimine codul încorporat, iar Polymarket spune că scripturile terțe vor reveni doar cu controale mai stricte: o politică Content Security Policy mai restrictivă, versiuni fixate și sandboxing.

De ce contează

Este un exemplu clasic de atac asupra lanțului de aprovizionare web. Codul Polymarket nu a fost niciodată compromis — punctul slab a fost registrarul de domeniu al unui furnizor, aflat la doi pași distanță. Orice script încărcat de pe alt domeniu rulează cu toate privilegiile paginii, iar pe o pagină unde utilizatorii tranzacționează sau semnează tranzacții, asta înseamnă capacitatea de a acționa în numele lor.

Incidentul arată și limitele apărărilor obișnuite. O politică CSP care doar permite un CDN de încredere nu ajută dacă DNS-ul acelui CDN — sau fișierul livrat — se schimbă fără știrea ta.

Ce e de făcut

Pentru proprietarii de site-uri:

1. Inventariați fiecare script terț încărcat de paginile voastre și eliminați tot ce nu e strict necesar din paginile unde utilizatorii se autentifică, tranzacționează, plătesc sau semnează.
2. Fixați versiunea și verificați. Acolo unde un fișier poate fi versionat, folosiți hash-uri Subresource Integrity (SRI), astfel încât browserul să-l refuze dacă i se schimbă conținutul — sau găzduiți-l voi înșivă.
3. Întăriți CSP-ul dincolo de simple liste de domenii permise și izolați scripturile de analiză și monitorizare în iframe-uri sandbox, departe de fluxurile sensibile.
4. Limitați ce poate cere codul din pagină semnatarului. Revizuiți ce acțiuni poate declanșa codul client și cereți confirmare explicită, ușor de înțeles, pentru operațiunile care mută bani.
5. Urmăriți și infrastructura furnizorilor. Schimbările neașteptate de DNS sau de găzduire pe domeniile de unde încărcați cod sunt un semnal de alarmă timpuriu.

Pentru traderi și utilizatori: respingeți orice cerere de semnare la care nu vă așteptați și verificați activitatea portofelului și a contului după orice anunț de incident al unei platforme pe care o folosiți.

Cele mai multe organizații nu au o listă exactă a domeniilor și scripturilor externe de care depind propriile site-uri. Serviciul nostru de Attack Surface Management cartografiază continuu aceste dependențe — inclusiv sursele scripturilor terțe și DNS-ul din spatele lor — și semnalează schimbările neașteptate, astfel încât un script înlocuit sau un domeniu de furnizor deturnat să fie observat înainte să ajungă la utilizatori.