Splunk opublikował ważne informacje, dotyczące szeregu nowych podatności w swoich produktach Splunk Enterprise i Splunk Cloud Platform. Luki mogą umożliwić atakującym wykonanie nieautoryzowanego kodu JavaScript, ujawnienie wrażliwych danych lub doprowadzenie do odmowy usługi (DoS). Poniżej opisujemy aspekty techniczne tych wad, omawiamy możliwe ścieżki ataku oraz przedstawiamy najlepsze praktyki minimalizacji ryzyka dla administratorów systemów wykorzystujących Splunk. Dla zespołów bezpieczeństwa – lektura obowiązkowa.

Autor: 7 min czytania

Charakterystyka wykrytych podatności

Splunk udostępnił informacje na temat sześciu głównych luk o różnym stopniu krytyczności – od medium do high – dotyczących m.in. SSRF, XSS, XXE i DoS. Poniżej szczegóły:

1. SSRF (Server-Side Request Forgery) – CVE-2025-20371

Najpoważniejsza luka to  CVE-2025-20371. W wersjach Splunk Enterprise poniżej 10.0.1, 9.4.4, 9.3.6, 9.2.8 oraz w niezałatanych instancjach Splunk Cloud atakujący, bez uwierzytelnienia, może wywołać tzw. „blind SSRF”. W praktyce umożliwia to wykonanie zapytań REST API w imieniu zalogowanego użytkownika z wysokimi uprawnieniami.

Warunkiem koniecznym jest włączenie opcji enableSplunkWebClientNetloc = true w pliku web.conf. Administratorzy mogą zredukować ryzyko przez ustawienie tej opcji na false.

2. XSS (Cross-Site Scripting) – CVE-2025-20367 / CVE-2025-20368

Dwie luki typu XSS umożliwiają atakującemu (nawet z niskimi uprawnieniami) wstrzyknięcie złośliwego kodu JavaScript:

  • CVE-2025-20367 (reflected XSS): poprzez parametr dataset.command w końcówce /app/search/table można spreparować ładunek, który zostanie wykonany w przeglądarce użytkownika.
  • CVE-2025-20368 (stored XSS): złośliwy kod można umieścić w komunikatach błędów lub w detalach inspekcji zadań w zapisie (saved search / job inspector). Kod pozostaje tam trwały i może być wykonany przy odczycie przez innego użytkownika.

Obie luki mają ocenę CVSS 5,7 (średnia) i dotyczą systemów Splunk korzystających z włączonego Splunk Web.

3. Ujawnienie informacji – CVE-2025-20366

W pewnych przypadkach użytkownik o niskich uprawnieniach (bez roli admin lub power) może uzyskać dostęp do wyników zapytania administracyjnego uruchomionego w tle, jeśli uda mu się odgadnąć unikalny identyfikator zadania (Search ID, SID). Luka oceniana jest na CVSS 6,5 (średnia) i może prowadzić do wycieku danych wewnątrz organizacji.

4. DoS i XXE – CVE-2025-20370 / CVE-2025-20369

  • CVE-2025-20370: użytkownik z uprawnieniem change_authentication może wysłać serię żądań LDAP bind do wewnętrznego punktu końcowego, co prowadzi do dużego zużycia CPU i w rezultacie DoS wymagającego restartu instancji (CVSS 4,9 – średnia).
  • CVE-2025-20369: jeśli dashboard ma etykiety zakładek (tab label) z włączonymi polami XML, możliwe jest przeprowadzenie ataku XXE (XML External Entity), co ponownie może prowadzić do DoS lub ujawnienia danych (CVSS 4,6 – średnia).

Scenariusze ataku i wymagania środowiskowe

Niektóre z podatności do wykorzystania wymagają spełnienia określonych warunków lub zastosowania kombinacji technik:

  • W przypadku SSRF (CVE-20371) atakujący musi najpierw sprowokować przeglądarkę ofiary do wykonania żądania (np. poprzez phishing, link HTML lub obrazek) – nie jest to luka „samodzielnie wykorzystywalna” z zewnętrznego hosta.
  • Przy wielu podatnościach Splunk Web musi być włączony – wyłączenie Splunk Web może zatem ograniczyć powierzchnię ataku.
  • Rola użytkownika („low-privileged user”) ma kluczowe znaczenie – to nie są luki do anonimowych ataków, lecz do użycia przy odpowiednich kontekstach autoryzacji i konfiguracji.

Ponadto Splunk opublikował aktualizacje dotyczące bibliotek zewnętrznych (third-party), takich jak libxml2, curl, protobuf-java, mongod, jackson-core itp. Wersje Splunk Enterprise nowsze niż 10.0.1, 9.4.4, 9.3.6, 9.2.8 już zawierają poprawki tych komponentów.

Rekomendacje bezpieczeństwa i kroki naprawcze

W celu zminimalizowania ryzyka administratorzy Splunk powinni podjąć następujące działania:

  1. Natychmiastowa aktualizacja
    Uaktualnij wszystkie instancje Splunk Enterprise do wersji co najmniej 10.0.1, 9.4.4, 9.3.6 lub 9.2.8 (lub nowszych). W przypadku Splunk Cloud Platform zastosuj odpowiednie poprawki wskazane przez Splunk (hotfix).
  2. Wyłączenie Splunk Web, jeśli nie jest używany
    Jeśli interfejs webowy Splunk nie jest konieczny (np. w instancjach indeksujących bez dostępu GUI), warto pamiętać, że jego wyłączenie zmniejsza powierzchnię ataku, szczególnie dla XSS, SSRF i XXE.
  3. Zmiana ustawień konfiguracyjnych
    • Ustaw enableSplunkWebClientNetloc = false w pliku web.conf, aby zapobiec potencjalnemu SSRF.
    • Przeanalizuj i ogranicz role z uprawnieniem change_authentication (używane w ataku DoS).
  4. Weryfikacja ról i uprawnień użytkowników
    Upewnij się, że użytkownicy mają przypisane tylko minimalne potrzebne uprawnienia (zasada least privilege). W szczególności usuń możliwość wykonywania operacji administracyjnych lub zmian konfiguracyjnych z ról, które nie wymagają takich uprawnień.
  5. Monitorowanie i detekcja podejrzanych aktywności
    • Monitoruj nieautoryzowane lub nietypowe użycia interfejsu REST API.
    • Śledź anomalie w żądaniach LDAP lub w zapytaniach do /app/search/table.
    • Wprowadź system alertów dla nietypowego zużycia CPU lub nagłych restartów instancji Splunk.
  6. Ocena komponentów zewnętrznych
    Zwróć uwagę na bibliotekę libxml2, curl, protobuf, mongod i inne komponenty, które zostały poddane aktualizacjom bezpieczeństwa. Upewnij się, że Twoja wersja Splunk zawiera już te poprawki – jeśli nie, rozważ migrację do wersji, które je integrują.

Podsumowanie

Odkryte w Splunk Enterprise i Splunk Cloud luki stanowią poważne zagrożenie dla firm oraz instytucji polegających na tych systemach do analizy danych, bezpieczeństwa i monitoringu. Najgroźniejsza z nich – SSRF (CVE-2025-20371) – może umożliwić wykonanie zapytań REST API w imieniu użytkownika z wysokimi uprawnieniami, przy pomocy phishingu i manipulacji ustawieniami konfiguracyjnymi. Pozostałe usterki – XSS, XXE, DoS czy ujawnienie danych – choć ocenione jako średnie ryzyko, mogą stanowić lukę w łańcuchu, jeśli nie zostaną zaadresowane.

Kluczowymi krokami zaradczymi są: natychmiastowa aktualizacja, ograniczenie eksponowania interfejsów webowych, restrykcje ról oraz ścisłe monitorowanie aktywności. Dla każdej organizacji, która korzysta ze Splunk w środowisku produkcyjnym, wymienione zabezpieczenia powinny być wprowadzone natychmiastowo.