Wprowadzenie do problemu / definicja
Platforma Polymarket czasowo wstrzymała handel po wykryciu incydentu bezpieczeństwa związanego ze złośliwym skryptem JavaScript, który miał działać po stronie przeglądarki użytkownika. To klasyczny przykład ataku typu supply chain na frontend, w którym napastnicy wykorzystują zaufany komponent dostarczany przez podmiot trzeci, aby uzyskać dostęp do sesji i inicjować nieautoryzowane operacje na aktywach kryptowalutowych.
Takie zdarzenia są szczególnie niebezpieczne dla platform finansowych i web3, ponieważ użytkownik korzysta z legalnej witryny, a mimo to złośliwy kod może wykonywać działania w ramach jego aktywnej sesji. W praktyce oznacza to, że zagrożenie nie musi wynikać z włamania do głównej infrastruktury transakcyjnej, lecz z kompromitacji zewnętrznej zależności ładowanej w przeglądarce.
W skrócie
Polymarket tymczasowo zatrzymał handel po wykryciu naruszenia powiązanego z zewnętrznym skryptem JavaScript. Według ustaleń badaczy bezpieczeństwa złośliwy kod miał przejmować aktywne sesje użytkowników, wyprzedawać ich pozycje oraz transferować tokeny do portfela kontrolowanego przez atakujących.
- źródłem problemu miał być skompromitowany komponent zewnętrznej usługi,
- atak koncentrował się na użytkownikach posiadających aktywne i uwierzytelnione sesje,
- analiza transakcji wskazywała na przepływy aktywów o wartości około 2,5 mln USD,
- platforma czasowo ograniczyła działanie, a następnie wstrzymała handel,
- firma usunęła problem i zapowiedziała działania naprawcze oraz rekompensatę dla poszkodowanych.
Kontekst / historia
Polymarket działa jako platforma rynku predykcyjnego oparta na aktywach cyfrowych i mechanizmach blockchain. W takim modelu bezpieczeństwo interfejsu użytkownika ma krytyczne znaczenie, ponieważ frontend jest bezpośrednim punktem styku pomiędzy użytkownikiem, jego portfelem oraz logiką wykonywania operacji finansowych.
W opisywanym przypadku nie chodziło o klasyczny błąd aplikacyjny po stronie backendu, lecz o kompromitację zewnętrznego dostawcy skryptu osadzonego w serwisie. To ważne rozróżnienie, ponieważ pokazuje, że nawet dobrze zabezpieczona platforma może zostać narażona na poważny incydent, jeśli korzysta z komponentów trzecich o szerokich uprawnieniach w przeglądarce.
Z dostępnych informacji wynika, że platforma najpierw przeszła w tryb ograniczonego działania, a następnie całkowicie wstrzymała handel na czas analizy sytuacji. Po usunięciu podatnej integracji usługa została przywrócona, a sam incydent zgłoszono odpowiednim organom ścigania.
Analiza techniczna
Technicznie był to incydent klasy browser-side supply chain compromise. Złośliwy JavaScript został dostarczony przez infrastrukturę zewnętrznej usługi, a po załadowaniu w przeglądarce analizował stan sesji użytkownika i dostępne aktywa. Dzięki temu mógł podejmować działania bez konieczności bezpośredniego przełamywania zabezpieczeń głównego systemu transakcyjnego.
Według opisu zachowania malware skrypt sprawdzał, czy użytkownik jest zalogowany do platformy, identyfikował otwarte pozycje, saldo oraz możliwe ścieżki transferu wartości. Następnie dobierał sposób działania do typu aktywów i modelu autoryzacji używanego przez ofiarę.
W części przypadków atakujący mieli najpierw wyprzedawać pozycje rynkowe użytkowników, aby uprościć dalsze przesunięcie środków. W innych scenariuszach skrypt inicjował bezpośredni transfer tokenów do portfela kontrolowanego przez napastników. Tego typu automatyzacja wskazuje, że złośliwy kod nie pełnił wyłącznie roli prostego narzędzia do kradzieży danych, ale aktywnie uczestniczył w monetyzacji przejętych sesji.
Istotnym elementem operacyjnym był również mechanizm komunikacji, który mógł służyć do przekazywania instrukcji i raportowania skuteczności działań. To sugeruje lekką architekturę dowodzenia i kontroli dla kodu uruchamianego w przeglądarce, co zwiększa elastyczność ataku i pozwala napastnikom dynamicznie dopasowywać priorytety kradzieży.
Z perspektywy obronnej ważnym sygnałem było szybkie usunięcie zależności odpowiedzialnej za incydent. Oznacza to, że organizacja zidentyfikowała wektor ataku i wdrożyła działania ograniczające jeszcze przed pełnym przywróceniem funkcji handlowych.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem tego typu ataku jest możliwość utraty środków mimo korzystania z prawidłowej domeny i autentycznego interfejsu. Dla użytkownika aplikacja może wyglądać normalnie, podczas gdy złośliwy komponent działa w tle i wykorzystuje zaufany kontekst sesyjny do wykonywania nieautoryzowanych operacji.
Ryzyko jest szczególnie wysokie w usługach kryptowalutowych i web3, ponieważ transakcje bywają szybkie, trudne do cofnięcia i często zależą od aktywnej autoryzacji po stronie portfela lub sesji webowej. Dodatkowo środki mogą zostać najpierw upłynnione poprzez sprzedaż pozycji, a dopiero potem wyprowadzone poza zasięg ofiary.
- utrata aktywów może nastąpić bez klasycznych oznak włamania do konta,
- przejęta sesja może wystarczyć do uruchomienia operacji wysokiego ryzyka,
- kompromitacja jednego dostawcy frontendowego może uderzyć w wielu użytkowników jednocześnie,
- incydent generuje ryzyko operacyjne, prawne i reputacyjne dla operatora platformy.
Z biznesowego punktu widzenia czasowe zatrzymanie handlu wpływa na ciągłość działania, wiarygodność marki oraz relacje z klientami. Dla sektora fintech i web3 jest to kolejny sygnał ostrzegawczy, że bezpieczeństwo frontendowego łańcucha dostaw powinno być traktowane na równi z ochroną backendu i smart kontraktów.
Rekomendacje
Organizacje korzystające z zewnętrznych skryptów JavaScript powinny ograniczać ich liczbę do niezbędnego minimum i traktować je jako komponenty wysokiego ryzyka. Szczególnie ważne jest odseparowanie funkcji analitycznych, reklamowych i monitoringowych od krytycznych ścieżek biznesowych związanych z logowaniem, handlem i transferem środków.
- utrzymywanie pełnego rejestru wszystkich skryptów third-party ładowanych w aplikacji,
- wdrożenie restrykcyjnej polityki Content Security Policy,
- stosowanie mechanizmów Subresource Integrity tam, gdzie jest to możliwe,
- ciągłe monitorowanie zmian w zależnościach frontendowych,
- testowanie scenariuszy przejęcia sesji i nadużycia logiki biznesowej po stronie klienta,
- wymuszanie dodatkowych kontroli przy operacjach skutkujących transferem wartości.
Dla platform finansowych i kryptowalutowych kluczowe jest również wdrożenie mechanizmów, które rozdzielają zwykłą aktywność sesyjną od operacji o wysokim wpływie finansowym. Sprzedaż pozycji, zamiana aktywów czy transfer tokenów powinny wymagać silniejszej weryfikacji kontekstowej, limitów ryzyka oraz dodatkowego potwierdzenia użytkownika.
Po stronie użytkowników zalecane są dobre praktyki operacyjne:
- uważna weryfikacja każdej podpisywanej operacji w portfelu,
- korzystanie z oddzielnych portfeli do handlu i długoterminowego przechowywania środków,
- ograniczanie ekspozycji aktywów stale dostępnych z poziomu aplikacji przeglądarkowych,
- regularny przegląd aktywnych autoryzacji i uprawnień nadanych aplikacjom web3.
Podsumowanie
Incydent w Polymarket pokazuje, że bezpieczeństwo platform kryptowalutowych nie kończy się na smart kontraktach, backendzie i kontroli dostępu do infrastruktury serwerowej. Coraz większym zagrożeniem staje się cały łańcuch dostaw komponentów uruchamianych w przeglądarce, zwłaszcza tych pochodzących od zewnętrznych dostawców.
Złośliwy skrypt osadzony w zaufanym środowisku może wykorzystać aktywną sesję użytkownika do sprzedaży aktywów, transferu tokenów i automatyzacji kradzieży na dużą skalę. Dla branży oznacza to konieczność zaostrzenia kontroli nad skryptami third-party, wdrożenia silniejszych zabezpieczeń transakcyjnych oraz ponownej oceny modeli zaufania w aplikacjach web3.
Źródła
- BleepingComputer — https://www.bleepingcomputer.com/news/security/polymarket-halts-trading-after-crypto-draining-script-breach-25m-traced/
- Polymarket Status — https://status.polymarket.com/
- Hudson Rock / Infostealers Research — https://www.infostealers.com/
- VirusTotal — https://www.virustotal.com/
- Polygonscan — https://polygonscan.com/