Podatności Wazuh

Wazuh w wersjach 4.4.0 do 4.14.6 zawiera podatność, która pozwala posiadaczowi klucza klastra na zapisywanie, nadpisywanie lub usuwanie dowolnych plików w katalogu /var/ossec na węzłach roboczych, co może prowadzić do zdalnego wykonania kodu jako root. Problem wynika z niepełnej weryfikacji ścieżek podczas synchronizacji plików klastra. Luka została naprawiona w wersji 4.14.7.

W platformie Wazuh od wersji 4.3.0 do 4.14.6 oraz 5.0.0-beta3, funkcja process_files_from_worker() w framework/wazuh/core/cluster/master.py ufa kontrolowanemu przez peera kluczowi file_path z pliku files_metadata.json. Ścieżka docelowa jest łączona z WAZUH_PATH bez sprawdzenia, czy pozostaje w wybranym katalogu. Peer klastra posiadający wspólny klucz Fernet może przesłać spreparowane archiwum i nadpisać wrażliwe pliki, takie jak /var/ossec/etc/ossec.conf, co może prowadzić do wykonania kodu po przeładowaniu usług.

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.

Workflows Wazuh przed commit 44bf114 zawierają podatność na wstrzyknięcie poleceń powłoki w GitHub Actions, która umożliwia atakującym wykonanie dowolnych poleceń poprzez przesłanie pull requestów ze spreparowanymi plikami VERSION.json. Atakujący mogą wstrzyknąć metaznaki powłoki do zmiennych środowiskowych, które są bezpośrednio interpolowane w krokach run, umożliwiając wykonanie poleceń i eksfiltrację sekretów, w tym GITHUB_TOKEN i poświadczeń AWS na samoobsługowych runnerach.

W Wazuh w wersjach 4.14.0 do 4.14.6, użytkownik API z niskimi uprawnieniami może odczytać klucz klastra w postaci jawnego tekstu z punktu końcowego konfiguracji, który nie maskuje go. Punkt końcowy GET /cluster/local/config zwraca konfigurację klastra lokalnego węzła, w tym klucz w postaci jawnej, podczas gdy inne punkty końcowe zwracają tę samą wartość zamaskowaną. Każde konto z domyślną rolą readonly lub cluster_readonly, które jest jawnie pozbawione uprawnień update-config, otrzymuje prawdziwy klucz klastra.

Wazuh w wersjach 4.14.0 do 4.14.6 umożliwia uwierzytelnionemu użytkownikowi o niskich uprawnieniach odczytanie sekretu klastra z konfiguracji menedżera. Dzieje się tak, ponieważ logika maskująca wrażliwe wartości jest wyłączana przez dowolną regułę RBAC typu update-config, nawet jeśli jest to reguła deny.

Wazuh w wersjach 4.2.0 do 4.14.6 ma wiele skryptów aktywnej odpowiedzi, które przekazują pola alertów kontrolowane przez atakującego do uprzywilejowanych poleceń systemowych bez walidacji formatu, umożliwiając wstrzykiwanie argumentów do narzędzi działających jako root.

Wazuh w wersjach 4.0.0 do 4.14.6 jest podatny na atak polegający na tym, że złośliwy menedżer rejestracji może doprowadzić do awarii agenta podczas rejestracji, zwracając odpowiedź z mniej niż czterema polami, co powoduje dereferencję wskaźnika NULL. Problem naprawiono w wersji 4.14.7.

Skrypt aktywnej odpowiedzi ip-customblock w Wazuh zawiera podatność na path traversal, która pozwala atakującemu tworzyć lub usuwać dowolne pliki w systemie jako root. Skrypt nie waliduje poprawności adresu IP w polu srcip, co umożliwia użycie sekwencji ../ do wyjścia poza katalog bazowy.

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.

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.

Wazuh od wersji 4.0.0 do 4.14.6 oraz 5.0.0-beta2 zawiera podatność w funkcji WazuhCommon.end_receiving_file() w framework/wazuh/core/cluster/common.py, która pozwala uwierzytelnionemu węzłowi klastra na usuwanie plików poza ścieżką WAZUH_PATH. Żądanie syn_i_w_m_e z nieznanym task_id dociera do gałęzi czyszczącej, gdzie nazwa pliku kontrolowana przez atakującego jest przekazywana do os.path.join bez kanonizacji lub ograniczeń. Ścieżki bezwzględne i sekwencje traversal mogą celować w pliki takie jak ossec.conf, jwt_secret.json, certyfikaty TLS i pliki reguł, które są dostępne dla procesu menedżera Wazuh. Usunięcie może wyłączyć menedżera, unieważnić tokeny API lub zakłócić łączność klastra i API. Problem naprawiono w wersjach 4.14.6 i 5.0.0-beta2.

W Wazuh od wersji 1.0.0 do 4.14.6 oraz 5.0.0-beta2 występuje podatność polegająca na zapisie poza granicami bufora na stosie w funkcji HandleSecureMessage(). Podczas przetwarzania zaszyfrowanej wiadomości agenta na porcie TCP 1514, dekompresja może zapisać bajt null poza końcem bufora docelowego, co prowadzi do awarii procesu remoted i zakłócenia komunikacji z agentami.

W Wazuh od wersji 3.9.0 do 4.14.5 oraz 5.0.0-beta2 protokół klastra pozwala uwierzytelnionemu węzłowi klastra na wyczerpanie pamięci na serwerze głównym. Metoda receive_str() akceptuje kontrolowaną przez atakującego wartość całkowitą bez limitu, a ścieżka podzielonych wiadomości przechowuje fragmenty bez ograniczeń, co może prowadzić do nadmiernego zużycia pamięci.

Wazuh Manager od wersji 4.0.0 do 4.14.5 pozwala użytkownikowi API o niskich uprawnieniach (tylko do odczytu) z uprawnieniem manager:read na pobranie klucza klastra z elementu w ossec.conf przez GET /manager/configuration?raw=true. Atakujący z dostępem sieciowym do portu TCP 1516 może użyć ujawnionego klucza Fernet do podszycia się pod pracownika klastra i wysyłać rozproszone żądania API z kontrolowanymi rbac_permissions i rbac_mode ustawionym na black. Ponieważ master ufa kontekstowi autoryzacji dostarczonemu przez pracownika, atakujący może tworzyć użytkowników, przypisywać role administratora, uzyskiwać dostęp do poświadczeń i tokenów API, modyfikować konfigurację i wykonywać akcje na agentach. Problem naprawiono w wersji 4.14.5.

Wazuh 4.4.0 przed wersją 4.14.7 zawiera podatność na odmowę usługi w funkcji fdecompress_files() w cluster.py. Uwierzytelnieni członkowie klastra mogą wyczerpać pamięć, dostarczając złośliwe archiwum synchronizacji bez ograniczeń rozmiaru po dekompresji. Atakujący z ważnym kluczem Fernet może przesłać małe, mocno skompresowane archiwum zip bomb, które zmusza wazuh-clusterd na węźle głównym do dekompresji pełnej zawartości do pamięci, powodując wyczerpanie pamięci i przerwanie usługi.

Wazuh 4.0.0 do 4.14.6 zawiera podatność na przechodzenie po ścieżkach, która pozwala uwierzytelnionym węzłom klastra na usuwanie zawartości dowolnych katalogów poprzez podanie nazwy węzła zawierającej sekwencje przechodzenia w ładunku hello klastra bez walidacji. Atakujący posiadający ważny klucz Fernet klastra może stworzyć złośliwą nazwę węzła i rozłączyć się, wyzwalając procedurę czyszczenia peerów przez master, co usuwa zawartość katalogów w ścieżce instalacji Wazuh zapisywalnej przez użytkownika wazuh.

Wazuh 4.0.0 do 4.14.7 oraz 5.0.0-beta2 zawierają podatność na odmowę usługi, która pozwala uwierzytelnionym atakującym z włączoną opcją allow_run_as na wyczerpanie zasobów CPU poprzez przesyłanie arbitralnie głęboko zagnieżdżonych struktur JSON do punktu końcowego POST /security/user/authenticate/run_as. Atakujący mogą wielokrotnie przesyłać nieprawidłowe ciała auth_context z nieograniczoną głębokością zagnieżdżenia, powodując nadmierne zużycie CPU przez framework API i odmowę usługi dla innych konsumentów API.

Wazuh 4.0.0 przed 4.14.6 zawiera podatność typu path traversal, która pozwala nieuwierzytelnionym zdalnym atakującym na spowodowanie odmowy usługi poprzez rejestrację agenta z nazwą zawierającą sekwencję kropek, np. "..", przez port rejestracji. Atakujący wykorzystują niewystarczającą walidację w OS_IsValidName() i niebezpieczną konkatenację ścieżek w delete_diff(), co prowadzi do usunięcia podkatalogów katalogu kolejki i zatrzymania wszystkich usług Wazuh.

Wazuh 5.0.0-beta1 (poprawione w 5.0.0-beta3) nie waliduje ani nie nadpisuje pól cluster_name i cluster_node w komunikatach FlatBuffer inventory-sync Start, walidując jedynie agentid względem uwierzytelnionej tożsamości agenta. Umożliwia to niskouprzywilejowanemu zarejestrowanemu agentowi fałszowanie atrybucji klastra w indeksowanych dokumentach inwentarza i podatności poprzez fałszowanie wartości wazuh.cluster.name i wpływanie na prefiks _id dokumentu, potencjalnie manipulując rekordami inwentarza lub, w przypadku wdrożeń z wieloma klastrami współdzielącymi indeksator, zatruwając rekordy innego klastra przy kolizji numerycznych identyfikatorów agentów.

W Wazuh przed wersją 4.14.5 występują podatności w obsłudze klastrowego API (DAPI), które pozwalają uwierzytelnionemu węzłowi klastra lub atakującemu z kluczem klastra na deserializację złośliwego obiektu i wykonanie go w kontekście RBAC kontrolowanym przez atakującego, co umożliwia pełne przejęcie menedżera.

W Wazuh w wersjach od 3.0.0 do 4.14.4 wykryto podatność polegającą na niedomiarze liczby całkowitej typu size_t w funkcji os_crypto/shared/msgs.c:389. Umożliwia ona dowolnemu uwierzytelnionemu agentowi Wazuh spowodowanie awarii procesu wazuh-remoted na menedżerze, co natychmiast rozłącza wszystkich agentów.

W Wazuh w wersjach od 4.6.0 do 4.14.4 wykryto podatność przepełnienia bufora sterty w komponencie syscheck agenta dla systemu Windows. Podczas rozwijania ścieżek rejestru zawierających symbole wieloznaczne (* lub ?) agent alokuje stały bufor o rozmiarze 256 bajtów, co przy odpowiednio długiej nazwie podklucza rejestru (do 255 znaków) prowadzi do zapisu poza przydzielonym obszarem pamięci.

W Wazuh w wersjach od 1.0.0 do 4.14.4 wykryto podatność na przepełnienie sterty w komponencie wazuh-analysisd. Nieuwierzytelniony atakujący może zdalnie wykorzystać domyślną konfigurację, aby wysłać spreparowane zdarzenia rootcheck, powodując przepełnienie bufora i zatrzymanie silnika analizy. Prowadzi to do całkowitej utraty przetwarzania alertów SIEM, podczas gdy panel i API nadal wyświetlają nieaktualne dane.

W Wazuh w wersjach od 3.9.0 do 4.14.4 wykryto podatność na zdalne wyczerpanie pamięci. Atakujący może wysłać spreparowany nagłówek protokołu klastra z dowolnie dużą długością ładunku, co prowadzi do alokacji pamięci przed uwierzytelnieniem i deszyfrowaniem.

W Wazuh w wersjach 4.6.0 do 4.14.4 wykryto błąd logiczny w mechanizmie ograniczania szybkości żądań. Powoduje on, że punkt końcowy /events ignoruje globalny limit żądań na minutę, jeśli nie został przekroczony limit specyficzny dla zdarzeń (30/min). Umożliwia to wstrzykiwanie zdarzeń do analizatora (analysisd) ponad skonfigurowany przez administratora globalny limit.

To CVE zostało odrzucone przez CNA. Zgodnie z polityką bezpieczeństwa Wazuh, podatności dotyczące tylko wersji nie-GA nie kwalifikują się do nadania numeru CVE.