Katalog podatności CVE

W Splunk SOAR w wersjach poniżej 8.6.0 użytkownik z rolą "Automation Engineer" może uruchamiać dowolne zapytania SQL przeciwko bazie danych Splunk SOAR poprzez wyniki niestandardowych funkcji, umożliwiając odczyt wszystkich istotnych danych i wpływając na integralność systemu. Podatność na wstrzyknięcie SQL wynika z budowania zapytania do bazy z podaną nazwą zamiast użycia powiązanej wartości SQL.

W Splunk SOAR w wersjach poniżej 8.6.0 użytkownik z rolą "Automation Engineer" może uruchamiać dowolne zapytania SQL przeciwko bazie danych Splunk SOAR oraz tworzyć, odczytywać, aktualizować lub usuwać wszystkie dane w bazie. Podatność wynika z włączania danych dostarczonych przez użytkownika do zapytań do bazy bez odpowiedniej neutralizacji w API automatyzacji playbooków.

W wersjach Splunk SOAR poniżej 8.6.0, nieuwierzytelniony użytkownik, który może obserwować lub modyfikować ruch sieciowy między Splunk SOAR a skonfigurowanym serwerem CyberArk REST, może uzyskać dostęp do wszystkich istotnych danych wymienianych przez ten menedżer poświadczeń lub je zmodyfikować. Podatność wynika z tego, że klient CyberArk REST nie weryfikuje domyślnie certyfikatów serwera. Atak wymaga zdolności przechwytywania ścieżki sieciowej między Splunk SOAR a serwerem CyberArk REST.

W wersjach Splunk SOAR poniżej 8.6.0 użytkownik z rolą Administrator może użyć endpointu /rest/support/connectivity/.../check_connectivity, aby zainicjować połączenia wychodzące do dowolnych miejsc docelowych i sprawdzić, czy wewnętrzne hosty i porty są osiągalne. Podatność SSRF wynika z niewystarczającej walidacji miejsca docelowego przez API sprawdzania łączności.

W Splunk SOAR w wersjach poniżej 8.6.0 uwierzytelniony użytkownik bez przypisanej roli może użyć punktu końcowego /rest/health do zebrania telemetrii systemu i klastra, która powinna być ograniczona do użytkowników administracyjnych lub wsparcia. Podatność wynika z braku sprawdzenia autoryzacji, gdzie punkt końcowy nie weryfikuje, czy wywołujący posiada rolę uprawnioną do przeglądania stanu zdrowia systemu i klastra.

W Splunk SOAR w wersjach poniżej 8.6.0 użytkownik z rolą Administratora może użyć podatności na przechodzenie po ścieżkach (path traversal) w instalatorze Universal Forwarder, aby zapisywać pliki poza zamierzonym katalogiem instalacyjnym. Podatność wynika z braku weryfikacji, czy każdy element archiwum pozostaje w zamierzonym miejscu docelowym przed rozpakowaniem.

W Splunk SOAR w wersjach poniżej 8.6.0 użytkownik z uprawnieniami do instalowania aplikacji może użyć podatności na przechodzenie po ścieżkach podczas instalacji aplikacji, aby zapisywać pliki poza zamierzonym katalogiem tymczasowym. Podatność wynika z braku walidacji, czy rozpakowane ścieżki plików pozostają w zamierzonym katalogu docelowym.

W wersjach Splunk SOAR poniżej 8.6.0, uwierzytelniony użytkownik bez przypisanej roli może przesłać spreparowaną ścieżkę pliku do API REST i wykonać dowolny kod. Podatność wynika z tego, że API REST nie wymaga przypisanej roli dla żądania i nie ogranicza ścieżki pliku dostarczonej przez użytkownika do zamierzonego katalogu tymczasowego.

W wersjach Splunk SOAR poniżej 8.6.0, nieuwierzytelniony użytkownik może sfałszować adres IP źródła w spreparowanym żądaniu do punktu końcowego powiadomień Automation Broker i wykonać dowolny kod na hoście Splunk SOAR. Podatność wynika z tego, że Automation Broker ufa nagłówkowi adresu IP źródła dostarczonemu przez klienta jako dowodowi, że żądanie pochodzi z lokalnego systemu. Udane wykorzystanie może ujawnić wszystkie istotne dane, wpłynąć na integralność systemu i zakłócić dostępność usług.

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 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 użyć spreparowanych danych powiadomień raportów, aby spowodować, że Splunk Secure Gateway wyśle żądanie do API REST Splunk Enterprise przy użyciu tokena sesji na poziomie systemu i zmodyfikować konfigurację platformy Splunk. Użytkownik może następnie uzyskać token sesji bez hasła i użyć go do uzyskania dostępu do wszystkich istotnych danych oraz wpłynąć na integralność systemu. Podatność wynika z tego, że Splunk Secure Gateway nie weryfikuje zdekodowanych identyfikatorów powiadomień raportów przed użyciem ich do konstruowania żądań do API REST Splunk Enterprise.

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.