Podatności Splunk Enterprise

W Splunk Enterprise w wersjach poniżej 10.4.1, 10.2.6, 10.0.9 i 9.4.14 nieuwierzytelniony użytkownik, który może odczytać źródło HTML strony osadzającej raport Splunk, może wykorzystać ujawnione materiały sesji do uzyskania dostępu do wszystkich istotnych danych i wpłynąć na integralność systemu. Podatność wynika z nieprawidłowego egzekwowania granic autoryzacji dla osadzonych raportów w ścieżce pobierania archiwum dispatch oraz z uwzględniania wrażliwych materiałów sesji w zarchiwizowanych danych zadań wyszukiwania.

W Splunk Enterprise w wersjach poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 nieuwierzytelniony użytkownik posiadający token osadzonego raportu może pobrać archiwum dispatch dla zadania wyszukiwania osadzonego raportu i wykorzystać ujawnione materiały sesji do uzyskania dostępu do wszystkich istotnych danych oraz wpłynąć na integralność systemu na instancji Splunk. Podatność wynika z tego, że przepływ autoryzacji osadzonych raportów nie blokuje żądań pobrania archiwum dispatch przed rozpoczęciem wysyłania archiwum do żądającego.

W Splunk Enterprise w wersjach poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 nieuwierzytelniony użytkownik posiadający token osadzonego raportu może pobrać powiązane archiwum dispatch zadania wyszukiwania, odzyskać materiały sesji i użyć ich do uzyskania dostępu do wszystkich istotnych danych dostępnych właścicielowi raportu oraz wpłynąć na integralność systemu, w tym wykonywać działania administracyjne, gdy właściciel ma rolę "admin" Splunk. Podatność wynika z tego, że dostęp do osadzonych raportów nie blokuje żądań pobrania archiwum dispatch przez API REST.

W wersjach Splunk Enterprise 10.4 poniżej 10.4.2, nieuwierzytelniony użytkownik może pobrać informacje zawarte w konfiguracjach potoków Edge Processor przez punkt końcowy API REST, gdy Edge Processor jest włączony. Podatność nie dotyczy wersji wcześniejszych niż 10.4. Podatność istnieje, ponieważ punkt końcowy usługi Edge Processor nie ma kontroli uwierzytelniania.

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 wpłynąć na integralność i dostępność systemu, wysyłając spreparowane żądanie REST API, które usuwa lub tymczasowo nadpisuje pliki zapisywalne przez konto użytkownika uruchamiające procesy Splunk Enterprise na nie-kapitanie członka klastra search head. Podatność wynika z tego, że replikacja pakietów Search Head Clustering nie weryfikuje nazwy replikowanego pliku pakietu ani nie neutralizuje bajtów NUL przed skonstruowaniem ścieżki pakietu członka.

W Splunk Enterprise w wersjach poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 użytkownik, który nie posiada ról "admin" lub "power", może przesłać spreparowaną deltę pakietu wiedzy, aby usunąć dowolne pliki dostępne dla Splunk Enterprise na menedżerze klastra. Podatność wynika z braku ograniczenia ścieżek usuwania do katalogu tymczasowego oraz braku egzekwowania oczekiwanej granicy autoryzacji.

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 utworzyć lub zmodyfikować skryptowy lookup przez ogólne punkty końcowe konfiguracji i uruchomić zainstalowany skrypt lookup z uprawnieniami konta użytkownika uruchamiającego Splunk Enterprise, co może umożliwić dostęp do wszystkich istotnych danych i wpłynąć na integralność i dostępność systemu. Podatność wynika z tego, że ogólne punkty końcowe konfiguracji transformacji nie egzekwują wymaganych uprawnień do tworzenia lub edycji zewnętrznych definicji lookup.

W wersjach Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14, użytkownik posiadający rolę z uprawnieniem schedule_search może skonfigurować załączniki PDF w przepływie pracy akcji alertu e-mail. Gdy akcja alertu e-mail zostanie uruchomiona, może wykonać dowolne polecenia SPL z uprawnieniami na poziomie systemu, ujawnić wszystkie istotne dane oraz wpłynąć na integralność i dostępność systemu na search head. Podatność wynika z tego, że harmonogram wyszukiwania przekazuje kontekst uwierzytelniania na poziomie systemu, a nie kontekst właściciela akcji, do akcji alertu e-mail podczas renderowania załączników PDF.

W wersjach Splunk Enterprise poniżej 10.2.6, 10.0.9 i 9.4.14 nieuwierzytelniony użytkownik może nakłonić uwierzytelnionego użytkownika do wykonania dowolnych poleceń SPL z jego uprawnieniami poprzez spreparowany link w Splunk Web. Podatność wynika z podstawiania wartości tokenów z URL do wyszukiwań SPL bez ich neutralizacji. Atak wymaga phishingu użytkownika.

W wersjach Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 użytkownik z uprawnieniem list_search_head_clustering może wysłać żądanie odczytu do endpointów kontroli członków Search Head Cluster i zmienić stan klastra, co może prowadzić do odmowy usługi. Podatność wynika z braku wymogu żądania zmieniającego stan HTTP przed zastosowaniem autoryzacji tylko do odczytu.

W Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14 oraz Splunk Secure Gateway poniżej 3.10.9, 3.9.23 i 3.8.70, użytkownik bez ról admin lub power może wykorzystać SSRF w powiadomieniach raportów do wysyłania żądań z uprawnieniami systemowymi do wewnętrznych usług Splunk. Może to prowadzić do zmian w stanie Search Head Cluster i DoS. Podatność wynika z braku walidacji ścieżek powiadomień.

W Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14, użytkownik z rolą power może przechowywać złośliwy skrypt w opcjach formatowania sparkline dashboardu i wykonać nieautoryzowany JavaScript w przeglądarce innego użytkownika. Jeśli ofiara ma rolę admin, skrypt może uzyskać dostęp do wszystkich danych i wykonywać działania z jej uprawnieniami. Podatność wynika z braku ograniczeń opcji wizualizacji i braku escapowania wartości tooltipów.

W Splunk Enterprise poniżej 10.4.2, użytkownik z wysokimi uprawnieniami zarządzający klastrem search head może użyć API REST do zapisu plików w lokalizacjach zapisywalnych przez konto Splunk, co może umożliwić zdalne wykonanie kodu. Podatność wynika z braku egzekwowania granic autoryzacji i braku walidacji ścieżek bundle.

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 zapisać metadane dispatch do dowolnej lokalizacji na hoście, dostarczając spreparowany identyfikator wyszukiwania do punktu końcowego API REST i wpłynąć na integralność systemu na hoście. Podatność wynika z tego, że Splunk Enterprise nie weryfikuje identyfikatora wyszukiwania przed użyciem go do utworzenia katalogu dispatch.

W 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 wykonywać dowolne zapytania SQL przez endpoint Data Orchestration jobs, co umożliwia dostęp do danych przechowywanych przez Data Orchestration, w tym zadań innych użytkowników i poświadczeń połączeń. Podatność wynika z budowania zapytań bez parametryzacji.

W Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14, użytkownik z rolą power może przechowywać ryzykowne polecenia SPL w zbiorze danych Table Editor i udostępnić go. Użytkownik z rolą admin uruchamia te polecenia po otwarciu zbioru w Table Editor, co może ujawnić dane i modyfikować pliki lookup. Podatność wynika z braku zabezpieczeń SPL dla ryzykownych poleceń w wyszukiwaniu field-summary.

W Splunk Enterprise w wersjach 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 kod SPL w zbiorze danych Table Editor i udostępnić go. Gdy użytkownik z rolą "admin" otworzy ten zbiór, kod SPL wykona się z jego uprawnieniami, co może ujawnić dane i umożliwić ich modyfikację. Luka wynika z braku zabezpieczeń SPL dla ryzykownych poleceń w Table Editor.

W Splunk Enterprise 10.4 poniżej 10.4.2, nieuwierzytelniony użytkownik może wymusić przeładowanie kluczy podpisujących tokeny przez API REST. Podatność wynika z braku wymogu uwierzytelnienia lub uprawnienia change_authentication dla akcji przeładowania kluczy.

W 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ąć dowolne polecenia SPL przez komendę geostats. Wstrzyknięte SPL wykonuje się z uprawnieniami innego uwierzytelnionego użytkownika po tym, jak ten zainicjuje wyszukiwanie geostats w Splunk Web. Podatność wynika z niewystarczającej walidacji danych wejściowych.

W wersjach Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14, nieuwierzytelniony użytkownik mający dostęp do zaufanego prywatnego klucza wyszukiwania rozproszonego może sfałszować administracyjny token sesji, uzyskać dostęp do wszystkich istotnych danych, wpłynąć na integralność systemu i zakłócić dostępność usług. Podatność wynika z tego, że punkt końcowy tokena uwierzytelniania wyszukiwania rozproszonego nie wymaga podpisanego żądania do identyfikacji skonfigurowanego peera wyszukiwania, co pozwala żądaniu na użycie wspólnego lokalnego materiału klucza.

W Splunk Enterprise poniżej 10.4.2, 10.2.6, 10.0.9 i 9.4.14, nieuwierzytelniony użytkownik może odczytać pliki JavaScript poza katalogiem statycznym Splunk Web. Podatność wynika z braku ograniczenia żądań plików statycznych do skonfigurowanego katalogu.

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ń.