Podatności Splunk Enterprise

W wersjach Splunk Enterprise poniżej 10.4.2 i 10.2.6 użytkownik bez ról admin lub power może usunąć wszystkie moduły SPL2 w całej instancji przez API REST. Może to usunąć wyeksportowane zbiory danych i funkcje, naruszając integralność systemu i powodując częściowe zakłócenia usług.

W wersjach Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 uwierzytelniony użytkownik bez uprawnienia edit_manager_xml może zapisać złośliwą konfigurację XML Menedżera Splunk Web. Po otwarciu strony przez tego użytkownika Splunk wykonuje polecenia systemowe kontrolowane przez atakującego.

Użytkownik z rolą "power" w Splunk Enterprise może zapisać akcję przepływu pracy w Dashboard Studio zawierającą kontrolowany przez atakującego język SPL. Gdy inny uwierzytelniony użytkownik wybierze tę akcję, Splunk uruchomi wstrzyknięty SPL z uprawnieniami tego użytkownika, co może pozwolić na dostęp lub modyfikację danych. Podatność wynika z niedostatecznej walidacji adresów URL akcji przepływu pracy w Dashboard Studio.

W wersjach Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 użytkownik z rolą power może zapisać akcję workflow Dashboard Studio z spreparowanym URL. Gdy inny uwierzytelniony użytkownik wybierze tę akcję, w jego przeglądarce wykonywany jest złośliwy JavaScript.

W wersjach Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 nieuwierzytelniony użytkownik może nakłonić uwierzytelnionego użytkownika do otwarcia spreparowanego linku do Analytics Workspace. Po otwarciu Splunk wykonuje SPL kontrolowane przez atakującego z uprawnieniami ofiary.

W wersjach Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 użytkownik bez ról admin lub power może wstrzyknąć SPL do żądań uruchamiania zapisanych wyszukiwań. Może to umożliwić nieautoryzowany dostęp do danych i naruszyć integralność systemu.

W wersjach Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 nieuwierzytelniony użytkownik może nakłonić uwierzytelnionego użytkownika do otwarcia spreparowanego linku do Monitoring Console. Po otwarciu Splunk wykonuje SPL kontrolowane przez atakującego z uprawnieniami ofiary.

Nieuwierzytelniony atakujący może nakłonić użytkownika z rolą "admin" do otwarcia spreparowanego linku do Monitoring Console. Po otwarciu linku Splunk Enterprise uruchamia kontrolowany przez atakującego język SPL z uprawnieniami tego użytkownika, co może ujawnić dane lub zmodyfikować dane wyszukiwania. Podatność wynika z niedostatecznej walidacji danych używanych do budowania wyszukiwań w pulpitach Monitoring Console.

Użytkownik z rolą "power" może zapisać kontrolowany przez atakującego język SPL w pulpicie. Gdy inny uwierzytelniony użytkownik eksportuje pulpit do pliku PDF, Splunk Enterprise uruchamia wstrzyknięty SPL z uprawnieniami tego użytkownika, co może pozwolić na dostęp lub modyfikację danych. Podatność wynika z niedostatecznej walidacji zawartości pulpitu przed przetworzeniem eksportu PDF.

Nieuwierzytelniony atakujący może nakłonić użytkownika z rolą "admin" lub "sc_admin" do otwarcia spreparowanego adresu URL Splunk Web. Wynikające z tego wyszukiwania w pulpitach mogą uruchamiać dowolne polecenia SPL z uprawnieniami ofiary, co może ujawnić dane i wpłynąć na wyniki wyszukiwania lub dane wyszukiwania. Podatność wynika z nieprawidłowej neutralizacji wartości dostarczanych przez wywołującego w pulpitach Splunk Secure Gateway.

Użytkownik bez ról "admin" lub "power" może zapisać widok pulpitu, który uruchamia JavaScript w przeglądarce innego użytkownika, gdy ten otworzy pulpit i najedzie kursorem na komórkę tabeli sparkline. Może to pozwolić na dostęp do wszystkich istotnych danych i naruszenie integralności systemu. Podatność wynika z niedostatecznego ograniczenia opcji tooltipów i braku escapowania zawartości tooltipów przed wyświetleniem.

W wersjach Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 użytkownik z rolą power może zapisać złośliwy obiekt ui-tour pasujący do nazwy strony auto-tour i udostępnić go na poziomie aplikacji. Obiekt może wykonać dowolny JavaScript w przeglądarce innego uwierzytelnionego użytkownika.

Użytkownik z rolą "power" może utworzyć złośliwą wycieczkę Splunk Web i spowodować wykonanie dowolnego JavaScript w przeglądarce innego użytkownika, gdy ten otworzy spreparowany link do wycieczki. JavaScript wykonuje się w przeglądarce ofiary, umożliwiając dostęp do wszystkich istotnych danych. Podatność XSS wynika z niedostatecznego kodowania wyjściowego treści wycieczki i linków nawigacyjnych oraz akceptowania wartości selektora wycieczki, która może być traktowana jako znaczniki.

Użytkownik bez ról "admin" lub "power" może ominąć zabezpieczenia SPL dla ryzykownych poleceń przez pulpit Job Details. Wstrzyknięty SPL może zostać uruchomiony z uprawnieniami uwierzytelnionego użytkownika, który otworzy spreparowany link do pulpitu Job Details. Może to pozwolić na dostęp do wszystkich istotnych danych i wpłynąć na integralność systemu. Podatność wynika z nieprawidłowej neutralizacji identyfikatora wyszukiwania dostarczonego przez wywołującego przed umieszczeniem go w wyszukiwaniach SPL.

Użytkownik z rolą "user" może stworzyć pulpit Dashboard Studio, który uruchamia kontrolowany przez atakującego język SPL dla innego uwierzytelnionego użytkownika. Kontrolowany SPL może uzyskać dostęp do wszystkich istotnych danych oraz wpłynąć na integralność i dostępność systemu. Podatność wynika z niespójnego egzekwowania granicy autoryzacji widoczności aplikacji przed dotarciem opcji zapytań pulpitu do wysyłki wyszukiwania.

W wersjach Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 nieuwierzytelniony użytkownik może wstrzyknąć dowolny SPL do żądań wyszukiwania zdarzeń w pobliżu wybranego zdarzenia. Może to umożliwić nieautoryzowane wykonywanie wyszukiwań.

Nieuwierzytelniony atakujący może spowodować, że uwierzytelniony użytkownik wykona dowolne wyszukiwania SPL w jego imieniu przez Event Type Builder. Może to ujawnić wszystkie istotne dane i przechowywane poświadczenia. Podatność występuje, gdy Event Type Builder akceptuje dane wejściowe z żądań między witrynami i zachowuje wartości wpływające na SPL podczas budowania przykładowych wyszukiwań zdarzeń.

W wersjach Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 użytkownik z niskimi uprawnieniami bez uprawnienia fsh_manage może wykonać zdalny kod przez wybór pakietu Federated Search. Może to umożliwić dostęp do danych i naruszyć integralność oraz dostępność systemu.

Użytkownik z rolą posiadającą uprawnienie schedule_search może zapisać złośliwy skrypt w polu warunku wyzwalania alertu. Gdy inny użytkownik otworzy spreparowany link, skrypt wykonuje się w przeglądarce tego użytkownika i może uzyskać dostęp do wszystkich danych dostępnych temu użytkownikowi. Podatność wynika z używania wartości progu alertu w generowanym znaczniku warunku wyzwalania alertu bez escapowania znaków specjalnych.

W wersjach Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 użytkownik bez ról admin lub power może przenieść pliki, które konto Splunk może odczytać, do lookupu kontrolowanego przez użytkownika. Może to umożliwić dostęp do danych i naruszyć integralność oraz dostępność systemu.

W Splunk Enterprise w wersjach poniżej 10.4.1, 10.2.5, 10.0.9 i 9.4.14 nieuwierzytelniony użytkownik, który ma dostęp do portu zarządzania Splunk, może zapisać potok SPL, który wykona się, gdy administrator otworzy przepływ pracy Add Data forwarder. Potok SPL może uzyskać dostęp do wszystkich istotnych danych oraz wpłynąć na integralność i dostępność instancji Splunk. Wstrzyknięcie SPL jest możliwe, ponieważ identyfikatory klientów Deployment Server są umieszczane w wysyłanych wyszukiwaniach bez neutralizowania znaków specjalnych.

W Splunk Enterprise w wersjach poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 użytkownik bez ról "admin" lub "power" może wykonać dowolny kod na instancji Splunk przez Splunk Web Manager Configuration. Użytkownik może następnie uzyskać dostęp do wszystkich istotnych danych oraz wpłynąć na integralność i dostępność systemu. Podatność wynika z tego, że Splunk Web Manager Configuration ocenia wartości konfiguracji menedżera, a ścieżka REST API dla konfiguracji menedżera nie wymaga uprawnień, które normalnie kontrolują zapisy konfiguracji menedżera.

W Splunk Enterprise w wersjach poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 użytkownik bez ról "admin" lub "power" może wykonać zdalne wykonanie kodu (RCE) poprzez przesłanie spreparowanej zawartości Splunk Web Manager Configuration. Użytkownik może następnie uzyskać dostęp do wszystkich istotnych danych oraz wpłynąć na integralność i dostępność systemu. Podatność wynika z tego, że Splunk Web ocenia wyrażenia XML menedżera bez wystarczających ograniczeń wejściowych, a powiązana trasa konfiguracji nie wymaga uprawnień oczekiwanych dla zmian konfiguracji menedżera.

W Splunk Enterprise w wersjach poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 użytkownik bez ról "admin" lub "power" może wykonać zdalne wykonanie kodu (RCE) poprzez przesłanie złośliwego pakietu wiedzy i spowodowanie jego użycia przez wyszukiwanie rozproszone, co może umożliwić dostęp do wszystkich istotnych danych oraz wpłynąć na integralność i dostępność systemu. Podatność wynika z tego, że punkt końcowy REST API do przesyłania pakietów wiedzy nie wymaga uprawnienia edit_dist_peer, a wyszukiwanie rozproszone akceptuje wybory pakietów wiedzy od użytkowników bez tego uprawnienia.

W wersjach Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 użytkownik z niskimi uprawnieniami, bez ról 'admin' lub 'power', może wstrzyknąć kod SQL przez API REST. Dzieje się tak, ponieważ API REST nie neutralizuje odpowiednio wartości filtrów dostarczanych przez użytkownika, co pozwala na wykonanie atakującego tekstu jako części zapytania do bazy danych.

W wersjach Splunk Enterprise poniżej 10.4.2 i 10.2.6 użytkownik bez ról 'admin' lub 'power' może usuwać moduły SPL2 należące do innych użytkowników przez interfejs orchestratora zarządzania danymi. Podatność wynika z braku weryfikacji własności zasobów przed ich usunięciem (uszkodzona autoryzacja na poziomie obiektu).

W Splunk Enterprise 10.4 w wersjach poniżej 10.4.2 nieuwierzytelniony użytkownik może odczytać metryki usługi Prometheus z sidecar SPL2 Preview Edge Processor, w tym szczegóły usługi ujawniające istotne metadane środowiska uruchomieniowego i kompilacji dla sidecar. Podatność nie dotyczy wersji Splunk Enterprise poniżej 10.4. Ujawnienie informacji jest możliwe, ponieważ punkt końcowy metryk Prometheus w sidecar SPL2 Preview Edge Processor nie wymaga uwierzytelnienia, co pozwala każdemu klientowi, który może dotrzeć do sidecar, pobrać metryki bez poświadczeń.

W Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 użytkownik z uprawnieniem rest_properties_get może odczytać zaszyfrowane poświadczenia przez API REST. Podatność wynika z błędnego przypisania uprawnień: endpoint właściwości wymaga uprawnienia rest_properties_get zamiast list_storage_passwords do odczytu poświadczeń.

W Splunk Enterprise dla Windows w wersjach poniżej 10.4.2, 10.2.6, 10.0.9, 9.4.13 i 9.3.14 lokalny użytkownik z dostępem do hosta Windows może związać się z portem zarządzania przed uruchomieniem Splunk Enterprise, przechwycić tokeny uwierzytelniające z procesów potomnych i użyć tych tokenów do naruszenia wszystkich istotnych danych i integralności systemu dostępnych dla konta użytkownika uruchamiającego Splunk Enterprise. Podatność jest możliwa, ponieważ nasłuch na porcie zarządzania Windows nie stosuje ochrony wyłącznego wiązania adresów przed uruchomieniem usługi.

W Splunk Enterprise poniżej 10.4.1, 10.2.6, 10.0.8 i 9.4.13 użytkownik bez ról 'admin' lub 'power' może nakłonić innego użytkownika do uruchomienia dowolnych poleceń SPL przez Edytor Modeli Danych, wykorzystując uprawnienia ofiary. Podatność wynika z braku zabezpieczeń SPL dla ryzykownych poleceń podczas uruchamiania wyszukiwania bazowego dla pól automatycznie wyodrębnianych. Atak wymaga phishingu ofiary.

W Splunk Enterprise przed wersjami 10.4.2, 10.2.6, 10.0.9, 9.4.14 i 9.3.14 nieuwierzytelniony użytkownik może nakłonić innego użytkownika do uruchomienia dowolnych potoków SPL z poziomu Dataset Explorer z uprawnieniami tego użytkownika. Dzieje się tak, ponieważ Dataset Explorer nie waliduje ani nie escapuje nazw zbiorów danych przed budowaniem zapytań SPL i nie stosuje zabezpieczeń SPL dla ryzykownych poleceń. Atak wymaga phishingu, aby ofiara otworzyła spreparowany link.

W Splunk Enterprise przed wersjami 10.4.2, 10.2.6, 10.0.9 i 9.4.14 użytkownik z uprawnieniem schedule_search może uruchamiać dowolne polecenia SPL z najwyższymi uprawnieniami systemowymi i odczytać wszystkie poświadczenia z magazynu poświadczeń. Dzieje się tak, ponieważ konfiguracja akcji alertów dla zaplanowanych wyszukiwań nie ogranicza odpowiednio ustawień akcji alertów specyficznych dla użytkownika przed uruchomieniem akcji przez scheduler.

W Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.13 nieuwierzytelniony użytkownik, który nakłoni ofiarę do odwiedzenia złośliwej strony, może uruchomić nieautoryzowany JavaScript w przeglądarce ofiary. Podatność XSS wynika z braku walidacji pochodzenia i źródła wiadomości otrzymywanych przez handler wiadomości strony. Atak wymaga phishingu ofiary.

W Splunk Enterprise przed wersjami 10.4.2, 10.2.6 i 10.0.9 użytkownik bez ról admin lub power może spowodować, że Splunk App for Splunk Observability Cloud będzie przekazywać żądania do Splunk Observability Cloud, w tym token dostępu przechowywany dla aplikacji. Dzieje się tak, ponieważ handlery endpointów REST aplikacji nie egzekwują uprawnienia read_o11y_content przed przekazaniem żądań z tokenem. Podatność nie dotyczy wersji 9.4 i 9.3.

W Splunk Enterprise (wersje poniżej 10.2.2, 10.0.5, 9.4.10, 9.3.11) oraz Splunk Cloud Platform (wersje poniżej podanych) użytkownik z uprawnieniem edit_user może utworzyć nazwę użytkownika zawierającą bajt null lub nie-UTF-8 bajt kodowany procentowo z powodu niewłaściwej walidacji danych wejściowych. Prowadzi to do niespójnej konwersji nazw użytkowników i problemów z zarządzaniem kontami, np. braku możliwości edycji lub usunięcia takich użytkowników.

W Splunk Enterprise (wersje poniżej 10.0.1, 9.4.5, 9.3.7, 9.2.9) oraz Splunk Cloud Platform (wersje poniżej 10.0.2503.5, 9.3.2411.111, 9.3.2408.121) występuje podatność na nieuwierzytelnione przekierowanie. Atakujący może spreparować złośliwy URL wykorzystujący parametr return_to w punkcie logowania Splunk Web, który po odwiedzeniu przez uwierzytelnionego użytkownika przekieruje go na zewnętrzną złośliwą stronę. Wymaga to nakłonienia ofiary do kliknięcia linku.

W Splunk Enterprise i Splunk Cloud Platform użytkownik z niskimi uprawnieniami może uzyskać dostęp do wrażliwych wyników wyszukiwania, jeśli zgadnie unikalny identyfikator zadania wyszukiwania (SID) wykonywanego w tle przez administratora.

W wersjach Splunk Enterprise poniżej 8.2.12, 9.0.6 i 9.1.1, atakujący może stworzyć zewnętrzne wyszukiwanie, które wywołuje przestarzałą funkcję wewnętrzną. Dzięki temu atakujący może wprowadzić kod do katalogu instalacyjnego platformy Splunk.

W wersjach Splunk Enterprise poniżej 8.2.12, 9.0.6 i 9.1.1, atakujący może wykorzystać podatność na przejście przez absolutną ścieżkę, aby wykonać dowolny kod znajdujący się na oddzielnym dysku.

W wersjach Splunk Enterprise wcześniejszych niż 8.2.12, 9.0.6 i 9.1.1, dynamiczna biblioteka linków (DLL) odnosi się do niebezpiecznej ścieżki w definicji budowy OPENSSLDIR. Atakujący może wykorzystać to odniesienie do zainstalowania złośliwego kodu, co prowadzi do eskalacji uprawnień na maszynie z systemem Windows.

W wersjach Splunk Enterprise poniżej 8.2.12, 9.0.6 i 9.1.1, atakujący może wykonać specjalnie przygotowane zapytanie, które pozwala na serializację nieufnych danych. To umożliwia atakującemu wykonanie dowolnego kodu.

W wersjach Splunk Enterprise poniżej 8.2.12, 9.0.6 i 9.1.1, atakujący może wykorzystać funkcję SPL `printf` do przeprowadzenia ataku typu denial of service (DoS) na instancję Splunk Enterprise.

W wersjach Splunk Enterprise poniżej 9.0.6 i 8.2.12, złośliwy aktor może wysłać źle sformułowane żądanie SAML do punktu końcowego REST `/saml/acs`, co może prowadzić do odmowy usługi poprzez awarię lub zawieszenie demona Splunk.

W wersjach Splunk Enterprise poniżej 9.1.1, 9.0.6 i 8.2.12, atakujący może stworzyć specjalne żądanie webowe, które może prowadzić do odzwierciedlonego ataku XSS na punkcie końcowym „/app/search/table”. Wykorzystanie tej podatności może prowadzić do wykonania dowolnych poleceń na instancji platformy Splunk.