Katalog podatności CVE

W wersjach poniżej 2.4.5 aplikacji Cisco Secure Malware Analytics dla Splunk SOAR, użytkownik z uprawnieniami do uruchamiania akcji może ujawnić wrażliwe hasło próbki, wywołując akcję detonate file, ponieważ parametr sample_password nie jest maskowany i jest wyświetlany w postaci jawnego tekstu w interfejsie użytkownika. Ujawnienie informacji jest możliwe, ponieważ aplikacja nie oznacza tego parametru jako hasła.

W wersjach poniżej 2.5.3 aplikacji Azure AD Graph dla Splunk SOAR, użytkownik z uprawnieniami do uruchamiania akcji może ujawnić wrażliwe hasło, wywołując akcję resetowania hasła, ponieważ parametr temp_password nie jest maskowany i jest wyświetlany w postaci jawnego tekstu w interfejsie użytkownika. Ujawnienie informacji jest możliwe, ponieważ aplikacja nie oznacza tego parametru jako hasła.

W wersjach poniżej 2.1.9 aplikacji AWS IAM dla Splunk SOAR, użytkownik z uprawnieniami do uruchamiania akcji może ujawnić wrażliwe poświadczenia AWS, wywołując akcję, która przyjmuje parametr credentials, ponieważ parametr nie jest maskowany i jest wyświetlany w postaci jawnego tekstu w interfejsie użytkownika. Ujawnienie informacji jest możliwe, ponieważ aplikacja nie oznacza tego parametru jako hasła.

W wersjach poniżej 2.3.8 aplikacji AD LDAP dla Splunk SOAR, użytkownik z uprawnieniami do uruchamiania akcji może ujawnić wrażliwe poświadczenia, wywołując akcję, która powoduje zapisanie całego środowiska procesu łącznika w postaci jawnego tekstu w trwałym pliku dziennika debugowania. Informacje są zapisywane w pliku dziennika.

W wersjach poniżej 2.3.8 aplikacji AD LDAP dla Splunk SOAR, użytkownik z uprawnieniami do uruchamiania akcji może spowodować zapisanie wrażliwych danych odpowiedzi Active Directory do trwałego pliku dziennika debugowania, wywołując operacje zapisu przez aplikację.

W wersjach poniżej 2.3.8 aplikacji AD LDAP dla Splunk SOAR, użytkownik z uprawnieniami do uruchamiania akcji może wstrzyknąć spreparowane dane do zapytania Active Directory, aby wyliczyć obiekty Active Directory, w tym konta, grupy i jednostki organizacyjne, odczytać wrażliwe atrybuty z dowolnych obiektów katalogu oraz przekierować akcje modyfikacji kont na niezamierzone obiekty.

W wersjach poniżej 3.0.15 Nmap Scanner, użytkownik z rolą umożliwiającą edycję, tworzenie lub uruchamianie playbooków w Splunk SOAR może uruchomić akcję scan network w playbooku Safe Mode, mimo że akcja jest oznaczona jako tylko do odczytu, co może umożliwić wykonanie poleceń lub innych zmian na systemie docelowym przez skrypty Nmap Scripting Engine. Podatność wynika z błędnej klasyfikacji akcji jako tylko do odczytu, mimo że akceptuje parametry skryptów mogące wykonywać operacje zapisu.

W wersjach FireAMP poniżej 2.1.15 użytkownik z rolą umożliwiającą edycję, tworzenie lub uruchamianie playbooków w Splunk SOAR może uruchomić akcję add listitem w playbooku w trybie Safe Mode, mimo że akcja jest oznaczona jako tylko do odczytu. Może to pozwolić na nieautoryzowane zmiany na listach plików. Podatność wynika z błędnej klasyfikacji akcji add listitem jako tylko do odczytu w manifeście akcji konektora FireAMP.

W Splunk SOAR w wersjach poniżej 8.6.0 uwierzytelniony użytkownik z ograniczonym dostępem do dzierżaw (tenantów) może użyć API REST do wyświetlenia nazw i identyfikatorów dzierżaw spoza zakresu swojej roli. Podatność wynika z braku egzekwowania ograniczeń opartych na rolach przy zwracaniu informacji o dzierżawach przez API REST w środowiskach z włączoną wielodzierżawczością.

W wersjach Splunk SOAR poniżej 8.6.0 użytkownik z rolą OnPrem Broker może zapisywać pliki poza zamierzonym katalogiem dziennika Automation Broker. Podatność wynika z akceptowania spreparowanych nazw plików podczas przesyłania dzienników Automation Broker przed zapisem plików dziennika.

W wersjach Splunk SOAR poniżej 8.6.0 użytkownik z uprawnieniem playbooks:view może przeglądać metadane repozytorium playbooków, do których nie ma autoryzacji. Podatność wynika z braku sprawdzania uprawnień repozytorium przez Playbook History przed zwróceniem metadanych rewizji playbooka.

W Splunk SOAR w wersjach poniżej 8.6.0 użytkownik z rolą "Incident Commander" może przechowywać JavaScript w notatce i uruchomić go w przeglądarce innego użytkownika po otwarciu notatki. Podatność na przechowywany XSS wynika z traktowania treści notatki jako HTML bez jej sanityzacji przy zmianie formatu notatki.

W Splunk SOAR w wersjach poniżej 8.6.0 użytkownik z ważnym kontem Splunk SOAR może użyć filtrowania API REST na przebiegach playbooków, aby odzyskać tokeny sesji, które kompromitują wszystkie dane dostępne dla tego użytkownika. Podatność wynika z braku blokowania filtrów API REST przed dopasowywaniem wartości, które odpowiedzi w inny sposób ukrywają.

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 pobieranie niestandardowych list w playbooku, umożliwiając operacje tworzenia, odczytu, aktualizacji i usuwania na wszystkich istotnych danych. Podatność na wstrzyknięcie SQL wynika z budowania zapytania do bazy z podaną nazwą listy 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 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.