Nie było luki

Przez ostatnie tygodnie opisywaliśmy ataki mierzone w minutach. Czterdzieści minut, przez które w rejestrze wisiały zatrute pakiety i zebrano sekrety z czterystu trzydziestu tysięcy instancji. Dziesięć godzin i dwadzieścia pięć dolarów za pełny łańcuch do wykonania kodu w rdzeniu WordPressa. Cztery i pół dnia, w które agent wykonał siedemnaście tysięcy sześćset działań.

12 sierpnia firma Reco opisała kampanię, która trwa siedemnaście miesięcy. Prowadzona jest z jednego serwera. Nie wykorzystuje żadnej podatności.

I prawdopodobnie wyniosła więcej danych niż niejedna z tamtych.

Konto, którego nie można usunąć

Mechanizm jest strukturalny i to czyni go interesującym.

Każda witryna Salesforce Experience Cloud ma własnego użytkownika-gościa. To nie jest abstrakcja ani tryb działania — to prawdziwe, trwałe konto z profilem i uprawnieniami, w którego kontekście wykonuje się każde żądanie od osoby niezalogowanej. Gdy ktoś obcy otwiera twój portal wsparcia albo bazę wiedzy, przegląda je właśnie jako to konto. Każda instancja ServiceNow ma swój odpowiednik.

I teraz rzecz kluczowa: tego konta nie da się usunąć. Wymuszenie logowania go nie likwiduje — profil, uprawnienia, reguły udostępniania i cały kod działający w jego kontekście istnieją dalej. Reco formułuje z tego zasadę, którą warto zapamiętać w tej postaci: jeśli gość może odczytać rekord, może go odczytać każdy w internecie.

To znaczy, że mówimy o czymś innym niż podatność. Podatność jest błędem, który da się naprawić. Użytkownik-gość jest elementem konstrukcji, który można wyłącznie ograniczyć — a jego domyślne uprawnienia ktoś kiedyś skonfigurował, zwykle dawno, zwykle nie do końca świadomie.

Badacz Reco, Nitay Bachrach, ujmuje sedno jednym zdaniem: podstawowym problemem jest to, że „co jest publiczne" i „co powinno być publiczne" to dwie różne rzeczy — i dokładnie to atakujący wykorzystał.

Siedemnaście miesięcy z jednego adresu

Kampania nazwana City-Forum, od domeny, na którą rozwiązuje się adres napastnika, działa z infrastruktury stojącej od marca 2025 roku. Ruch idzie konsekwentnie z tego samego adresu, z jednym rozpoznawalnym identyfikatorem klienta HTTP. Najbardziej obciążony pojedynczy cel odnotował ponad 560 tysięcy zdarzeń.

Wśród celów: firmy telekomunikacyjne, banki i instytucje finansowe, dostawcy oprogramowania korporacyjnego — w tym, co warto odnotować, firmy zajmujące się bezpieczeństwem i ochroną prywatności — oraz portale sektora publicznego.

To jest ten sam motyw, który wracał przy włamaniu do Klue, gdzie połowa ofiar zawodowo chroniła innych przed dokładnie tym, co je spotkało. Konfiguracja portalu klienckiego jest tą częścią infrastruktury, którą zajmuje się dział marketingu albo obsługi, a nie zespół bezpieczeństwa — i to obowiązuje także w firmach bezpieczeństwa.

Zbudowali własne narzędzie, choć nie musieli

Element, który odróżnia tę kampanię od zwykłego skanowania, to jej techniczna staranność.

Nadużywanie zbyt szeroko uprawnionego gościa w starszym frameworku Salesforce jest znanym problemem od lat i istnieją do tego gotowe, publicznie dostępne narzędzia. Atakujący mogli ich użyć. Zbudowali własne — obejmujące jednym zestawem dwie platformy naraz.

I skierowali je w dwa miejsca, których nikt wcześniej nie ruszał.

Pierwszym jest warstwa danych za nowszym frameworkiem witryn Salesforce, którą istniejące narzędzia ofensywne całkowicie pomijają. Reco nazywa to ofensywnym ślepym polem — i jest to, według badaczy, pierwsze zaobserwowane wykorzystanie tej powierzchni w realnym ataku.

Drugim jest endpoint wyszukiwania w portalu ServiceNow, tak słabo udokumentowany, że producent nie publikuje do niego żadnej referencji, a w obiegu nie ma znanych narzędzi otwartoźródłowych, które by go dotykały.

Warto zauważyć, co to znaczy praktycznie. Obrona przed nadużyciem gościa opiera się w wielu organizacjach na sprawdzeniu, czy nie jesteśmy podatni na to, co robią publicznie dostępne narzędzia. Ten atakujący celowo wyszedł poza ten zakres — i dlatego przez siedemnaście miesięcy nie było powodu, żeby cokolwiek zauważyć.

Pułapka dwóch przełączników

Jest w ustaleniach Reco jeden szczegół konfiguracyjny, który tłumaczy skalę tej kampanii lepiej niż cokolwiek innego, i który warto podać wprost.

Ustawienie mówiące, że goście mogą widzieć witrynę i korzystać z niej bez logowania, kontroluje widoczność stron — to, co niezalogowany zobaczy w przeglądarce. Nie kontroluje powierzchni API. Za to odpowiada osobne ustawienie, dotyczące dostępu gości do publicznych interfejsów programistycznych.

Konsekwencja jest niewygodna: zaostrzenie widoczności stron nie zamyka API. Administrator, który przejrzał portal, upewnił się, że anonimowy użytkownik nie widzi wrażliwych podstron, i uznał sprawę za zamkniętą, wciąż może mieć otwartą warstwę danych — bo to dwa różne przełączniki, a tylko jeden wygląda jak ten właściwy.

Po stronie ServiceNow jest analogicznie: endpoint wyszukiwania jest publiczny z założenia, więc utwardzanie go nie ma sensu. Sens ma pytanie o to, co za nim stoi — które źródła danych portal udostępnia gościowi i czy te źródła same egzekwują kontrolę dostępu.

To jest ten sam kształt problemu, który opisywaliśmy przy polskiej elektrociepłowni, gdzie prywatny APN okazał się siecią płaską w środku. Granica istniała dokładnie tam, gdzie ją narysowano. Tylko wewnątrz niej nie było już żadnej.

Uczciwie: co to jest, a czego nie

Kilka rzeczy trzeba postawić proporcjonalnie.

To nie jest podatność w Salesforce ani w ServiceNow i nie ma tu nic do załatania po stronie producentów. Obie platformy działają zgodnie z dokumentacją, a użytkownik-gość jest funkcją, nie błędem. Odpowiedzialność leży po stronie konfiguracji — co nie znaczy, że po stronie winy, bo domyślne ustawienia i rozdzielenie dwóch przełączników robią tu połowę roboty za atakującego.

Ustalenia pochodzą od jednej firmy, która sprzedaje monitoring postawy bezpieczeństwa środowisk SaaS, i tak też opisuje swoje rozwiązanie w materiale źródłowym. To standardowe zastrzeżenie przy badaniach producenckich. Z drugiej strony wskaźniki kompromitacji są konkretne i weryfikowalne, a sam mechanizm jest sprawdzalny w każdej organizacji niezależnie od tego, czyje narzędzie się do tego użyje.

Nie wiemy, ile organizacji realnie ucierpiało ani jakiego rodzaju dane wyszły. Wiadomo, jakie obiekty były enumerowane, ale zakres ekspozycji jest u każdej ofiary inny, bo zależy wyłącznie od jej własnej konfiguracji. Nie ma też publicznego przypisania kampanii do konkretnego aktora.

Co z tego wynika dla obrońcy

Rzecz pierwsza jest do zrobienia od ręki i nie wymaga żadnego narzędzia: sprawdź, jakie obiekty i pola widzi użytkownik-gość w twoich witrynach Experience Cloud oraz co jest dostępne dla gościa w portalach ServiceNow. Nie przez otwarcie portalu w przeglądarce, tylko przez przejrzenie profilu, reguł udostępniania i dostępu do obiektów.

Rzecz druga wynika z pułapki dwóch przełączników i jest najważniejsza. Sprawdź ustawienie dostępu gości do publicznych API osobno od widoczności stron. To pierwsze jest tym, które realnie otwiera warstwę danych, i to ono decyduje o ekspozycji niezależnie od tego, jak wygląda sam portal.

Rzecz trzecia dotyczy wykrywania. Ruch w tej kampanii szedł konsekwentnie z jednego adresu, z jednym charakterystycznym identyfikatorem klienta HTTP i w wolumenie, który przy jednym celu przekroczył pół miliona zdarzeń. To jest wykrywalne — pod warunkiem, że ktokolwiek patrzy na logi dostępu gościa. W większości organizacji nikt na nie nie patrzy, bo to ruch anonimowy, czyli z definicji nudny.

Rzecz czwarta jest inwentaryzacyjna. Portale klienckie, bazy wiedzy i formularze zgłoszeniowe zwykle powstają poza działem bezpieczeństwa i rzadko trafiają do rejestru zasobów. Warto sprawdzić, ile takich witryn twoja organizacja w ogóle ma — bo obrona zaczyna się od wiedzy o ich istnieniu, a portal postawiony trzy lata temu na kampanię marketingową wciąż ma swojego gościa.

Jedna myśl na koniec

Przywykliśmy myśleć o bezpieczeństwie w kategoriach tego, co zepsute: luka, exploit, łatka, okno reakcji. Cała nasza infrastruktura obronna — od skanerów po katalogi eksploatowanych podatności — jest zbudowana wokół założenia, że ktoś musiał coś złamać.

City-Forum nie złamał niczego. Przez siedemnaście miesięcy odczytywał dane, które właściciele portali sami udostępnili anonimowym użytkownikom, przez konto, którego nie da się usunąć, korzystając z interfejsów działających dokładnie tak, jak zaprojektowano. Nie ma tu numeru CVE, nie ma wpisu w żadnym katalogu, nie ma łatki do nałożenia i nie było momentu, w którym cokolwiek wyglądało źle.

Jest tylko różnica między tym, co jest publiczne, a tym, co powinno być publiczne — i siedemnaście miesięcy, w które nikt jej nie sprawdził.

Źródła

Reco — oryginalna analiza kampanii City-Forum z opisem mechanizmu użytkownika-gościa w obu platformach, rozróżnieniem między ustawieniem widoczności stron a dostępem do publicznych API, wskazaniem endpointu wyszukiwania ServiceNow jako publicznego z założenia oraz wskaźnikami kompromitacji: https://www.reco.ai/blog/city-forum-campaign-salesforce-servicenow

Help Net Security — omówienie kampanii z cytatem badacza o różnicy między tym, co jest publiczne, a tym, co powinno być publiczne, danymi o skali ruchu wobec najbardziej obciążonego celu oraz opisem obu nietypowych powierzchni ataku: https://www.helpnetsecurity.com/2026/08/12/salesforce-servicenow-guest-user-exposure/

SecurityWeek — relacja z opisem profilu ofiar, informacją o pierwszym zaobserwowanym wykorzystaniu tej powierzchni w realnym ataku oraz o zintegrowaniu obu wektorów w jednym, autorskim zestawie narzędzi: https://www.securityweek.com/stealthy-city-forum-attacks-target-salesforce-and-servicenow-with-custom-toolset/

The Hacker News — potwierdzenie okresu działania infrastruktury od marca 2025, wskaźników sieciowych kampanii oraz braku publicznych narzędzi i opracowań dotyczących wykorzystanych powierzchni: https://thehackernews.com/2026/08/threatsday-ghostjacking-ai-attacks.html