Jeden atakujący od 2025 roku masowo wykrada dane z portali Salesforce i ServiceNow - Security Bez Tabu

Jeden atakujący od 2025 roku masowo wykrada dane z portali Salesforce i ServiceNow

Cybersecurity news

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa opisali długotrwałą kampanię polegającą na automatycznym pobieraniu danych z publicznie dostępnych portali opartych o Salesforce Experience Cloud oraz ServiceNow Service Portal. Sednem problemu nie jest klasyczne obejście uwierzytelniania, lecz nadużycie zbyt szerokich uprawnień przypisanych kontom gościnnym, które w wielu środowiskach mają dostęp do większej liczby rekordów, pól i wyników wyszukiwania, niż wynika to z realnych potrzeb biznesowych.

To szczególnie istotne zagrożenie dla organizacji rozwijających publiczne portale samoobsługowe. Jeżeli anonimowy użytkownik może odczytać dane przez legalnie działający interfejs aplikacji, to z perspektywy atakującego nie ma potrzeby stosowania zaawansowanych exploitów — wystarczy automatyzacja i konsekwentne pobieranie informacji.

W skrócie

  • Ta sama infrastruktura atakująca działa co najmniej od marca 2025 roku.
  • Kampania obejmuje portale Salesforce Experience Cloud oraz ServiceNow Service Portal.
  • Atak opiera się na nadużyciu uprawnień użytkowników anonimowych, a nie na przełamaniu logowania.
  • W Salesforce wykorzystywano zarówno starsze mechanizmy Aura, jak i nowsze interfejsy UI API.
  • W ServiceNow operator korzystał z natywnego endpointu wyszukiwania dostępnego dla użytkowników niezalogowanych.

Kontekst / historia

Problemy z dostępem gościnnym w ekosystemie Salesforce nie są nowe. W poprzednich latach wielokrotnie obserwowano przypadki enumeracji obiektów i przeglądania rekordów udostępnionych publicznie wskutek błędnej konfiguracji portali. Zazwyczaj jednak kampanie te koncentrowały się na pojedynczych technikach i jednym środowisku.

Obecnie opisana aktywność wyróżnia się znacznie większą dojrzałością operacyjną. Atakujący nie ogranicza się do jednego produktu SaaS, lecz stosuje podobną logikę pozyskiwania danych w dwóch różnych ekosystemach chmurowych. To sugeruje systematyczne rozpoznanie powierzchni ataku i świadome poszukiwanie błędów konfiguracyjnych związanych z tożsamością anonimową oraz autoryzacją dostępu do danych.

Analiza techniczna

Z udostępnionych ustaleń wynika, że aktywność była powiązana z jednym serwerem VPS, a ruch posiadał spójny fingerprint w postaci domyślnego identyfikatora klienta HTTP biblioteki Go. Taki wzorzec wskazuje na użycie własnego narzędzia do automatyzacji scrapingu, a nie ręczne działania wykonywane z poziomu przeglądarki.

W przypadku Salesforce operator wykorzystywał dwa główne podejścia. Pierwsze dotyczyło starszego modelu opartego o framework Aura, w którym możliwe było wysyłanie licznych żądań gościnnych w celu enumeracji obiektów oraz pobierania kolejnych stron rekordów. Drugie obejmowało nowsze witryny Lightning Web Runtime i warstwę UI API. Badacze zauważyli także sekwencyjne odpytywanie kolejnych wersji API, co może wskazywać na automatyczne testowanie kompatybilności oraz wyszukiwanie najbardziej użytecznych punktów dostępu.

W środowisku ServiceNow wykorzystywany był natywny endpoint wyszukiwania portalu usługowego, realizowany metodą POST. Jeżeli portal publiczny, źródła wyszukiwania lub kryteria dostępu do bazy wiedzy są skonfigurowane zbyt szeroko, odpowiedzi mogą ujawniać treści i metadane, które nie powinny być dostępne dla użytkowników anonimowych.

Kluczowy aspekt techniczny w obu platformach pozostaje taki sam: użytkownik gościnny jest trwałą tożsamością wykorzystywaną przez anonimowego odwiedzającego. Jeżeli otrzyma on prawa odczytu do określonych rekordów, dane stają się faktycznie publiczne, nawet jeśli interfejs użytkownika sprawia wrażenie ograniczonego. Atakujący nie musi więc łamać zabezpieczeń w klasycznym sensie, lecz korzysta z funkcji działających zgodnie z projektem, ale opartych o błędnie nadane uprawnienia.

Dodatkowymi sygnałami ostrzegawczymi mogą być skoki ruchu do publicznych endpointów, wzrost liczby żądań z jednego adresu IP, nietypowe wzorce user-agent, sekwencyjne odpytywanie wielu wersji API oraz ponadprzeciętna wielkość odpowiedzi zwracanych anonimowym użytkownikom.

Konsekwencje / ryzyko

Najpoważniejszym zagrożeniem jest ciche i długotrwałe ujawnianie danych bez potrzeby wykorzystania podatności typu RCE, przejęcia kont czy kampanii phishingowych. Taki scenariusz bywa trudniejszy do wykrycia, ponieważ ruch przypomina zwykłe korzystanie z aplikacji przez niezalogowanego użytkownika.

Skutki biznesowe mogą obejmować ujawnienie danych klientów, rekordów zgłoszeń, artykułów bazy wiedzy, informacji organizacyjnych, metadanych procesowych, a w niektórych przypadkach również danych regulacyjnie wrażliwych. W branżach takich jak finanse, telekomunikacja, sektor publiczny czy technologie może to prowadzić do naruszeń poufności, incydentów zgodności oraz kolejnych ataków opartych o dane zebrane podczas scrapingu.

Ryzyko rośnie wraz z rozbudową portali samoobsługowych i zwiększaniem liczby integracji SaaS. Im więcej wyjątków w politykach udostępniania, źródeł wyszukiwania, obiektów i pól, tym trudniej utrzymać zasadę najmniejszych uprawnień dla kont anonimowych.

Rekomendacje

Organizacje korzystające z Salesforce powinny rozpocząć od przeglądu profilu użytkownika gościnnego, reguł udostępniania, dostępu na poziomie obiektów i pól oraz ustawień publicznych API dla witryn Experience Cloud. Wszystkie uprawnienia niewymagane do obsługi anonimowego ruchu powinny zostać usunięte. Warto również wyłączyć samorejestrację tam, gdzie nie jest potrzebna.

Po stronie monitoringu należy analizować logi związane z dostępem gościnnym, w tym żądania do warstwy Aura, publicznych interfejsów API oraz zdarzenia związane z portalami. Szczególną uwagę powinny zwracać:

  • wysoka liczba żądań z jednego adresu źródłowego,
  • nietypowe identyfikatory user-agent,
  • sekwencyjne odpytywanie wielu wersji API,
  • nagłe wzrosty ruchu do publicznych ścieżek aplikacji.

W środowisku ServiceNow zalecany jest audyt publicznych źródeł wyszukiwania, kryteriów odczytu bazy wiedzy oraz wszystkich mechanizmów zwracających wyniki anonimowym użytkownikom. Zespoły bezpieczeństwa powinny regularnie przeglądać logi transakcyjne pod kątem zapytań do endpointów wyszukiwania, nietypowej wielkości odpowiedzi oraz obecności treści przeznaczonych wyłącznie dla użytkowników zalogowanych.

W obu platformach konieczne jest wdrożenie zasady najmniejszych uprawnień, cyklicznych testów ekspozycji danych, automatycznych kontroli konfiguracji SaaS oraz procedur walidacji zmian przed publikacją portalu. Dobrym uzupełnieniem są testy symulujące dostęp anonimowy i porównujące zwracane dane z oczekiwanym zakresem publikacji.

Podsumowanie

Opisana kampania pokazuje, że jednym z najpoważniejszych zagrożeń dla nowoczesnych platform SaaS pozostają nie tylko klasyczne podatności, ale również nadmierne uprawnienia przypisane tożsamościom anonimowym. W tym przypadku atakujący wykorzystał legalnie działające funkcje Salesforce i ServiceNow do systematycznego pobierania danych przez długi czas.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona aplikacji chmurowych musi obejmować nie tylko zarządzanie lukami, lecz także szczegółowy nadzór nad konfiguracją dostępu gościnnego, monitoring telemetrii oraz regularną weryfikację ekspozycji danych w publicznych portalach.

Źródła