SAP NetWeaver (CVE-2025-31324): webshell bez logowania

Systemy SAP to cyfrowe serce największych organizacji: finanse, produkcja, łańcuch dostaw, dane kadrowe — wszystko w jednym miejscu. Właśnie dlatego luka CVE-2025-31324 w komponencie SAP NetWeaver Visual Composer, ujawniona wiosną 2025, była tak groźna. Z oceną CVSS 10.0 (maksymalną) pozwalała wgrać na serwer dowolny plik bez żadnego uwierzytelnienia — w praktyce webshell dający pełną kontrolę nad systemem trzymającym najcenniejsze procesy firmy. I, jak to bywa z krytycznymi lukami w systemach wystawionych do sieci, trafiła do aktywnej eksploatacji, zanim wiele firm zdążyło ją załatać.

Na czym polegała luka

Problemem był brak kontroli dostępu do jednego z endpointów uploadu w Visual Composerze (/developmentserver/metadatauploader). Napastnik mógł wysłać żądanie i wgrać plik wykonywalny (np. JSP webshell) do katalogu obsługiwanego przez serwer aplikacyjny — bez logowania, bez tokenu, bez niczego. Po wgraniu wystarczyło otworzyć podrzucony plik w przeglądarce, by uruchomić polecenia na serwerze z uprawnieniami usługi SAP.

Prostota tego łańcucha (upload → wykonanie) uczyniła go idealnym do masowego, zautomatyzowanego wykorzystania. W eksploatację zaangażowały się zarówno grupy szpiegowskie, jak i operatorzy ransomware — powtarzalny wzorzec: krytyczny 0-day w systemie o wysokiej wartości najpierw służy cichej penetracji, potem wymuszeniu.

Dlaczego SAP to cel wyjątkowy

Bezpieczeństwo SAP przez lata żyło w cieniu, bo systemy te bywają traktowane jak „wewnętrzne, więc bezpieczne”. W praktyce wiele instancji SAP jest — świadomie lub przez zapomnienie — częściowo osiągalnych z internetu (portale, integracje, komponenty webowe). A stawka jest najwyższa: przejęcie SAP to dostęp do ksiąg finansowych, danych osobowych pracowników, procesów produkcyjnych i płatności. To nie „jeszcze jeden serwer” — to system, którego kompromitacja dotyka jednocześnie poufności, integralności i ciągłości działania.

Do tego dochodzi specyfika utrzymania: systemy SAP są krytyczne i złożone, więc okna serwisowe bywają rzadkie, a łatanie — ostrożne i powolne. Ta sama cecha, która czyni je stabilnymi, opóźnia reakcję na krytyczne luki. Napastnicy o tym wiedzą.

Obrona: co zrobić z krytycznym SAP

Załataj i sprawdź obejścia. SAP wydał pilną poprawkę poza normalnym cyklem, a wkrótce kolejną, domykającą powiązany wektor (CVE-2025-42999). Instalacja obu jest konieczna — to ta sama lekcja „łatka bywa obchodzona”, co przy ToolShell.

Zakładaj kompromitację, jeśli byłeś wystawiony. Przy luce w masowej eksploatacji sprawdź, czy w katalogach serwera nie ma podrzuconych plików (webshelli), przejrzyj logi endpointu uploadu i nietypowe procesy potomne serwera aplikacyjnego. To klasyczne threat hunting — łatka nie usuwa webshella, który już tam jest.

Zdejmij SAP z internetu. Komponenty webowe SAP (zwłaszcza Visual Composer, jeśli nieużywany) nie powinny być osiągalne publicznie. Dostęp tylko przez VPN z MFA, segmentacja, ograniczenie ekspozycji do niezbędnego minimum.

Włącz SAP w proces bezpieczeństwa. SAP zbyt często stoi poza standardowym zarządzaniem podatnościami i testami. Powinien być inwentaryzowany, skanowany i objęty monitoringiem jak każdy inny krytyczny system — a przy jego wartości raczej bardziej niż mniej.

Najczęstsze pytania (FAQ)

Nasz SAP jest „wewnętrzny”, niedostępny z internetu. Czy byliśmy bezpieczni? Warto to zweryfikować, a nie zakładać. Wiele instancji ma częściowo wystawione komponenty webowe lub integracje, o których zespół nie pamięta. Nawet jeśli SAP faktycznie jest tylko wewnętrzny — atakujący, który wszedł do sieci inną drogą, wykorzysta tę lukę do przejęcia najcenniejszego systemu (ruch boczny).

Nie używamy Visual Composera. Czy luka nas dotyczyła? Podatny był komponent, który bywa zainstalowany i włączony domyślnie, nawet jeśli go aktywnie nie używacie. Dlatego samo „nie korzystamy” nie wystarcza — trzeba sprawdzić, czy komponent jest obecny i osiągalny, oraz zastosować poprawki lub wyłączyć nieużywane moduły.

Jak sprawdzić, czy ktoś wgrał webshell? Przeszukaj katalogi serwera aplikacyjnego pod kątem nieoczekiwanych plików (JSP i podobnych) z datami z okna ekspozycji, przejrzyj logi dostępu do endpointu uploadu oraz procesy uruchamiane przez usługę SAP. Znalezione ślady traktuj jako aktywny incydent.

Dlaczego łatanie SAP jest takie trudne? Bo to systemy krytyczne, złożone i zwykle silnie dostosowane — każda zmiana wymaga testów i okna serwisowego. To realne wyzwanie, ale przy luce CVSS 10.0 w masowej eksploatacji priorytet musi przeważyć nad wygodą; alternatywą jest przejęcie serca firmy.

Jak podejść do bezpieczeństwa SAP kompleksowo? Traktując go jak system krytyczny w pełnym procesie: inwentaryzacja i minimalizacja ekspozycji, regularne łatanie, monitoring, kontrola dostępu i okresowe testy bezpieczeństwa. Chętnie pomożemy ocenić ekspozycję Twojego SAP i wpiąć go w proces — odezwij się.

Podsumowanie

CVE-2025-31324 przypomniał, że najgroźniejsze luki to te w systemach o najwyższej wartości — a SAP, mimo reputacji „wewnętrznego”, bywa wystawiony i rzadko łatany na czas. Obrona to szybka poprawka (wraz z domknięciem powiązanego wektora), aktywne poszukiwanie webshelli, zdjęcie komponentów z internetu i wpięcie SAP w normalny proces bezpieczeństwa. Jeśli SAP trzyma serce Twojej firmy, upewnij się, że nie stoi poza Twoim programem ochrony.

Źródła i dalsza lektura: SAP Security Notes, CISA KEV, Sekurak.