Atak supply chain na Polymarket: złośliwy skrypt przejął aktywne sesje i wywołał wielomilionowe straty

Wprowadzenie do problemu / definicja

Atak supply chain to scenariusz, w którym cyberprzestępcy nie muszą bezpośrednio łamać zabezpieczeń głównej platformy. Zamiast tego kompromitują zaufany element zewnętrzny, taki jak skrypt JavaScript, usługa analityczna lub komponent monitoringu, a następnie wykorzystują go do dostarczenia złośliwego kodu użytkownikom końcowym.

W incydencie związanym z Polymarket taki mechanizm miał szczególnie poważne skutki, ponieważ dotknął środowiska finansowego, w którym aktywna sesja użytkownika może wystarczyć do wykonania kosztownych operacji. To pokazuje, iż bezpieczeństwo nowoczesnych aplikacji nie kończy się na backendzie i ochronie kont, ale obejmuje także cały łańcuch zależności uruchamianych w przeglądarce.

W skrócie

Polymarket czasowo wstrzymał handel na swojej międzynarodowej platformie po zgłoszeniach nieautoryzowanych wypłat i operacji wykonywanych bez zgody użytkowników. Firma wskazała na problem po stronie zewnętrznego dostawcy i zapowiedziała rekompensatę dla poszkodowanych, a handel wznowiono po wdrożeniu działań ograniczających skutki incydentu.

Z analiz opublikowanych po zdarzeniu wynika, iż złośliwy kod miał być dostarczany przez skrypt powiązany z narzędziem monitorowania wydajności. Po uruchomieniu w przeglądarce identyfikował zalogowanych użytkowników, analizował interfejs transakcyjny i podejmował próby sprzedaży pozycji lub transferu tokenów pozycyjnych na adres kontrolowany przez atakujących. Szacunki strat różnią się w zależności od źródła, ale mowa o kwotach przekraczających 2 mln dolarów.

Kontekst / historia

Incydent wpisuje się w rosnący trend ataków na warstwę klienta, w których przeglądarka staje się jednym z najważniejszych pól walki. W takim modelu pojedyncza kompromitacja zewnętrznego zasobu może oddziaływać jednocześnie na wielu użytkowników, choćby jeżeli sama infrastruktura serwerowa organizacji nie została bezpośrednio przejęta.

W przypadku platform finansowych i kryptowalutowych ryzyko jest szczególnie wysokie. Frontend coraz częściej realizuje istotną część logiki biznesowej, obsługuje sesje, inicjuje żądania API oraz pośredniczy w interakcjach z portfelami i mechanizmami handlowymi. To sprawia, iż zewnętrzne skrypty telemetryczne, analityczne lub wydajnościowe stają się elementami o znaczeniu krytycznym, mimo iż pierwotnie nie służą do realizacji transakcji.

Atak na Polymarket pokazuje również szerszy problem branży: organizacje często traktują komponenty trzecie jako pomocnicze, podczas gdy z perspektywy bezpieczeństwa mogą one uzyskać dostęp do tego samego kontekstu wykonawczego co kod głównej aplikacji. jeżeli taki komponent zostanie skompromitowany, granica między „dodatkiem” a „uprzywilejowanym modułem” praktycznie przestaje istnieć.

Analiza techniczna

Z technicznego punktu widzenia mamy do czynienia z klasycznym przykładem kompromitacji zewnętrznego skryptu JavaScript ładowanego przez produkcyjną aplikację webową. Po wykonaniu w przeglądarce ofiary złośliwy kod działał w kontekście zaufanej strony, co dawało mu możliwość obserwowania interfejsu, reagowania na zdarzenia oraz korzystania z uprawnień dostępnych w aktywnej sesji.

Według publicznie opisanych analiz skrypt wyszukiwał elementy DOM związane z handlem i portfelem użytkownika. Następnie, zależnie od dostępnych zasobów i typu konta, miał realizować jeden z dwóch scenariuszy: sprzedaż pozycji i przekierowanie środków albo bezpośredni transfer tokenów pozycyjnych na wcześniej przygotowany adres atakującego.

Kluczowe jest to, iż atak nie musiał opierać się na kradzieży hasła, frazy seed czy klucza prywatnego. Mechanizm nadużycia wykorzystywał fakt, iż użytkownik był już zalogowany i dysponował aktywną, poprawnie uwierzytelnioną sesją. W praktyce oznacza to działanie „w imieniu” ofiary, z użyciem jej legalnych uprawnień oraz z wykorzystaniem standardowego przepływu aplikacji.

Tego rodzaju incydenty są trudne do wykrycia po stronie backendu. Operacje mogą wyglądać jak poprawne żądania wygenerowane przez autentycznego użytkownika: z adekwatnej przeglądarki, prawidłowej sesji i typowego adresu IP. jeżeli organizacja nie posiada zaawansowanej detekcji anomalii zachowania, odróżnienie legalnej aktywności od zautomatyzowanego nadużycia frontendowego staje się bardzo trudne.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem są straty finansowe użytkowników. W przypadku Polymarket skala szkód została oszacowana na ponad 2 mln dolarów, co pokazuje, iż choćby krótki czas ekspozycji na złośliwy skrypt może prowadzić do bardzo szybkiej monetyzacji ataku.

Po stronie organizacji konsekwencje wykraczają jednak daleko poza same aktywa. Dochodzi konieczność zatrzymania lub ograniczenia działania platformy, przeprowadzenia analizy śledczej, współpracy z partnerami technologicznymi i organami ścigania oraz wdrożenia pilnych zmian architektonicznych. Równie istotny jest koszt reputacyjny, ponieważ użytkownicy zaczynają kwestionować bezpieczeństwo całego modelu działania serwisu.

Dla sektora finansowego i kryptowalutowego to kolejny sygnał, iż zależności frontendowe muszą być traktowane jako pełnoprawna powierzchnia ataku. Każdy skrypt third-party uruchamiany w krytycznej części aplikacji może w praktyce uzyskać zdolność inicjowania operacji o wysokim wpływie biznesowym.

Rekomendacje

Organizacje utrzymujące aplikacje finansowe powinny przede wszystkim ograniczyć liczbę zewnętrznych skryptów ładowanych w sekcjach odpowiedzialnych za logowanie, handel, portfele i zarządzanie aktywami. Funkcje marketingowe, analityczne i telemetryczne powinny być separowane od interfejsów realizujących działania wysokiego ryzyka.

• wdrożenie restrykcyjnej polityki Content Security Policy,
• stosowanie mechanizmów Subresource Integrity tam, gdzie jest to możliwe,
• pełna inwentaryzacja skryptów third-party oraz ich zależności,
• monitorowanie zmian hashy, domen źródłowych i zachowania runtime,
• detekcja anomalii obejmująca nietypowe sekwencje sprzedaży i transferów,
• wymuszanie dodatkowej autoryzacji dla operacji wysokiego ryzyka,
• skracanie czasu życia sesji uprzywilejowanych,
• przygotowanie procedur awaryjnego odłączania komponentów zewnętrznych w produkcji.

Po stronie użytkowników rozsądnym krokiem jest korzystanie z oddzielnych profili przeglądarki do operacji finansowych, bieżące monitorowanie aktywności portfeli oraz szybkie wylogowanie po zauważeniu nietypowego zachowania interfejsu. Zespoły SOC powinny natomiast regularnie ćwiczyć scenariusze kompromitacji dostawcy JavaScript, ponieważ czas reakcji w takim incydencie może decydować o skali strat.

Podsumowanie

Atak supply chain na Polymarket stanowi mocny przykład tego, jak groźna może być kompromitacja pojedynczego elementu zewnętrznego w aplikacji obsługującej aktywa finansowe. Najważniejszą cechą tego przypadku było wykorzystanie zaufanego skryptu do przejęcia możliwości aktywnych, już uwierzytelnionych sesji użytkowników.

Wniosek dla branży jest jednoznaczny: ochrona infrastruktury serwerowej nie wystarcza, jeżeli aplikacja dopuszcza wykonywanie niekontrolowanego kodu zewnętrznego w przeglądarce. Bezpieczeństwo łańcucha dostaw JavaScript powinno być traktowane jako krytyczny element architektury, porównywalny z ochroną systemów transakcyjnych i kont uprzywilejowanych.

Źródła

1. 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/
2. Polymarket Status Page – Incident updates – https://status.polymarket.com/
3. DebugBear – Security incident statement – https://www.debugbear.com/
4. Hudson Rock – Analysis of the malicious JavaScript sample – https://www.infostealers.com/
5. GoPlus Security – On-chain analysis and attribution notes – https://gopluslabs.io/