Katalog podatności CVE

Wazuh to darmowa platforma open source używana do zapobiegania, wykrywania i reagowania na zagrożenia. Od wersji 4.6.0 do 4.14.6 oraz 5.0.0-beta3, funkcje DB::getFile() i DB::searchFile() w src/syscheckd/src/db/src/file.cpp łączą ścieżkę monitorowanego pliku z filtrami wierszy SQLite. Na systemach innych niż Windows, FIMDBCreator::encodeString() nie escapuje wartości. Lokalny użytkownik, który może utworzyć nazwę pliku w katalogu monitorowanym przez FIM, może wstrzyknąć wyrażenie UNION SELECT, gdy wazuh-syscheckd przetwarza lub usuwa tę ścieżkę. Potwierdzony prymityw manipuluje zestawami wyników SELECT używanymi przez kod FIM; nie wykazano instrukcji skumulowanych ani zdalnego wykonania kodu. Problem naprawiono w wersjach 4.14.6 i 5.0.0-beta3.

W platformie Wazuh od wersji 4.0.0 do 4.14.6 oraz 5.0.0-beta3, funkcja DistributedAPI.send_tmp_file() w framework/wazuh/core/cluster/dapi/dapi.py łączy kontrolowaną przez atakującego wartość tmp_file z WAZUH_PATH bez kanonizacji lub ograniczenia. Peer klastra posiadający wspólny klucz Fernet może użyć traversal lub ścieżki bezwzględnej, aby zmusić mastera do zwrócenia dowolnego czytelnego pliku przez kanał klastra. Odczytanie /var/ossec/api/configuration/security/private_key.pem pozwala na sfałszowanie tokenów administratora REST API i wykonywanie uprawnień administracyjnych bez tworzenia konta.

W platformie Wazuh od wersji 4.0.0 do 4.14.6 oraz 5.0.0-beta3, funkcja cluster.unmerge_info() w framework/wazuh/core/cluster/cluster.py konstruuje ścieżki z kontrolowanych przez peera wartości merge_type i name w scalonym archiwum synchronizacji. Funkcja process_files_from_worker() w framework/wazuh/core/cluster/master.py nie ogranicza odpowiednio wynikowej ścieżki do zadeklarowanego katalogu elementu klastra. Peer klastra posiadający wspólny klucz Fernet może użyć traversal w files_metadata.json lub nagłówku scalonego pliku, aby zapisać pliki takie jak /var/ossec/etc/ossec.conf, co może prowadzić do wykonania kodu po przeładowaniu usług Wazuh.

Wazuh to darmowa platforma open source używana do zapobiegania, wykrywania i reagowania na zagrożenia. Od wersji 4.5.0 do 4.14.6 i 5.0.0-beta2, funkcja compare_wazuh_versions() w src/shared/version_op.c kopiuje kontrolowane przez atakującego pole V z rejestracji do 10-bajtowego bufora na stosie za pomocą strncpy(), ale nie kończy jawnie bufora. Funkcja jest osiągalna przed uwierzytelnieniem przez wazuh-authd na porcie TCP 1515, gdy włączone jest anonimowe uwierzytelnianie TLS. Ciąg wersji o długości co najmniej dziewięciu niezerowych bajtów może spowodować, że strchr() i strtok() będą czytać poza ver2 i mogą sprawić, że strtok() zapisze bajt zerowy do sąsiedniej pamięci stosu, umożliwiając zdalną odmowę usługi. Problem został naprawiony w wersjach 4.14.6 i 5.0.0-beta2.

Wazuh od wersji 4.0.0 do 4.14.6 oraz 5.0.0-beta2 zawiera podatność w funkcji AffectedItemsWazuhResult.merge() w framework/wazuh/core/results.py, która ufa polu sort_casting w odpowiedzi JSON od pracownika klastra. Podczas scalania odpowiedzi API, nazwy typów kontrolowane przez atakującego są rozwiązywane przez wbudowane funkcje Pythona bez listy dozwolonych. Zainfekowany pracownik może ustawić sort_casting na exec i umieścić kod Pythona w affected_items, co powoduje wykonanie kodu przez mastera jako root podczas scalania odpowiedzi z wielu węzłów. Problem został naprawiony w wersjach 4.14.6 i 5.0.0-beta2.

Wazuh to darmowa platforma open source używana do zapobiegania, wykrywania i reagowania na zagrożenia. Od wersji 4.4.0 do 4.14.6 oraz 5.0.0-beta2, api/api/middlewares.py dekoduje nazwę użytkownika Basic authentication przed weryfikacją poświadczeń i przekazuje ją do loggera dostępu bez neutralizowania znaków kontrolnych. api/api/alogging.py interpoluje tę wartość do logu API w formacie tekstowym. Nieuwierzytelniony atakujący może umieścić znaki powrotu karetki lub nowej linii w nazwie użytkownika, aby sfałszować wpisy, ukryć aktywność lub zatruć systemy konsumujące tekstowy log audytowy. Format logu JSON nie jest dotknięty, ponieważ serializacja JSON escapuje te znaki. Problem naprawiono w wersjach 4.14.6 i 5.0.0-beta2.

Wazuh to darmowa platforma open source używana do zapobiegania, wykrywania i reagowania na zagrożenia. Od wersji 4.0.0 do 4.14.6 oraz 5.0.0-beta2, AuthenticationManager.check_user() w framework/wazuh/rbac/orm.py wykonuje check_password_hash() tylko wtedy, gdy podana nazwa użytkownika istnieje. Nieistniejąca nazwa użytkownika zwraca natychmiast, podczas gdy prawidłowa nazwa powoduje kosztowne obliczenie bcrypt. Nieuwierzytelniony zdalny atakujący może porównać czasy odpowiedzi uwierzytelniania, aby wyliczyć prawidłowe nazwy użytkowników Wazuh i wykorzystać te informacje w późniejszych atakach na poświadczenia. Problem naprawiono w wersjach 4.14.6 i 5.0.0-beta2.

Wazuh od wersji 4.9.0 do 4.10.4 oraz 4.14.6 zawiera podatność w punkcie końcowym PUT /security/users/{user_id} w api/api/controllers/security_controller.py, gdzie przekazywany jest request.get("user") zamiast request.context['token_info']['sub'] jako current_user. Funkcja remove_nones_to_dict() usuwa wynikową wartość None, więc ochrona kont zarezerwowanych w framework/wazuh/security.py nie może zweryfikować, kto wykonuje żądanie. Uwierzytelniony użytkownik z rolą users_admin może nadpisać hasło chronionych kont administratora o identyfikatorach do 99, w tym superużytkownika wazuh, i uzyskać pełną kontrolę administracyjną. Problem został naprawiony w wersjach 4.10.4 i 4.14.6.

Podatność w Cisco Crosswork związana z niewystarczającą ochroną poświadczeń (CWE-522). Została wykryta podczas wewnętrznego przeglądu bezpieczeństwa i zaadresowana w wydaniu wzmacniającym oprogramowanie.

Podatność w Cisco Crosswork związana z zewnętrzną kontrolą systemu plików (CWE-73). Wykryta podczas wewnętrznego przeglądu bezpieczeństwa, naprawiona w wydaniu wzmacniającym.

Podatność w Cisco Crosswork polegająca na braku uwierzytelnienia dla krytycznych funkcji (CWE-306). Wykryta podczas wewnętrznego przeglądu bezpieczeństwa, naprawiona w wydaniu wzmacniającym.

Podatność w interfejsie zarządzania opartym na sieci Cisco Unified Intelligence Center może pozwolić uwierzytelnionemu lokalnemu atakującemu na przeprowadzenie ataku blind SQL injection na dotknięte urządzenie. Podatność wynika z niewystarczającej walidacji danych wprowadzanych przez użytkownika. Atakujący może wykorzystać tę podatność, wysyłając spreparowane żądanie do interfejsu zarządzania. Udany atak może pozwolić atakującemu na odczytanie zawartości wewnętrznej bazy danych urządzenia. Aby wykorzystać podatność, atakujący musi mieć prawidłowe poświadczenia użytkownika na urządzeniu.

Podatność w parserze XML Open Client Interface (OCI) w Cisco BroadWorks umożliwia nieuwierzytelnionemu, zdalnemu atakującemu odczyt wrażliwych informacji konfiguracyjnych. Problem wynika z nieprawidłowego parsowania wpisów XML z powodu domyślnego zezwolenia na rozwiązywanie encji zewnętrznych. Atakujący może wysłać spreparowaną wiadomość XML do usługi OCI-P, co pozwala na odczyt wrażliwych plików z systemu plików z uprawnieniami użytkownika Cisco BroadWorks.

Cisco Secure Workload zawiera wiele podatności związanych z zarządzaniem buforami, sklasyfikowanych jako CWE-119. Zostały one wykryte podczas wewnętrznego przeglądu bezpieczeństwa i zaadresowane w wydaniu wzmacniającym oprogramowanie.

Podatność w Cisco Secure Workload związana z nieprawidłową walidacją danych wejściowych (CWE-20). Wykryta podczas wewnętrznego przeglądu bezpieczeństwa, naprawiona w wydaniu wzmacniającym.

Podatność w Cisco Secure Workload związana z nieprawidłowym uwierzytelnianiem (CWE-287). Wykryta podczas wewnętrznego przeglądu bezpieczeństwa, naprawiona w wydaniu wzmacniającym.

Podatność w Cisco Secure Workload związana z nieprawidłową kontrolą dostępu (CWE-284). Wykryta podczas wewnętrznego przeglądu bezpieczeństwa, naprawiona w wydaniu wzmacniającym.

Podatność w Cisco Packaged Contact Center Enterprise (Packaged CCE) i Cisco Unified Contact Center Enterprise (Unified CCE) może pozwolić uwierzytelnionemu zdalnemu atakującemu na przeprowadzenie ataków typu server-side request forgery (SSRF) przez dotknięte urządzenie. Podatność wynika z nieprawidłowej walidacji danych wejściowych dla określonych żądań HTTP. Atakujący może wykorzystać tę podatność, wysyłając spreparowane żądanie HTTP do urządzenia. Udany atak może pozwolić atakującemu na wysyłanie dowolnych żądań sieciowych pochodzących z urządzenia. Aby wykorzystać podatność, atakujący musi mieć prawidłowe poświadczenia użytkownika na urządzeniu.

Podatność w sterowniku USB Cisco RoomOS pozwala nieuwierzytelnionemu atakującemu z fizycznym dostępem do portu USB na wykonanie dowolnego kodu z uprawnieniami root. Problem wynika z niewystarczających kontroli granicznych dla danych przekazywanych przez sterownik USB, co może prowadzić do przepełnienia bufora.

Podatność w interfejsie zarządzania opartym na sieci w przełącznikach Cisco Industrial Ethernet 1000 Series umożliwia uwierzytelnionemu zdalnemu atakującemu przeprowadzenie ataku typu stored XSS. Problem wynika z niewystarczającej walidacji danych wejściowych, co pozwala na wstrzyknięcie złośliwego kodu do stron interfejsu.