Roczny atak na portale Salesforce i ServiceNow

Nieznany atakujący przez blisko rok miał nieautoryzowany dostęp do portali Salesforce i ServiceNow.

To nie wygląda jak jednorazowy incydent, tylko długie i ciche działanie w obszarze logowania oraz utrzymania sesji. Dla zespołów pracujących na Salesforce to prosty sygnał: sam fakt, że platforma jest centralna dla biznesu, robi z niej atrakcyjny cel.

Atak szedł przez uwierzytelnianie i sesje

Napastnik wykorzystał słabości w mechanizmach authentication i session management. To właśnie ten łańcuch błędów pozwolił ominąć standardowe zabezpieczenia i utrzymać dostęp przez długi czas bez szybkiego wykrycia. Najgroźniejsze w tym scenariuszu nie jest samo wejście, ale to, że intruz potrafił działać po cichu i regularnie wyciągać dane.

W praktyce to przypomnienie, że ochrona loginu nie kończy tematu. Równie ważne jest to, jak portal utrzymuje sesję użytkownika, jak łatwo ją przejąć i czy nietypowe zachowania są w ogóle widoczne dla zespołu. Przy podobnych incydentach problemem bywa nie jeden wielki błąd, tylko kilka mniejszych, które razem dają pełny dostęp.

Dlaczego Salesforce i ServiceNow są tak łakomym celem

Obie platformy siedzą w środku operacji firmy. Trzymają dane klientów, informacje wrażliwe biznesowo i wiedzę o procesach operacyjnych. To wystarczy, żeby atak miał wysoki zwrot dla przestępcy nawet bez głośnego ransomware czy natychmiastowego sabotażu.

Skutki takiego wejścia mogą obejmować ekspozycję poufnych informacji klientów, danych biznesowych i wiedzy o tym, jak działa organizacja. Dlatego po wykryciu incydentu zapowiedziano szerokie audyty bezpieczeństwa i dodatkowe środki ochronne. Dla admina albo architekta ważny wniosek jest prosty: centralny portal to nie tylko wygoda dla użytkownika, ale też bardzo szeroka powierzchnia ataku.

Jeśli temat monitoringu i reakcji na anomalię jest u was odkładany, warto wrócić do podejścia opartego na zdarzeniach i widoczności operacji. Dobrym uzupełnieniem jest tekst o monitoringu danych w czasie rzeczywistym, bo bez tego podobne incydenty potrafią wisieć miesiącami.

Jak to wpływa na nas

Na polskim rynku dużo wdrożeń opiera się na portalach, doświadczeniach self-service i integracjach, które mają działać bez tarcia dla użytkownika. Właśnie tam najłatwiej przesunąć akcent za mocno w stronę wygody, a za słabo w stronę kontroli dostępu i obserwowalności. Problem nie dotyczy tylko wielkich orgów. Dotyczy każdego środowiska, gdzie portal otwiera drogę do danych klienta albo procesów service.

Dla partnerów i zespołów in-house oznacza to też zmianę rozmowy z biznesem. Bezpieczeństwo nie może być dopięte na końcu jako checklista przed go-live. Trzeba je rozpisywać już na etapie projektu logowania, sesji, uprawnień i obsługi wyjątków. W tym kontekście wraca też stary temat porządkowania dostępów – przydaje się podejście opisane w materiale o Permission Sets i Profiles, bo nadmiarowe uprawnienia zawsze podnoszą koszt incydentu.

Co zrobić teraz

Najrozsądniejszy ruch to przegląd konfiguracji bezpieczeństwa, wdrożenie zalecanych poprawek i wzmocnienie identity management. Nie chodzi tylko o hasła czy MFA, ale o cały przepływ logowania i utrzymania sesji. Jeśli portal jest krytyczny, potraktuj go jak system o podwyższonym ryzyku. Sprawdź, co widać w logach, jak szybko wykryjesz nietypowy dostęp i czy użytkownik po przejętej sesji może dojść za daleko.