Wprowadzenie do problemu / definicja
Ataki typu supply chain należą do najgroźniejszych i najtrudniejszych do wykrycia incydentów we współczesnych aplikacjach webowych. Ich istota polega na skompromitowaniu zewnętrznego dostawcy usług, skryptu lub komponentu, z którego korzysta docelowa platforma. W przypadku Polymarket skutkiem takiego scenariusza była kradzież środków użytkowników oraz konieczność uruchomienia programu zwrotów o łącznej wartości 3,9 mln dolarów.
To zdarzenie pokazuje, że organizacja nie musi zostać zaatakowana bezpośrednio, aby ponieść poważne straty operacyjne i reputacyjne. Wystarczy naruszenie elementu zewnętrznego, który posiada zaufany dostęp do środowiska użytkownika końcowego.
W skrócie
Polymarket poinformował o zwrocie 3,9 mln dolarów użytkownikom dotkniętym incydentem bezpieczeństwa. Według dostępnych ustaleń złośliwy kod JavaScript został dostarczony przez zewnętrzny komponent powiązany z usługą DebugBear, a źródłem problemu miało być przejęcie rekordów DNS przez poziom rejestratora domeny.
- atak miał charakter supply chain i dotyczył komponentu zewnętrznego,
- złośliwy skrypt działał w kontekście aktywnych sesji użytkowników,
- celem były środki oraz pozycje handlowe na platformie,
- Polymarket wstrzymał handel i uruchomił proces kompensacji,
- incydent uwypuklił ryzyko związane z osadzaniem skryptów third-party.
Kontekst / historia
Incydent został ujawniony po zgłoszeniach użytkowników dotyczących nieautoryzowanych wypłat oraz podejrzanych działań na ich pozycjach handlowych. W odpowiedzi Polymarket czasowo wstrzymał handel na swojej międzynarodowej platformie i rozpoczął analizę skali zdarzenia. Z czasem firma poinformowała, że problem objął setki portfeli, a równolegle trwały działania mające ustalić pełną wartość strat i zakres odpowiedzialności.
Zdarzenie wpisuje się w szerszy trend ataków wymierzonych w warstwę frontendową aplikacji. W tego typu operacjach złośliwy kod nie jest wstrzykiwany bezpośrednio do głównej aplikacji, lecz trafia do niej przez legalnie zintegrowany zasób zewnętrzny. Dla platform finansowych i krypto jest to szczególnie niebezpieczne, ponieważ przeglądarka użytkownika staje się miejscem wykonywania działań autoryzowanych aktywną sesją.
Dodatkowym problemem jest fakt, że podobne incydenty związane z ryzykiem dostawców zewnętrznych nie są w branży odosobnione. Każdy taki przypadek wzmacnia przekonanie, że bezpieczeństwo nowoczesnych usług cyfrowych należy oceniać nie tylko przez pryzmat własnej infrastruktury, ale również całego ekosystemu partnerów technologicznych.
Analiza techniczna
Według dostępnych informacji złośliwy skrypt był serwowany z adresu powiązanego z usługą DebugBear, której kod był osadzony w witrynie Polymarket. Wstępne ustalenia wskazują, że rekordy DNS dostawcy zostały przejęte za pośrednictwem rejestratora domeny. Taki scenariusz oznacza, że atakujący nie musieli uzyskiwać dostępu do głównej infrastruktury aplikacyjnej Polymarket ani przełamywać jej mechanizmów uwierzytelniania.
Mechanizm działania był ukierunkowany na zalogowanych użytkowników. Skrypt analizował stan portfela oraz aktywne pozycje, a następnie inicjował działania prowadzące do sprzedaży aktywów lub ich transferu do portfela kontrolowanego przez napastników. Kluczowe znaczenie ma tutaj fakt, że operacje odbywały się w ramach już uwierzytelnionej sesji przeglądarkowej.
To ważne rozróżnienie z perspektywy technicznej. W takim modelu ataku przestępcy nie muszą kraść haseł, seed phrase ani kluczy prywatnych, aby spowodować realne szkody finansowe. Wystarczy przejęcie zaufanego kanału dostarczania kodu i wykorzystanie uprawnień, które użytkownik już posiada w aktywnej sesji.
Dostępne ustalenia sugerują także, że skrypt odczytywał dane związane z poświadczeniami przechowywanymi w przeglądarce, jednak nie wskazano dowodów na pełną eksfiltrację danych uwierzytelniających o najwyższym poziomie wrażliwości. Jeśli potwierdzi się, że systemy wewnętrzne dostawcy nie zostały naruszone, głównym punktem wejścia pozostaje warstwa zarządzania domeną i DNS, która w wielu organizacjach nadal nie jest traktowana jako zasób krytyczny.
Konsekwencje / ryzyko
Najbardziej bezpośrednim skutkiem incydentu były straty finansowe użytkowników. Decyzja Polymarket o pokryciu zarówno skradzionych środków, jak i szkód wynikających z wymuszonej sprzedaży pozycji oraz przerwy w handlu, miała istotne znaczenie dla ograniczenia strat reputacyjnych i utrzymania zaufania klientów.
Ryzyko techniczne i organizacyjne jest jednak znacznie szersze. Incydent pokazuje, że pozornie pomocnicze komponenty frontendowe mogą uzyskać bardzo szeroki wpływ operacyjny na aplikację i użytkownika końcowego.
- skrypty stron trzecich tworzą krytyczny obszar zaufania,
- przejęcie DNS może umożliwić podmianę legalnych zasobów bez zmian w kodzie głównej aplikacji,
- aktywne sesje użytkowników mogą zostać wykorzystane do autoryzowanych, ale niepożądanych działań,
- brak kradzieży hasła nie oznacza braku skutecznego przejęcia kontroli nad operacjami,
- platformy fintech, Web3 i e-commerce są szczególnie narażone na tego typu wektory.
Dla rynku oznacza to konieczność traktowania narzędzi analitycznych, monitorujących i wydajnościowych jako pełnoprawnych elementów powierzchni ataku. Nawet jeśli nie uczestniczą one bezpośrednio w logice transakcyjnej, mogą zostać użyte do manipulacji interfejsem, odczytu danych sesyjnych lub inicjowania operacji w imieniu użytkownika.
Rekomendacje
Organizacje rozwijające aplikacje obsługujące środki finansowe powinny ograniczać zależność od zewnętrznych skryptów wykonywanych w przeglądarce użytkownika. Jeśli integracja z dostawcą zewnętrznym jest niezbędna, konieczne jest wdrożenie ścisłej kontroli nad frontendowym łańcuchem dostaw.
- przegląd i redukcja wszystkich skryptów third-party ładowanych w aplikacji,
- stosowanie restrykcyjnej polityki Content Security Policy,
- wdrożenie mechanizmu Subresource Integrity tam, gdzie jest to możliwe,
- ochrona kont u rejestratora domen przez silne MFA, separację uprawnień i alertowanie,
- monitorowanie zmian DNS oraz anomalii związanych z rozwiązywaniem domen,
- separacja funkcji pomocniczych od logiki transakcyjnej i krytycznych danych sesyjnych,
- wykrywanie anomalii po stronie backendu dla nietypowych operacji wykonywanych z aktywnej sesji,
- krótszy czas życia sesji oraz dodatkowe potwierdzenia dla operacji wysokiego ryzyka,
- procedury awaryjne umożliwiające szybkie odłączenie dostawcy trzeciego i przejście do trybu ograniczonego działania.
Z perspektywy użytkowników końcowych kluczowe pozostaje monitorowanie historii operacji, szybkie wylogowywanie nieużywanych sesji oraz ostrożność wobec nietypowych zachowań interfejsu. W środowiskach kryptowalutowych warto również rozważyć oddzielenie portfeli wykorzystywanych do bieżącego handlu od głównych zasobów.
Podsumowanie
Incydent związany z Polymarket pokazuje, że bezpieczeństwo aplikacji internetowej jest bezpośrednio uzależnione od odporności jej dostawców zewnętrznych. W tym przypadku przejęcie rekordów DNS i dostarczenie złośliwego JavaScriptu wystarczyły, aby wykorzystać aktywne sesje użytkowników i doprowadzić do znaczących strat finansowych.
Zwrot 3,9 mln dolarów ogranicza biznesowe skutki zdarzenia, ale nie zmienia najważniejszego wniosku. Organizacje muszą traktować komponenty frontendowe, relacje z podmiotami trzecimi oraz bezpieczeństwo DNS jako obszary krytyczne dla cyberbezpieczeństwa i ciągłości działania.
Źródła
- SecurityWeek — Polymarket Returns $3.9 Million to Traders as DebugBear Cites DNS Hijack — https://www.securityweek.com/polymarket-returns-3-9-million-to-traders-as-debugbear-cites-dns-hijack/
- Polymarket — aktualizacja incydentu opublikowana na platformie X — https://x.com/Polymarket/status/1981402114415267911
- DebugBear — initial findings opublikowane na platformie X — https://x.com/DebugBear/status/1981398852202874944
- Hudson Rock — analiza incydentu Polymarket — https://www.infostealers.com/article/polymarket-attack-analysis/
- SecurityWeek — $2 Million+ Drained From Polymarket Traders in New Supply Chain Attack — https://www.securityweek.com/2-million-drained-from-polymarket-traders-in-new-supply-chain-attack/