Katalog podatności CVE

W Kibana Agent Builder występuje podatność typu Confused Deputy (CWE-441), która może prowadzić do eskalacji uprawnień. Użytkownik bez uprawnień administracyjnych, mogący edytować współdzielonego agenta, może doprowadzić do wykonania uprzywilejowanych operacji w kontekście użytkownika o wyższych uprawnieniach. Jeśli ten sam użytkownik może także tworzyć workflowy, może to skutkować pełną kontrolą administracyjną nad Kibana i klastrem Elasticsearch.

Wtyczka Groups – Memberships and Access Control dla WordPressa w wersjach do 4.6.0 włącznie jest podatna na eskalację uprawnień. Funkcja groups_join() wyznacza uprawnienia do dołączenia do grupy na podstawie uprawnień autora posta (global $post->post_author), a nie zalogowanego użytkownika, jednocześnie generując ważny hash i nonce. Uwierzytelniony atakujący z poziomem Subscriber może zapisać się do dowolnej grupy, w tym uprzywilejowanej, i ostatecznie uzyskać uprawnienia Administratora.

Rozszerzenie Joomla UP (lomart.fr) w wersjach 5.0.0-5.2.0 oraz 6.0.0-6.0.29 zawiera różne wektory path traversal i dostępu do plików. Osoba atakująca może uzyskać dostęp do plików poza zamierzonym katalogiem.

Rozszerzenie Joomla UP (lomart.fr) w wersjach 5.0.0-5.2.0 oraz 6.0.0-6.0.29 zawiera podatność na wstrzyknięcie poleceń PHP przez uwierzytelnionego użytkownika z uprawnieniami. Osoba atakująca z odpowiednimi uprawnieniami może wykonać dowolne polecenia PHP.

Rozszerzenie Joomla AcyMailing Enterprise w wersjach poniżej 11.1.0 zawiera podatność umożliwiającą zdalne wykonanie kodu w funkcji obsługi skrzynki pocztowej. Części MIME przychodzących wiadomości były zapisywane do katalogu media/com_acym/upload/ bez sprawdzania rozszerzenia, więc każdy, kto mógł wysłać e-mail na monitorowaną skrzynkę, mógł zapisać plik PHP w katalogu głównym witryny.

Rozszerzenie AcyMailing Enterprise (wersje < 11.1.0) dla Joomla zawiera podatność na nieuwierzytelnione usuwanie dowolnych plików. Subskrybent może przechowywać ścieżkę w polu niestandardowym typu plik i spowodować usunięcie tego pliku przez AcyMailing po wyczyszczeniu pola, w tym plików poza folderem upload, takich jak configuration.php.

Froxlor 2.0.0 do 2.3.10 jest podatny na przechowywany cross-site scripting. Gdy klient (najniżej uprzywilejowana rola) przesyła certyfikat SSL dla własnej domeny, metody add()/update() API Certificates parsują go funkcją openssl_x509_parse() i przechowują wartość issuer organization bez sanityzacji. Renderer tabel Froxlor emituje komórki skalarne przez filtr `raw` Twig, wyłączając automatyczne escapowanie HTML, więc gdy administrator lub reseller otworzy Domeny > Certyfikaty SSL, wartość issuer dostarczona przez atakującego wykonuje się jako skrypt w sesji uprzywilejowanego użytkownika. Problem przekracza granicę uprawnień od klienta do administratora i może prowadzić do pełnego przejęcia konta administratora; ponieważ administrator Froxlor kontroluje serwer WWW, DNS i konfigurację PHP stosowaną przez cron działający jako root, problem może być dalej eskalowany do wykonania poleceń jako root na zarządzanym serwerze. Problem naprawiono w Froxlor 2.3.12.

Froxlor do wersji 2.3.10 nie egzekwuje polityki mail.allow_external_domains w poleceniu API EmailSender.add. Gdy administrator włączył funkcję dozwolonych nadawców, ale wyłączył zewnętrzne domeny (mail.enable_allow_sender = 1, mail.allow_external_domains = 0), uwierzytelniony klient z dostępem do API może nadal użyć EmailSender.add do zarejestrowania dowolnego zewnętrznego adresu nadawcy dla swojej skrzynki, który jest przechowywany mimo polityki. Tworzy to obejście między konfiguracją UI/administratora a API i — tam gdzie wygenerowana konfiguracja poczty korzysta z tabeli dozwolonych nadawców — umożliwia klientowi autoryzację tożsamości nadawcy spoza hostowanych domen, ułatwiając podszywanie się pod nadawcę. Naprawiono w wersji 2.3.12.

Froxlor 2.3.10 i wcześniejsze zawierają wyścig TOCTOU w synchronizacji kluczy SSH (lib/Froxlor/Cron/System/SshKeys.php, SshKeys::generateFiles). Walidacja zawartości/symlinków wykonywana przez FileDir::makeCorrectDir()/makeCorrectFile() jest tylko w czasie sprawdzenia; ścieżka pliku jest ponownie rozwiązywana jako root w czasie zapisu, bez przypinania ścieżki lub deskryptora pliku. Na instalacjach z włączonym system.allow_customer_shell=1, klient może podmienić swój katalog ~/.ssh na symlink po sprawdzeniu, co powoduje, że cron działający jako root dopisuje klucz publiczny klienta do /root/.ssh/authorized_keys i zmienia właściciela /root/.ssh na klienta, prowadząc do pełnego przejęcia hosta panelu. Naprawiono w Froxlor 2.3.12.

Froxlor przed wersją 2.3.12 nie unieważnia istniejących sesji panelu, kluczy API i ciasteczek zaufania 2FA po zmianie hasła użytkownika. Atakujący posiadający przejęte sesje, ważne klucze API lub tokeny zaufania 2FA zachowują pełny dostęp do konta po rotacji hasła, omijając działania związane z reagowaniem na incydenty.

Froxlor do 2.3.10 przechowuje w tokenach remembered-2FA (panel_2fa_tokens) tylko numeryczny identyfikator użytkownika bez przestrzeni nazw konta, a wyszukiwanie tokena przy logowaniu nie jest ograniczone do typu konta klienta lub administratora. Ponieważ identyfikatory klientów i administratorów pochodzą z oddzielnych przestrzeni, token wystawiony klientowi o danym ID pasuje także do administratora o tym samym ID, co pozwala obejść drugi składnik TOTP administratora przy znanym haśle.

Froxlor przed wersją 2.3.13 zwraca kolumnę ssl_key_file — która przechowuje surową zawartość prywatnego klucza TLS w formacie PEM — bezpośrednio w odpowiedziach JSON poleceń API Certificates.get i Certificates.listing, ponieważ wyniki zapytań domain_ssl_settings są przekazywane przez ApiCommand::response() bez żadnego usuwania pól ani listy dozwolonych. Nisko uprzywilejowany uwierzytelniony klient API może pobrać klucze prywatne certyfikatów swoich domen, w tym klucze Let's Encrypt generowane przez Froxlor po stronie serwera i przechowywane z uprawnieniami root-only (0600), do których klient nie ma dostępu do systemu plików; konta reseller i customers_see_all admin mogą zrzucić klucze prywatne innych podmiotów przez ten sam mechanizm. Ujawnione klucze umożliwiają podszywanie się pod domenę, pasywne deszyfrowanie przechwyconego ruchu TLS oraz aktywne ataki typu man-in-the-middle.

Kyverno w wersjach przed 1.19.1 zawiera lukę pozwalającą na obejście izolacji przestrzeni nazw w wpisie kontekstu apiCall dla zasobów Policy z ograniczeniem do namespace. Wynika to z niespójnej interpretacji ścieżek między walidacją a wykonaniem. Użytkownik o niskich uprawnieniach może użyć procentowo zakodowanych segmentów kropek w urlPath, aby ominąć sprawdzanie przestrzeni nazw i odczytać zasoby z innych namespace przy użyciu poświadczeń ServiceAccount kontrolera Kyverno.

Kyverno przed wersją 1.19.1 jest podatny na SSRF. Domyślna lista blokowania egress (169.254.169.254, 169.254.169.253, metadata.google.internal, 127.0.0.0/8, ::1/128) i kontrola tokenów z ograniczonym zakresem były podłączone tylko do nowej biblioteki CEL http.Get/Post, ale nie do starszego executor usług apiCall (pkg/engine/apicall/executor.go) ani do ścieżki GlobalContextEntry external-API. Te ścieżki używają zwykłego klienta net/http bez filtrowania egress i bez walidacji adresu URL usługi, co pozwala autorowi ClusterPolicy lub GlobalContextEntry (lub osobie przesyłającej zasoby, jeśli polityka używa szablonu URL) na wysyłanie żądań GET/POST do dowolnego hosta, w tym do punktu metadanych chmury, loopback i usług wewnątrz klastra. Executor bezwarunkowo dołącza token ServiceAccount Kyverno do wybranego przez atakującego miejsca docelowego. Naprawiono w wersji 1.19.1.

Kyverno to silnik polityk dla Kubernetes. W wersjach od 1.14.0 do 1.19.0 evaluator ImageValidatingPolicy nigdy nie odczytuje pól spec.images i spec.allowedValues z PolicyException. Każdy PolicyException, którego policyRefs i matchConditions pasują do zasobu, powoduje pominięcie weryfikacji podpisu obrazu dla całego zasobu, a nie tylko dla wymienionych obrazów lub wartości. W rezultacie niepodpisane lub niezaufane obrazy mogą być dopuszczone do klastra bez weryfikacji podpisu. Różni się to od ValidatingPolicy, GeneratingPolicy i MutatingPolicy, które traktują to samo pole jako częściowe wyłączenie. Problem naprawiono w wersji 1.19.1.

Kyverno w wersjach od 1.16.0 do 1.19.0 rejestruje bibliotekę globalcontext.Lib CEL w środowisku polityk bez ograniczania jej do przestrzeni nazw polityki, w przeciwieństwie do bibliotek pokrewnych, które otrzymują przestrzeń nazw polityki. Tenant mogący tworzyć polityki z ograniczeniem do namespace w swoim namespace może wywołać globalContext.get("<entry>", "") i otrzymać pełną zawartość buforowanego GlobalContextEntry o zasięgu klastra, w tym dane z przestrzeni nazw, do których tenant nie ma uprawnień RBAC. Brak walidacji przyjęcia odrzucającej takie wywołania. Naprawiono w 1.19.1.

nodemailer w wersjach przed 10.0.6 zawiera podatność typu denial of service w wyrażeniu regularnym fallbacku free-text parsera adresów, które wykazuje kwadratowe zachowanie backtrackingu. Atakujący mogą dostarczyć spreparowane wartości nagłówków e-mail z długimi ciągami bez spacji, aby zablokować pętlę zdarzeń Node.js na dziesiątki sekund, powodując niedostępność usługi.

Adminer w wersjach od 6.0.0 do 6.0.1, gdy załadowany jest oficjalny plugin sterownika ClickHouse, jest podatny na podatność Server-Side Request Forgery przed uwierzytelnieniem. Nieuwierzytelniony atakujący może przesłać auth[driver]=clickhouse z auth[server] ustawionym na dowolny URL, powodując, że serwer Adminer wyśle żądanie HTTP POST zawierające 'SELECT version()' do tego hosta. W rootQuery(), jeśli cel zwróci status poza 200-299 (inny niż 401/403), surowe ciało odpowiedzi HTTP jest przypisywane do błędu połączenia i renderowane na stronie logowania, więc atakujący otrzymuje pełne ciało odpowiedzi wewnętrznej usługi. Umożliwia to rozpoznanie wewnętrznej sieci/portów i ujawnienie poufnych informacji zawartych w wewnętrznych stronach błędów. Naprawiono w Adminer 6.0.2.

Hugo w wersjach od v0.162.0 do v0.166.0 zawiera błąd walidacji z rozróżnianiem wielkości liter w regule blokowania adresów IP w security.http.urls, co pozwala atakującym obejść ograniczenia. Atakujący mogą użyć mieszanych wielkości liter w schematach URL w wywołaniach resources.GetRemote, aby pobierać dane z zastrzeżonych adresów IP, takich jak localhost.

Hugo, generator statycznych stron, w wersjach po v0.123.0 i przed v0.166.0, ma wadę w sprawdzaniu ograniczeń dowiązań symbolicznych (symlink confinement). Motyw lub moduł w themes/ (lub vendorowany moduł) może zawierać dowiązanie symboliczne w punkcie montowania (np. themes/mytheme/assets -> /some/dir/outside), co pozwala na odczyt plików spoza dozwolonych ścieżek podczas budowania strony oraz publikowanie ich do public/ przez statyczne montowania, omijając zasadę, że źródła montowania motywów i modułów muszą być lokalnymi ścieżkami.