Wprowadzenie do problemu / definicja
Atak typu supply chain na komponent webowy polega na kompromitacji zaufanego zasobu dostarczanego przez zewnętrznego dostawcę, a nie na bezpośrednim ataku na pojedynczą aplikację. W opisanym incydencie celem był AppsFlyer Web SDK, czyli skrypt wykorzystywany przez wiele serwisów do analityki marketingowej i atrybucji zdarzeń.
Skutkiem kompromitacji było czasowe dostarczanie złośliwego kodu JavaScript, który monitorował interakcje użytkownika ze stroną i podmieniał adresy portfeli kryptowalut na wartości kontrolowane przez napastników. To pokazuje, jak niebezpieczne mogą być zewnętrzne zależności wykonywane bezpośrednio w przeglądarce.
W skrócie
Incydent objął webową wersję SDK AppsFlyer i polegał na dystrybucji złośliwego JavaScriptu z oficjalnej domeny powiązanej z komponentem. Dzięki temu ładunek wyglądał wiarygodnie i mógł zostać wykonany w kontekście legalnych witryn korzystających z tego rozwiązania.
Według dostępnych ustaleń skrypt przechwytywał adresy portfeli kryptowalut wpisywane przez użytkowników, a następnie zastępował je adresami należącymi do atakującego. Producent potwierdził incydent związany z problemem po stronie rejestratora domeny, zaznaczając jednocześnie, iż mobilne SDK nie zostało nim objęte, a zagrożenie zostało opanowane.
Kontekst / historia
AppsFlyer jest szeroko znanym dostawcą narzędzi do analityki, atrybucji i pomiaru efektywności kampanii marketingowych. Tego typu rozwiązania są często wdrażane jako zewnętrzne skrypty ładowane bezpośrednio do aplikacji webowych, przez co stają się elementem łańcucha zaufania pomiędzy dostawcą, właścicielem serwisu i użytkownikiem końcowym.
Z dostępnych informacji wynika, iż złośliwy kod mógł być serwowany co najmniej od 9 marca 2026 roku do 11 marca 2026 roku. Producent wskazał, iż problem został wykryty 10 marca 2026 roku i wiązał się z incydentem po stronie rejestratora domeny. Choć okno ekspozycji było ograniczone czasowo, potencjalny zasięg zdarzenia mógł być szeroki ze względu na liczbę stron wykorzystujących Web SDK.
Analiza techniczna
Technicznie atak był szczególnie groźny, ponieważ złośliwy kod nie wyłączał podstawowej funkcjonalności SDK. Komponent przez cały czas realizował zadania analityczne, a szkodliwe działanie odbywało się w tle, co ograniczało szanse na szybkie wykrycie anomalii przez administratorów lub użytkowników.
Według opisów analiz złośliwy JavaScript wykorzystywał mechanizmy zaciemniania kodu i dekodowania ciągów w czasie wykonania. Tego rodzaju techniki utrudniają analizę statyczną i osłabiają skuteczność prostych reguł detekcyjnych opartych na sygnaturach.
Kluczowy mechanizm polegał na monitorowaniu pól wejściowych i aktywności związanej z operacjami kryptowalutowymi. Po wykryciu wzorca odpowiadającego adresowi portfela skrypt mógł przechwycić oryginalną wartość, przesłać ją wraz z dodatkowymi metadanymi do infrastruktury napastnika, a następnie podmienić ją na inny adres. W analizach wskazywano na zainteresowanie popularnymi ekosystemami, takimi jak Bitcoin, Ethereum, Solana, Ripple i TRON.
W praktyce oznacza to, iż użytkownik mógł wykonywać operację w pełnym przekonaniu, iż korzysta z legalnej strony i prawidłowego formularza, podczas gdy krytyczna wartość transakcji została już zmieniona po stronie klienta. To klasyczny przykład zagrożenia wynikającego z wykonywania zaufanego, ale skompromitowanego kodu third-party.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją incydentu była możliwość przekierowania środków kryptowalutowych do portfeli kontrolowanych przez atakujących. Dotyczy to zwłaszcza serwisów, które pozwalają użytkownikowi manualnie wpisywać, kopiować lub zatwierdzać adres odbiorcy w interfejsie webowym.
Ryzyko dla organizacji nie ogranicza się jednak do bezpośrednich strat finansowych klientów. Kompromitacja zewnętrznego SDK oznacza utratę integralności kodu uruchamianego w przeglądarce, możliwość wystąpienia szkód wizerunkowych oraz trudności z jednoznacznym oszacowaniem skali incydentu. Ponieważ atak działa po stronie klienta, standardowe logi backendowe mogą nie dostarczyć pełnego obrazu zdarzenia.
Dodatkowe skutki mogą obejmować wzrost liczby reklamacji, konieczność przeglądu telemetrii przeglądarkowej, pilną komunikację z użytkownikami oraz audyt wszystkich ścieżek biznesowych zależnych od skryptów zewnętrznych. W środowiskach związanych z płatnościami i aktywami cyfrowymi taki incydent należy traktować jako krytyczny.
Rekomendacje
Organizacje korzystające z zewnętrznych SDK webowych powinny ograniczać zaufanie do kodu dostarczanego przez strony trzecie. najważniejsze znaczenie ma pełna inwentaryzacja wszystkich skryptów ładowanych zewnętrznie oraz ocena ich wpływu na bezpieczeństwo i procesy biznesowe.
W przypadku tego incydentu warto przeanalizować logi i telemetrię z okresu od 9 do 11 marca 2026 roku, zwłaszcza pod kątem nietypowych żądań inicjowanych przez komponent Web SDK, anomalii w formularzach kryptowalutowych oraz zgłoszeń użytkowników dotyczących nieprawidłowych adresów odbiorczych.
- zamrozić i zweryfikować wersje zewnętrznych bibliotek JavaScript;
- stosować mechanizmy Subresource Integrity tam, gdzie to możliwe;
- ograniczać użycie skryptów third-party w krytycznych ścieżkach transakcyjnych;
- wdrożyć rygorystyczną politykę Content Security Policy;
- monitorować zmiany w odpowiedziach dostawców CDN i domen SDK;
- oddzielić funkcje analityczne od formularzy związanych z płatnościami i kryptowalutami;
- weryfikować integralność krytycznych danych po stronie serwera;
- przygotować procedury szybkiego odłączenia zewnętrznego komponentu w razie incydentu.
W środowiskach wysokiego ryzyka warto również rozważyć samodzielne hostowanie wybranych zależności, jeżeli pozwala na to model operacyjny i licencyjny, oraz objęcie skryptów webowych kontrolą zmian zbliżoną do tej stosowanej dla własnego kodu aplikacyjnego.
Podsumowanie
Incydent związany z AppsFlyer Web SDK pokazuje, iż ataki supply chain po stronie przeglądarki pozostają jednym z najtrudniejszych do wykrycia zagrożeń dla nowoczesnych aplikacji internetowych. W tym przypadku kompromitacja zaufanego komponentu analitycznego umożliwiła podmianę adresów portfeli kryptowalut bez konieczności atakowania każdej ofiary indywidualnie.
To ważne ostrzeżenie dla zespołów bezpieczeństwa, iż ochrona aplikacji webowej nie może ograniczać się wyłącznie do własnego backendu i frontendowego kodu biznesowego. Równie istotna jest kontrola całego ekosystemu zależności, szczególnie tych, które działają w przeglądarce użytkownika i mają dostęp do wrażliwych procesów.
Źródła
- https://www.bleepingcomputer.com/news/security/appsflyer-web-sdk-used-to-spread-crypto-stealer-javascript-code/
- https://www.appsflyer.com/company/newsroom/pr/company-update-february-2025/
- https://support.appsflyer.com/hc/en-us/articles/39145848948625–Beta-Advanced-Security-Protect360-Module
