Najbardziej zdradliwy malware na stronie nie zawsze rozwala stronę. Czasem produkt się wyświetla, koszyk działa, klient może zapłacić i nikt nie widzi czerwonego komunikatu. Problem dzieje się w tle, już w przeglądarce użytkownika.

Cloudflare opisał cztery takie kampanie. Jedna przechwytywała kliknięcia i kierowała je przez link afiliacyjny. Druga generowała afiliacyjne żądanie bez kliknięcia użytkownika. Trzecia dawała możliwość pobierania i wykonywania dodatkowego JavaScriptu z serwera atakującego. Czwarta uruchamiała się tylko dla wybranych użytkowników mobilnych z płatnych kampanii i próbowała wyłączać narzędzia analityczne oraz wsparcie.

Dlaczego zwykły skan może tego nie zobaczyć?

Wspólny motyw tych operacji nie polegał na jednej sygnaturze czy jednym sposobie ukrywania kodu. Skrypty potrafiły sprawdzać urządzenie, kraj, godzinę, źródło wejścia, parametry kampanii, stan przeglądarki albo sieć użytkownika i uruchamiać właściwe zachowanie dopiero wtedy, gdy pasował konkretny zestaw warunków.

WebsiteGarage / Usługi

Sprawdź nasze usługi.

To oznacza, że osoba sprawdzająca sklep z laptopa w biurze może zobaczyć zupełnie inny kod w działaniu niż klient wchodzący z reklamy na telefonie. Jedna z opisanych kampanii miała nawet listę 325 fragmentów adresów IP i pozostawała nieaktywna w wybranych sieciach, żeby trudniej było ją złapać podczas analizy.

Właśnie dlatego statyczne pytanie “czy ten plik jest znany jako złośliwy?” nie zawsze wystarcza. Cloudflare podaje, że po wykryciu kampanii siedem z ośmiu payloadów nie figurowało w VirusTotal, a URLScan nie oznaczył żadnego z ośmiu jako złośliwy.

Pierwsza kampania nie kradła karty. Kradła zasługę za sprzedaż

W jednym z przypadków złośliwy skrypt czekał na odpowiedni moment i przechwytywał kliknięcie użytkownika mobilnego. Klient nadal widział sklep, ale ruch był przepuszczany przez przygotowaną przez atakującego ścieżkę afiliacyjną.

Efektem mogła być błędna atrybucja sprzedaży i prowizja przypisana komuś, kto klienta wcale nie pozyskał. To bardzo dobry przykład, dlaczego “incydent bezpieczeństwa” nie zawsze oznacza wyciek haseł albo numerów kart. Czasem atak uderza bezpośrednio w ekonomię marketingu i dane, na których firma ocenia skuteczność kampanii.

Cloudflare ostrożnie rozdziela przy tym możliwości kodu od potwierdzonych skutków. W drugim wariancie skrypt potrafił wygenerować ukryte żądanie afiliacyjne bez kliknięcia użytkownika, ale badacze nie potwierdzili, czy konkretne żądania rzeczywiście zakończyły się wypłatą prowizji.

Łańcuch marketingowy też jest częścią powierzchni ataku

W jednej z operacji droga do przeglądarki prowadziła przez łańcuch skryptów używanych do marketingu: Google Tag Manager ładował kolejny tag manager, a ten złośliwy skrypt. Cloudflare wyraźnie zaznacza, że nie jest to dowód kompromitacji samych tag managerów. Pokazuje natomiast, jak łatwo wraz z kolejnymi narzędziami marketingowymi rośnie liczba miejsc, z których strona pobiera kod.

To ważne, bo właściciel sklepu zwykle myśli o bezpieczeństwie serwera, WordPressa, konta administratora i aktualizacji wtyczek. Tymczasem klient wykonuje także JavaScript pochodzący z analityki, reklam, czatów, widgetów i innych usług. Jeśli któraś warstwa łańcucha zaczyna dostarczać coś, czego właściciel nie autoryzował, sam serwer może nadal wyglądać zupełnie normalnie.

Najciekawszy przypadek: sklep z aktywnym tylnym wejściem w przeglądarce

Trzecia operacja wykorzystywała kod znany wcześniej z przekierowywania wyszukiwań. Na sklepie stare moduły pozostały w dużej części uśpione, ale aktywna gałąź wysyłała telemetrię i mogła pobierać zdalny JavaScript.

W praktyce oznaczało to możliwość zmiany zachowania ataku bez ponownego modyfikowania plików sklepu. Cloudflare nie ustalił, jakie payloady drugiego etapu były rzeczywiście serwowane, więc nie ma podstaw, by dopisywać historię o kradzieży danych, której badacze nie potwierdzili. Potwierdzona była natomiast możliwość zdalnego pobierania i uruchamiania kodu w przeglądarce klientów.

Czwarta kampania polowała właśnie na ruch, za który sklep już zapłacił

Inny skrypt uruchamiał się dla wybranych wizyt mobilnych oznaczonych parametrami kampanii. Próbował wyłączać analitykę i narzędzia monitorujące, ukrywał czat i formularz kontaktowy, a jednocześnie ładował zastępcze mechanizmy śledzenia.

Cloudflare potwierdził w analizie dynamicznej, że zastępczy skrypt analityczny wysłał beacon, czyli niewidoczne żądanie rejestrujące aktywność. Nie potwierdzono natomiast, czy atakujący faktycznie przejął telemetrię sesji albo przychód z reklam. Ta granica jest istotna: złośliwa możliwość i udowodniona szkoda to nie to samo.

Komentarz WebsiteGarage

Najbardziej użyteczna lekcja z tego researchu jest banalnie niewygodna: “strona działa” nie jest testem bezpieczeństwa. Nawet “checkout działa” też nim nie jest.

Wiele współczesnych stron składa się z własnego kodu plus całego wagonu zewnętrznych skryptów do reklam, analityki, czatu, A/B testów, afiliacji i automatyzacji. Każdy kolejny kawałek JavaScriptu uruchamia się po stronie klienta, czyli dokładnie tam, gdzie może zobaczyć kliknięcie, zmienić zachowanie strony albo wysłać dane gdzie indziej.

Nie wyciągałabym z tego wniosku “usuń wszystkie tagi”. To równie praktyczne jak rada “odłącz internet”. Wniosek jest inny: lista skryptów ładowanych przez sklep powinna być znana i kontrolowana, a monitoring nie może polegać wyłącznie na jednorazowym przeskanowaniu plików. Jeśli złośliwy kod budzi się tylko o określonej godzinie, na konkretnym urządzeniu albo dla ruchu z kampanii, pojedynczy skan ma po prostu sporą szansę zobaczyć grzeczną wersję strony.