Podatności Splunk Enterprise

Podatność w Splunk Enterprise przed wersjami 10.4.3 i 10.2.7 pozwala nieuwierzytelnionemu użytkownikowi z dostępem sieciowym do API REST Patroni na członku klastra wyszukiwania na wykonanie poleceń systemu operacyjnego. Interfejs nie wymaga uwierzytelnienia dla krytycznych operacji konfiguracyjnych.

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 Splunk Enterprise w wersjach poniżej 10.4.4 i 10.2.8 użytkownik bez ról admin lub power może odtworzyć hasło superużytkownika bazy PostgreSQL sidecar i uruchomić dowolne polecenia systemowe jako konto uruchamiające Splunk Enterprise na członkach klastra search head. Luka wynika z faktu, że usługa PostgreSQL sidecar wyprowadza uprzywilejowane hasło bazy z identyfikatora klastra search head, który pojawia się w logach zadań wyszukiwania.

W Splunk Enterprise (wersje poniżej 10.4.4, 10.2.8, 10.0.11 i 9.4.16) nieuwierzytelniony użytkownik może nakłonić użytkownika z uprawnieniem edit_federated_providers do wyłączenia wszystkich dostawców wyszukiwania sfederowanego. Wynika to z faktu, że API REST dostawców sfederowanych akceptuje żądania GET dla akcji zmieniających stan, a atak wymaga phishingu ofiary.

W Splunk Enterprise w wersjach poniżej 10.4.4, 10.2.8, 10.0.11 i 9.4.16 użytkownik nieposiadający ról "admin" ani "power" mógł tworzyć, przenosić, edytować lub usuwać konfiguracje zmiany nazw typów źródłowych, których jest właścicielem, w aplikacjach, do których nie ma uprawnień dostępu. Luka jest możliwa przy włączonym Splunk Web, ponieważ nie weryfikuje on wymaganych uprawnień aplikacji przed wykonaniem operacji zmiany nazw typów źródłowych.

W Splunk Enterprise w wersjach poniżej 10.4.4, 10.2.8, 10.0.11 i 9.4.16 oraz w Splunk Secure Gateway w wersjach poniżej 3.10.12, 3.9.26 i 3.8.73 użytkownik nieposiadający ról "admin" lub "power" może przeglądać listy dashboardów i raportów poza zakresem żądanego filtra, pozostając w granicach obiektów, do których ma dostęp. Podatność wynika z nieneutralizowania znaków specjalnych w wartościach przed utworzeniem filtrów.

W Splunk Enterprise w wersjach poniżej 10.4.4, 10.2.8, 10.0.11 i 9.4.16 użytkownik nieposiadający ról "admin" ani "power" mógł przenosić wyodrębnienia pól lub transformacje pól do aplikacji, do których nie ma uprawnień odczytu. Luka jest możliwa, ponieważ API REST nie weryfikuje dostępu do aplikacji docelowej przed przetworzeniem operacji przenoszenia wyodrębnień i transformacji pól.

W Splunk Enterprise w wersjach poniżej 10.4.3, 10.2.8, 10.0.11 i 9.4.16 użytkownik z rolą posiadającą uprawnienie edit_manager_xml może wykonać dowolne polecenia systemu operacyjnego z uprawnieniami konta uruchamiającego Splunk Enterprise, otwierając odpowiednią konfigurację w Splunk Web Manager. Podatność wynika z tego, że Splunk Web ocenia wyrażenia kontrolowane przez użytkownika z Manager XML bez wystarczającego ograniczenia składni wyrażeń.

W Splunk Enterprise w wersjach poniżej 10.4.4, 10.2.8, 10.0.11 i 9.4.16 oraz Splunk Secure Gateway w wersjach poniżej 3.10.12, 3.9.26 i 3.8.73 użytkownik o niskich uprawnieniach bez roli "admin" Splunk lub roli "sc_admin" Splunk Secure Gateway może odczytywać dane powiadomień o alertach mobilnych innych użytkowników poprzez punkty końcowe REST API App Key Value Store (KV Store) Splunk Secure Gateway. Podatność wynika z braku egzekwowania autoryzacji na poziomie użytkownika dla żądań odczytu w kolekcjach KV Store.

W Splunk Enterprise w wersjach poniżej 10.4.4, 10.2.8, 10.0.11 i 9.4.16 użytkownik posiadający rolę z uprawnieniem schedule_search może obejść oczekiwane zabezpieczenia w procesie wyszukiwania zaplanowanego. Użytkownik może następnie uruchomić ryzykowne polecenia SPL, które ujawniają lub zmieniają dane Splunk Enterprise albo zakłócają dostępność Splunk Enterprise. Podatność wynika z faktu, że harmonogram wyszukiwania Splunk Enterprise nie stosuje zabezpieczeń SPL dla ryzykownych poleceń do wyszukiwań zaplanowanych.

W Splunk Enterprise w wersjach poniżej 10.4.4, 10.2.8 i 10.0.11 nieuwierzytelniony użytkownik może wysyłać powtarzające się żądania do punktu końcowego pobierania pakietów Edge Processor w aplikacji Splunk Pipeline Builders. Żądania mogą powodować nadmierne zużycie zasobów systemowych przez demona Splunk i potencjalnie doprowadzić do braku odpowiedzi. Podatność wynika z braku uwierzytelniania i przetwarzania całego pakietu w pamięci dla każdego żądania.

W Splunk Enterprise w wersjach poniżej 10.4.4, 10.2.8, 10.0.11 i 9.4.16 użytkownik nieposiadający ról „admin” ani „power” może uczynić instancję niedostępną dla innych użytkowników poprzez wysłanie żądania do endpointu REST API dla plików tabel przeglądowych. Dotknięta instancja wymaga restartu w celu przywrócenia usługi, ponieważ endpoint nie ogranicza zużycia zasobów podczas przetwarzania wyboru pól odpowiedzi.

W Splunk Enterprise w wersjach poniżej 10.4.4, 10.2.8, 10.0.11 i 9.4.16 nieuwierzytelniony użytkownik może wysłać pojedyncze spreparowane żądanie do endpointu loggera JavaScript w Splunk Web i spowodować zaprzestanie odpowiadania przez Splunk Web na żądania. Splunk Web pozostaje niedostępny do momentu restartu Splunk Enterprise. Podatność wynika z braku ograniczenia parsowania nagłówków żądania przed jego przetworzeniem.

W Splunk Enterprise w wersjach poniżej 10.4.4 użytkownik posiadający rolę z uprawnieniem preview_data_management_pipeline lub edit_data_management_pipeline_job może odczytywać lub usuwać zadania i wyniki podglądu Data Management SPL2 poza zakresem własności. Podatność występuje, ponieważ REST API Data Management weryfikuje wymagane uprawnienie, ale nie sprawdza, czy żądane zadanie podglądu należy do wnioskującego. API jest dostępne tylko przy włączonej funkcji Edge Processor, która domyślnie jest wyłączona.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7, 10.0.10 i 9.4.15 oraz Splunk Secure Gateway poniżej 3.10.11, 3.9.25 i 3.8.72, uwierzytelniony użytkownik bez ról admin lub sc_admin może modyfikować dane alertów i urządzeń mobilnych w kolekcjach App Key Value Store, co wpływa na późniejsze przepływy pracy alertów i subskrypcji. Podatność wynika z braku ograniczeń zapisu w tych kolekcjach.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7, 10.0.10 i 9.4.15, użytkownik z uprawnieniem run_collect może użyć polecenia collect SPL do zapisywania zdarzeń do wewnętrznych indeksów poza skonfigurowanym dla roli dostępem do indeksów. Podatność wynika z braku normalizacji białych znaków w nazwie indeksu przed zastosowaniem ograniczeń dostępu.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7 i 10.0.10, użytkownik z uprawnieniem edit_spl2_module_permissions może użyć REST API do uzyskania informacji o uprawnieniach modułów SPL2, których nie ma prawa przeglądać. Podatność wynika z braku weryfikacji, czy użytkownik może czytać aplikację przed zwróceniem uprawnień modułu.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7, 10.0.10 i 9.4.15, użytkownik z uprawnieniem edit_user może utworzyć nazwę użytkownika kończącą się kropką. Walidacja nazwy nie odrzuca końcowej kropki, co powoduje, że różne nazwy mogą współdzielić dane konfiguracyjne, a operacje zarządzania użytkownikami mogą dotyczyć niewłaściwego konta lub kończyć się niepowodzeniem.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7 i 10.0.10, użytkownik z niskimi uprawnieniami (bez ról admin lub power) może pobrać oryginalny kod źródłowy aplikacji Discover Splunk Observability Cloud przez Splunk Web. Podatność wynika z osadzonych source map w produkcji, które zawierają oryginalny kod źródłowy.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7, 10.0.10 i 9.4.15, użytkownik bez ról admin lub power może uzyskać dostęp do tekstu zapytań i metadanych zadań innych użytkowników przez REST API. Podatność wynika z niepełnego egzekwowania autoryzacji per użytkownik przy wyświetlaniu listy zadań.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7 i 10.0.10, użytkownik z uprawnieniem read_o11y_content może przekierować wychodzące żądanie z aplikacji Splunk App for Splunk Observability Cloud przez REST API na kontrolowany przez atakującego host i ujawnić skonfigurowany token API Observability Cloud. Podatność wynika z niepełnej walidacji celu wychodzącego żądania.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7, 10.0.10 i 9.4.15, użytkownik z uprawnieniem run_collect może użyć polecenia collect SPL do dodania treści kontrolowanej przez atakującego do komunikatów na poziomie systemowym. Podatność wynika z braku walidacji nazwy indeksu przed przetworzeniem wartości.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7, 10.0.10 i 9.4.15 oraz Splunk Secure Gateway poniżej 3.10.11, 3.9.25 i 3.8.72, użytkownik bez ról admin lub power może spowodować podpisanie przez Splunk Secure Gateway payloadów kontrolowanych przez atakującego. Podatność wynika z braku weryfikacji autoryzacji użytkownika do żądania podpisu.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7 i 10.0.10, użytkownik z niskimi uprawnieniami (bez ról admin lub power) może spowodować denial of service na REST API endpoint w aplikacji Discover Splunk Observability Cloud. Podatność wynika z użycia nieefektywnego wyrażenia regularnego do walidacji danych wejściowych.

W Splunk Enterprise w wersjach poniżej 10.4.3 użytkownik z rolą posiadającą uprawnienie list_spl2_modules może wykorzystać wstrzykiwanie SQL w filtrowaniu modułów SPL2, aby uzyskać dostęp do wszystkich danych dostępnych przez REST API, w tym prywatnych definicji modułów SPL2 innych użytkowników. Podatność wynika z braku parametryzacji wartości dostarczanych przez użytkownika przed użyciem ich w zapytaniach do bazy danych.

W Splunk Enterprise w wersjach poniżej 10.4.3, 10.2.7, 10.0.10 i 9.4.15 użytkownik bez ról admin lub power może wykorzystać kontrolowany identyfikator zadania, aby uzyskać dostęp do prawie wszystkich informacji o zadaniach wyszukiwania należących do innych użytkowników, w tym tekstu zapytania, metadanych, wyników i podglądów wyników, przez REST API. Podatność wynika z niepełnej weryfikacji własności zadań przed zwróceniem informacji.

W Splunk Enterprise w wersjach poniżej 10.4.3, 10.2.7 i 10.0.10 użytkownik z uprawnieniem read_o11y_content może wstrzykiwać sfałszowane wpisy do dziennika aplikacji przez REST API. Podatność wynika z braku neutralizacji treści SignalFlow dostarczanych przez użytkownika przed zapisem do dziennika aplikacji w Splunk App for Splunk O11y Cloud.

W Splunk Enterprise na Linuxie w wersjach poniżej 10.4.3, 10.2.7, 10.0.10 i 9.4.15, lokalny użytkownik mogący uruchamiać polecenia jako konto użytkownika Splunk może spowodować, że aktualizacja pakietu Linuksa wykona kontrolowane przez atakującego polecenia systemowe z uprawnieniami roota. Podatność wynika z zaufania skryptu konserwacyjnego pakietu do istniejącej zawartości instalacji Splunk podczas operacji aktualizacji z uprawnieniami roota. Wymaga to, aby aktualizacja pakietu nastąpiła po modyfikacji instalacji przez lokalnego użytkownika.

W Splunk Enterprise w wersjach poniżej 10.4.2, 10.2.6, 10.0.10 i 9.4.15 użytkownik bez ról admin lub power może tworzyć lub edytować definicje skryptowych wyszukiwań (scripted lookups) przez surowe punkty końcowe konfiguracji. Podatność wynika z braku sprawdzania uprawnień external lookup w ścieżkach zapisu surowej konfiguracji transforms.

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.