Podatności Splunk SOAR

W Splunk SOAR w wersjach poniżej 8.7.0 nieuwierzytelniony użytkownik mający dostęp do zaszyfrowanych danych poświadczeń może przesłać dane uwierzytelniania Basic do API REST, aby ujawnić i odszyfrować te dane. Podatność wynika z tego, że Splunk SOAR odszyfrowuje zaszyfrowane wartości Basic przed zakończeniem kontroli uwierzytelniania. Atak wymaga posiadania zaszyfrowanych danych poświadczeń z podatnej instancji.

W Splunk SOAR w wersjach poniżej 8.7.0 uwierzytelniony użytkownik może zmienić edycję Enterprise Security poprzez REST API, powodując zastosowanie zmiany licencji. Podatność wynika z braku autoryzacji wywołującego przed zastosowaniem zmiany licencji.

W Splunk SOAR w wersjach poniżej 8.7.0 użytkownik posiadający rolę z uprawnieniem widoku Users and Roles może za pomocą API REST wywnioskować wartości tokenów uwierzytelniających innych użytkowników. Jeśli wywnioskowany token zapewnia dostęp administracyjny, użytkownik może uzyskać dostęp administracyjny do instancji Splunk SOAR. Podatność wynika z faktu, że API REST akceptuje kontrolowane przez wywołującego filtry zapytań na wrażliwych polach rekordów użytkowników.

W wersjach Splunk SOAR poniżej 8.7.0 użytkownik z rolą "Observer" może użyć filtrów zapytań w API REST do wywnioskowania hashy haseł i tokenów autoryzacyjnych innych użytkowników. Ujawnienie informacji jest możliwe, ponieważ filtry zapytań API REST są stosowane do rekordów użytkowników przed ochroną pól wrażliwych.

W wersjach Splunk SOAR poniżej 8.7.0 uwierzytelniony użytkownik bez roli z uprawnieniem do przeglądania aplikacji może pobrać archiwum zainstalowanej aplikacji. Może to ujawnić wszystkie dane w archiwum aplikacji, w tym zastrzeżony kod źródłowy i informacje wrażliwe. Podatność wynika z braku weryfikacji uprawnień do przeglądania aplikacji przed zwróceniem archiwum.

W Splunk SOAR w wersjach poniżej 8.7.0 uwierzytelniony użytkownik bez roli z uprawnieniem do edycji Automation Brokers może pobrać plik konfiguracyjny Docker Compose brokera automatyzacji Splunk SOAR. Plik zawiera adres URL instancji Splunk SOAR, lokalizację obrazu kontenera oraz wersję brokera. Podatność wynika z braku wymuszenia uprawnienia do edycji Automation Broker przy zwracaniu pliku konfiguracyjnego.

W Splunk SOAR w wersjach poniżej 8.7.0 użytkownik posiadający rolę z uprawnieniem install_apps może zainstalować aplikację zawierającą złośliwą treść w dokumentacji, która nie jest sanityzowana przed wyświetleniem. Gdy inny użytkownik z uprawnieniem do przeglądania aplikacji otworzy tę dokumentację, treść zostanie wykonana w jego przeglądarce, co może pozwolić atakującemu na dostęp do danych i wykonywanie zmian z uprawnieniami ofiary.

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.

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 SOAR poniżej 8.5.0, nieautoryzowany atakujący może wstrzykiwać kody ucieczki ANSI do plików dzienników aplikacji SOAR poprzez specjalnie przygotowane ścieżki żądań HTTP. Wstrzyknięcie jest możliwe, ponieważ SOAR nie usuwa znaków kontrolnych z ścieżek żądań HTTP przed zapisaniem ich do dzienników aplikacji.

Wersje Splunk SOAR poniżej 6.1.0 są pośrednio narażone na potencjalną podatność, która może być wykorzystana przez terminal użytkownika. Osoba trzecia może wysłać złośliwie skonstruowane żądanie webowe zawierające specjalne znaki ANSI, co prowadzi do zanieczyszczenia plików dziennika.