Katalog podatności CVE

W Splunk Connect for Kafka w wersjach poniżej 2.2.7 nieuwierzytelniony użytkownik, który ma dostęp do API REST Kafka Connect, może skonfigurować niebezpieczny endpoint HTTP Event Collector w Splunk Enterprise, co powoduje wysyłanie poświadczeń uwierzytelniających do serwera kontrolowanego przez atakującego. Może to prowadzić do ujawnienia poświadczeń i naruszenia integralności danych przesyłanych przez konektor.

W Splunk AI Toolkit w wersjach poniżej 6.0.1 użytkownik z rolą "power" może modyfikować dostarczane przez aplikację zaplanowane wyszukiwania, aby uruchamiać dowolny język SPL z uprawnieniami właściciela wyszukiwania. Może to umożliwić dostęp do wszystkich istotnych danych i wpłynąć na integralność systemu.

W Splunk AI Toolkit w wersjach poniżej 6.0.0 użytkownik z rolą "power" może uzyskać dostęp do historii eksperymentów i usuwać wszystkie istotne dane, w tym dane innych użytkowników. Podatność wynika z braku zachowania zaufanego zakresu eksperymentu podczas przetwarzania wartości zapytań kontrolowanych przez wywołującego.

W Splunk AI Toolkit w wersjach poniżej 6.0.0 użytkownik z rolą posiadającą uprawnienie schedule_search może spowodować, że zaplanowane wyszukiwanie załaduje i zdeserializuje plik modelu przez polecenie apply. Podatność wynika z braku oznaczenia polecenia apply jako ryzykownego.

W Splunk AI Toolkit w wersjach poniżej 6.0.0 użytkownik z rolą "power" może wykonać dowolny kod na serwerze Splunk, ładując plik modelu zawierający spreparowane dane rzadkiej macierzy. Podatność wynika z deserializacji niezaufanych danych bez zabezpieczeń przed osadzonym kodem pickle.

W Splunk AI Toolkit w wersjach poniżej 6.0.0 użytkownik z niskimi uprawnieniami, bez ról "admin" lub "power", może uruchamiać, zatrzymywać i konfigurować kontenery oraz odczytywać lub modyfikować dane połączeń i konfiguracji przez API REST. Podatność wynika z braku kontroli autoryzacji w wielu handlerach API REST.

W Splunk AI Toolkit w wersjach poniżej 6.0.0 użytkownik bez ról "admin" lub "power" może uruchamiać wyszukiwania z uprawnieniami systemowymi, uzyskać dostęp do wszystkich istotnych danych, wpłynąć na integralność systemu oraz odczytywać lub usuwać zadania wyszukiwania innych użytkowników przez Agent Run History. Podatność wynika z zastąpienia klucza sesji użytkownika tokenem uwierzytelniającym systemu przed wykonaniem operacji wyszukiwania.

W Cisco Talos Intelligence for Enterprise Security Cloud w wersjach poniżej 1.0.3 użytkownik z uprawnieniem get_talos_enrichment może wysłać spreparowane żądanie do endpointu REST wzbogacania Talos, powodując wysłanie żądania wychodzącego do serwera kontrolowanego przez atakującego. Może to ujawnić tokeny, które naruszają wszystkie istotne dane i integralność systemu w instancji Splunk.

W Splunk Enterprise Security w wersjach poniżej 8.6.1 użytkownik z rolą ess_analyst może zmieniać makra wyszukiwań UEBA, które są uruchamiane przez zaplanowane wyszukiwania z uprawnieniami administratora, co umożliwia dostęp do wszystkich istotnych danych i naruszenie integralności systemu. Podatność wynika z nadania analitykom prawa zapisu do makr, które powinny być zapisywalne tylko przez administratorów.

W Splunk Enterprise Security w wersjach poniżej 8.6.1 użytkownik z rolą zawierającą uprawnienie mc_investigation_read może wstrzyknąć język SPL przez filtry wyszukiwania Analyst Queue, co umożliwia dostęp do wszystkich istotnych danych i naruszenie integralności systemu w zakresie zaplanowanych wyszukiwań uruchamianych dla tego użytkownika. Podatność wynika z braku walidacji nazw pól filtrów przed ich użyciem w wyszukiwaniach SPL.

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