Podatności Wazuh

Wazuh od wersji 4.1.1 do 4.14.8 zawiera podatność na przechodzenie po ścieżkach w funkcjach upload_list_file, upload_rule_file i upload_decoder_file, umożliwiającą złośliwym pracownikom klastra zapisywanie plików w dowolnych lokalizacjach. Atakujący posiadający klucz klastra mogą wysyłać żądania DistributedAPI z sekwencjami ../ w nazwach plików, omijając walidację kontrolera REST, aby zapisywać pliki jako użytkownik wazuh.

Wazuh od wersji 3.9.0 przed 4.14.8 zawiera podatność na nadpisanie dowolnych plików w funkcji MasterHandler.process_files_from_worker, umożliwiającą pracownikowi klastra nadpisanie chronionych plików mastera. Atakujący kontrolujący pracownika może wykorzystać obejście z ukośnikiem na końcu nazwy i brak egzekwowania extra_valid, aby nadpisać ossec.conf i agent.conf, osiągając zdalne wykonanie kodu jako root na menedżerze i wszystkich agentach.

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.

Wazuh w wersjach od 4.1.1 przed 4.14.8 zawiera lukę path traversal w helperze get_list_file, która pozwala złośliwym workerom klastra odczytywać dowolne pliki poprzez niezwalidowane wartości nazw plików. Atakujący posiadający klucz klastra może wysyłać żądania DistributedAPI z nazwami plików zawierającymi traversal, aby odczytać client.keys, ossec.conf z kluczem klastra oraz inne pliki czytelne dla Wazuh.

Wazuh w wersjach od 4.0.0 do 4.14.8 zawiera wyścig w ograniczaniu prób logowania, który pozwala nieuwierzytelnionym atakującym ominąć limit max_login_attempts poprzez wysyłanie równoczesnych żądań. Atakujący mogą wysyłać serie logowań do endpointów authenticate i run_as, które przechodzą kontrolę blokady przed zliczeniem nieudanych prób, umożliwiając nieograniczone zgadywanie haseł.

Wazuh w wersjach od 4.0.0 do 4.14.8 zawiera podatność ujawniania informacji, która pozwala użytkownikom z niskimi uprawnieniami (agent:read) na odzyskanie hasła rejestracji authd.pass w postaci jawnego tekstu poprzez niezasłonięty endpoint konfiguracji agenta. Atakujący posiadający domyślną rolę readonly mogą zażądać konfiguracji komponentu auth dla pseudo-agenta ID 000, aby uzyskać sekret i zarejestrować fałszywych agentów przeciwko menedżerowi.

Wazuh w wersjach od 3.12.0 do 4.14.8 zawiera przepełnienie bufora na stercie w funkcji fim_generate_alert(), gdzie rozmiar full_log jest ustalany na podstawie danych wejściowych, ale zapis ograniczony jest przez OS_MAXSTR. Zarejestrowany agent może wysłać spreparowane zdarzenie FIM syscheck, aby uszkodzić pamięć sterty menedżera i w sposób deterministyczny zawiesić wazuh-analysisd, powodując awarię wykrywania w całej flocie.

W Wazuh w wersjach 4.14.3 przed 4.14.8 oraz 4.10.4 występuje niezgodność wielkości liter między walidatorem ossec.conf a wazuh-logcollector, co pozwala obejść walidację zdalnych komend. Uwierzytelniony użytkownik z uprawnieniem manager:update_config może wstrzyknąć komendę LOG_FORMAT pisaną wielkimi literami do localfile, którą kolektor uruchamia jako root przy przeładowaniu.

Wazuh w wersjach od 4.0.0 do 4.14.8 nie unieważnia wydanych tokenów dla użytkowników run_as z zerową liczbą ról statycznych, ponieważ funkcja check_token nigdy nie sprawdza czarnej listy. Atakujący z odebranymi uprawnieniami administratora mogą nadal się uwierzytelniać i samodzielnie przypisać sobie rolę administratora, aby trwale zachować uprzywilejowany dostęp.

Wazuh w wersjach od 4.3.0 do 4.14.8 zawiera podatność umożliwiającą zdalne wykonanie kodu, gdzie zaufanie do polityki SCA jest ustalane na podstawie ścieżki pliku, a nie źródła konfiguracji. Atakujący kontrolujący menedżera może zapisać niepodpisane pliki polityk do var/incoming poprzez kanał aktualizacji i odwołać się do nich, aby wykonać sprawdzenia poleceń jako root na agentach.

Wazuh w wersjach od 4.6.0 do 4.14.8 zawiera podatność omijania uwierzytelniania, gdzie funkcja security.update_user umieszcza zabezpieczenie zarezerwowanego użytkownika i politykę haseł wewnątrz fałszywego sprawdzenia prawdziwości. Delegowany administrator użytkowników może wysłać puste hasło do punktu końcowego aktualizacji użytkownika, omijając zabezpieczenie zarezerwowanego użytkownika, aby przejąć konto superużytkownika wazuh i uwierzytelnić się pustymi poświadczeniami.

Wazuh w wersjach od 4.1.0 do 4.14.8 zawiera brak sprawdzania pochodzenia w wm_agent_upgrade, co pozwala zarejestrowanym agentom na wydawanie poleceń upgrade_custom z kontrolowaną przez atakującego ścieżką file_path. Atakujący mogą wstrzyknąć wiadomość upgrade_custom przez kanał agenta, aby odczytać dowolne pliki jako root, eksfiltrując /etc/shadow i client.keys.

Wazuh w wersjach od 4.1.1 do 4.14.8 zawiera podatność typu path traversal w handlerach list CDB get_lists() i delete_list_file(), która pozwala skompromitowanym pracownikom klastra na odczyt lub usunięcie plików mastera. Atakujący mogą wysyłać nazwy plików z sekwencjami traversal lub ścieżkami bezwzględnymi przez wewnętrzne RPC klastra, omijając walidację REST i RBAC, aby usunąć pliki takie jak rbac.db.

Wazuh w wersjach od 4.0.0 do 4.14.8 zawiera podatność obejścia autoryzacji, która pozwala niskouprzywilejowanym uwierzytelnionym użytkownikom na odczyt katalogu RBAC poprzez zapytania do niechronionych endpointów bezpieczeństwa. Atakujący mogą wysłać żądania GET /security/actions i /security/resources, które pomijają polityki RBAC wywołującego, aby zmapować uprzywilejowane akcje i endpointy w celu planowania eskalacji uprawnień.

Wazuh w wersjach od 4.1.1 do 4.14.8 zawiera podatność typu path traversal w pomocnikach delete_rule_file i delete_decoder_file, która pozwala złośliwym pracownikom klastra na usuwanie dowolnych plików poprzez niezweryfikowany parametr nazwy pliku. Atakujący posiadający klucz klastra mogą wywołać te pomocniki przez DistributedAPI z sekwencjami traversal, aby usunąć ossec.conf, client.keys lub reguły jako użytkownik wazuh.

Wazuh w wersjach od 3.9.0 do 4.14.8 zawiera niekontrolowaną ekspansję aliasów YAML w yaml2json_node, która pozwala polityce kontrolowanej przez menedżera na wyczerpanie pamięci agenta. Atakujący kontrolujący menedżera mogą wypchnąć małą politykę SCA z zagnieżdżonymi aliasami przez merged.mg, aby doprowadzić do OOM-kill wazuh-modulesd na każdym agencie w grupie.

Wazuh, open-source platforma bezpieczeństwa XDR i SIEM, w wersjach od 3.9.0 do 4.14.7 zawiera podatność w wazuh-clusterd w pliku framework/wazuh/core/cluster/common.py, gdzie bufor ładunku jest alokowany na podstawie rozmiaru zadeklarowanego w 20-bajtowym nagłówku protokołu klastra przed walidacją przez deszyfrowanie Fernet. Nieuwierzytelniony peer sieciowy może zadeklarować ładunek do 256 MiB, przerwać wysyłanie po nagłówku i utrzymać alokację do zamknięcia połączenia TCP. Nasłuch klastra nie ma limitu połączeń na źródło, co pozwala równoległym gniazdom zwielokrotnić zużycie pamięci i potencjalnie zakończyć proces klastra, zakłócając synchronizację i przekazywanie API. Problem naprawiono w wersji 4.14.7.

W platformie Wazuh od wersji 3.8.0 do 4.14.7 funkcja _getattributes() w src/os_xml/os_xml.c rekurencyjnie przetwarza każdy atrybut XML bez limitu głębokości, alokując przy tym dwa duże bufory lokalne w każdej ramce stosu. Zarejestrowany agent może wysłać zdarzenie Windows EventChannel z elementem o dużej liczbie atrybutów, wyczerpując stos wątku roboczego analysisd i powodując błąd segmentacji oraz przerwanie zbierania logów.

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.