Podatności OpenBao

OpenBao to system zarządzania sekretami oparty na tożsamości. W wersjach przed 2.5.3, gdy usunięcie początkowej przestrzeni nazw nie powiedzie się, kolejne próby nie usuwają poprawnie wszystkich danych przed oznaczeniem przestrzeni jako usuniętej.

OpenBao to system zarządzania sekretami oparty na tożsamości. Przed wersją 2.6.0, ścieżka handleLogicalRecovery w http/logical.go porównywała token odzyskiwania o wysokich uprawnieniach ze zwykłym porównaniem równości łańcuchów. Zdalny nieuwierzytelniony atakujący, który może wysyłać powtarzane żądania trybu odzyskiwania i mierzyć czas odpowiedzi, może wywnioskować token odzyskiwania. Odzyskany token może następnie autoryzować operacje trybu odzyskiwania, które odczytują lub modyfikują dane OpenBao. Problem został naprawiony w wersji 2.6.0.

OpenBao przed wersją 2.5.2 nie wymaga potwierdzenia użytkownika podczas logowania przez JWT/OIDC z rolą ustawioną na `callback_mode=direct`. Pozwala to atakującemu na zdalny phishing poprzez nakłonienie ofiary do odwiedzenia URL i automatyczne zalogowanie jej do sesji atakującego.

OpenBao od 2.5.0 przed 2.6.2 nie egzekwuje ograniczenia allowed_ip_sans_cidr roli PKI na IP SAN pobranych z CSR, gdy włączone jest use_csr_sans. Uwierzytelnieni wywołujący z uprawnieniem sign mogą przesłać CSR z IP SAN spoza zakresu do pki/sign/<role> i uzyskać certyfikaty podpisane przez CA dla nieautoryzowanych adresów IP.

OpenBao od 2.3.0 przed 2.6.3 zawiera podatność na nieprawidłową autoryzację, która pozwala tokenom uprzywilejowanego namespace podrzędnego modyfikować rejestracje pluginów, ponieważ /v1/sys/plugins/catalog/* nie jest ograniczone do głównego namespace. Atakujący mogą usuwać istniejące rejestracje, tworzyć nieprawidłowe lub rejestrować zainstalowane pluginy przez sys/ mount namespace podrzędnego, powodując odmowę usługi.

Podatność nieprawidłowej autoryzacji w pamięci podręcznej polityk ACL OpenBao pozwala tokenom odwoływać się do polityk z dowolnych przestrzeni nazw przy użyciu specjalnie spreparowanych nazw polityk. Osoba atakująca posiadająca takie tokeny może uzyskać uprawnienia z pamięci podręcznej polityk w innych przestrzeniach nazw, w tym w przestrzeni root, i działać poza granicami przestrzeni nazw.

OpenBao przed 2.6.3 zawiera brak sprawdzenia autoryzacji, który pozwala atakującym zatrzymać usługi Agent i Proxy poprzez pominięcie nagłówka X-Vault-Header. Gdy włączone jest require_request_header, atakujący mogą wysyłać żądania przez server-side request forgery do /agent/v1/quit lub /proxy/v1/quit, aby wyłączyć te usługi.

OpenBao 2.2.0 przed 2.6.4 oraz 2.7.0 przed 2.7.1 zawiera podatność na ujawnienie informacji, która eksponuje wartość tls_acme_eab_mac_key przez endpoint sys/config/state/sanitized. Wywołujący oczyszczony endpoint konfiguracji mogą pobrać klucz MAC ACME External Account Binding używany dla certyfikatów listenera TLS, pozwalając im powiązać się z kontem ACME operatora.

OpenBao przed 2.6.4 oraz 2.7.x przed 2.7.1 nie sprawdza wygaśnięcia Secret ID przy użyciu w metodzie uwierzytelniania AppRole, pozostawiając wygasłe Secret ID ważne do czasu usunięcia ich przez okresowe tidy. Atakujący posiadający wygasły, nieposprzątany Secret ID może się zalogować i uzyskać dostęp poza jego TTL.

Podatność obejścia ACL w OpenBao powoduje ciche pomijanie jawnych reguł odmowy opartych na zabronionych szablonach metadanych tożsamości w ramach uprawnień z symbolami wieloznacznymi. Osoba atakująca, której metadane tożsamości zawierają symbole wieloznaczne lub segmenty ścieżek, może uzyskać dostęp do ścieżek, które powinny być zablokowane w szerszym zakresie uprawnień z symbolami wieloznacznymi.

Podatność otwartego przekierowania w dostawcy tożsamości OIDC interfejsu OpenBao dotyczy użytkowników nieuwierzytelnionych w OpenBao. Osoba atakująca może tworzyć linki OIDC przekierowujące nieuwierzytelnionych użytkowników do celów kontrolowanych przez atakującego, umożliwiając phishing lub kradzież danych uwierzytelniających.

OpenBao przed 2.6.4 oraz 2.7.x przed 2.7.1 zawiera wadę w podsystemie limitów szybkości, gdzie rozwiązywanie roli zawodzi dla żądań z ciałami form-encoded lub przekazanymi certyfikatami, więc reguły kwot ograniczone do ról specyficznych dla backendu nie są egzekwowane. Ważni wywołujący mogą wielokrotnie wystawiać tokeny bez zużywania skonfigurowanego budżetu limitu opartego na rolach.

OpenBao przed 2.6.3 zawiera podatność na ujawnienie informacji, która pozwala atakującym wyciekać poufne dane do logów audytu poprzez wysyłanie zniekształconych parametrów pluginu. Atakujący mogą przesyłać żądania z nieprawidłowymi wartościami pól TypeKVPair lub TypeHeader, powodując zapisanie w logach audytu komunikatów błędów zawierających poufne dane wejściowe.

OpenBao przed 2.6.4 oraz 2.7.x przed 2.7.1 nie zapisuje wpisów audytu odpowiedzi dla nieuwierzytelnionych endpointów sys/generate-root, sys/rekey i sys/rekey-recovery-key, gdy logowanie audytu żądań powiedzie się, ale logowanie audytu odpowiedzi zawiedzie. Atakujący używający tych endpointów może zakończyć generowanie tokenu root lub operacje rekey bez odpowiadającego wpisu audytu odpowiedzi, utrudniając wykrycie forensyczne.

OpenBao przed wersją 2.6.4 oraz 2.7.x przed 2.7.1 nie weryfikuje przy odnawianiu tokenu wydanego przez metodę uwierzytelniania Kubernetes, czy token konta usługi użyty pierwotnie do uwierzytelnienia jest nadal ważny. Uwierzytelniona osoba atakująca może stale odnawiać takie tokeny, aby utrzymać dostęp po usunięciu konta usługi Kubernetes.

OpenBao Agent w trybie renderowania exec mógł zapisywać sekrety z env_template na standardowe wyjście, gdy plik exec.go odtwarzał runner szablonu po powtarzających się błędach renderowania, głównie po osiągnięciu num_retries. Proces nadzorujący, kolektor logów lub lokalny użytkownik z dostępem do tego wyjścia mógł odczytać wyrenderowane wartości sekretów. Problem naprawiono w wersji 2.6.0.

OpenBao przed wersją 2.6.0 ma podatność w vault/policy/acl.go, gdzie szerszy wildcard ACL może być oceniany przed bardziej specyficznymi ścieżkami z trailing-wildcard i capabilities = ["deny"] dla operacji LIST. Gdy ścieżka nadrzędna zezwalała na LIST, a podrzędna była zabroniona, można było listować zabronioną ścieżkę.

W OpenBao przed wersją 2.6.0 szablonowe polityki ACL, PKI i SSH mogły podstawiać dane tożsamości kontrolowane przez atakującego bez odrzucania znaków istotnych składniowo. W szablonowych politykach ACL gwiazdki, plusy i ukośniki mogły zmieniać dopasowanie ścieżek; w politykach PKI allowed_uri_sans_template i allowed_domains gwiazdka mogła rozszerzyć wystawianie certyfikatów na nieautoryzowane domeny; w politykach SSH allowed_users i allowed_domains przecinek mógł dodawać nieautoryzowane podmioty. Wykorzystanie wymaga wdrożenia używającego szablonowych danych polityk, które użytkownicy mogą swobodnie modyfikować; szablony oparte na losowo generowanej wartości identity.entity.id nie są podatne.

OpenBao przed wersją 2.5.5 ma podatność, w której uwierzytelniony użytkownik z dostępem do zapisu do transit/keys/* może spowodować zakończenie procesu serwera, ustawiając derived na true przy typie klucza rsa-, ecdsa- lub ed25519. Błąd w obsłudze mutexa prowadzi do paniki, braku odpowiedzi HTTP i odmowy usługi.

OpenBao przed wersją 2.5.5 pozwala użytkownikom z uprawnieniami do /sys/namespaces/root w nie-rootowej przestrzeni nazw wykorzystać specjalne traktowanie ścieżki root w kanonizacji przestrzeni nazw. Kontrole ACL odbywają się przed kanonizacją root do pustej ścieżki, przez co /sys/namespaces/root rozwiązuje się do przestrzeni nazw zawierającej backend systemowy, umożliwiając dozwolone operacje wyszukiwania, usuwania, blokowania lub zmiany metadanych na tej przestrzeni.

OpenBao przed wersją 2.5.5 pozwala użytkownikowi z dostępem do sys/leases/revoke/:lease_id w jednej przestrzeni nazw unieważnić lease w innej przestrzeni nazw, jeśli zna identyfikator obcego lease. Routing wyszukiwania lease w vault/expiration.go pozwala FetchLeaseInfo i loadEntry rozwiązać dane lease poza przestrzenią nazw żądania, umożliwiając jednemu tenantowi unieważnienie lease i poświadczeń innego tenanta.

OpenBao przed wersją 2.5.5 używa funkcji EscapeLDAPValue (do escapowania DN wg RFC 4514) tam, gdzie wymagane jest escapowanie filtrów wyszukiwania LDAP (RFC 4515) w GetUserDN. Przy skonfigurowanym backendzie LDAP dla Active Directory, nazwa użytkownika zawierająca metaznaki filtrów może zmienić predykat wyszukiwania i wybrać inny wpis, co pozwala na powiązanie tokena z inną tożsamością i dostęp do jej sekretów.

OpenBao przed wersją 2.5.4 ma podatność w metodzie uwierzytelniania Kerberos, gdzie odpowiedź na żądanie GET lub z nagłówkiem Authorization: Negotiate zawiera obiekt logical.Auth wraz z komunikatem o błędzie. Powoduje to tworzenie tokenów z domyślną polityką, domyślnym TTL i bez informacji o encji, które są ukryte przez komunikat błędu. Tokeny nie są dostępne dla wywołującego ani poza sys/raw.

OpenBao przed wersją 2.5.4 ma podatność w przestrzeniach nazw, gdzie najemca, który celowo ujawni identyfikatory dzierżaw, może mieć swoją dzierżawę i poświadczenia odwołane lub odnowione przez użytkownika z innej przestrzeni nazw za pomocą nieudokumentowanych endpointów sys/revoke i sys/renew.

OpenBao przed wersją 2.5.4 ma podatność w funkcji inline auth, która nieprawidłowo redaguje wpisy dziennika audytu, usuwając nagłówki nieuwierzytelniające i pozostawiając nagłówki związane z uwierzytelnianiem w postaci jawnego tekstu. Wymaga to od atakującego kompromitacji dostępu do urządzenia audytowego.

OpenBao w wersjach przed 2.5.2 z włączoną metodą uwierzytelniania OIDC/JWT i rolą z `callback_mode=direct` jest podatny na atak XSS poprzez parametr `error_description` na stronie nieudanego uwierzytelnienia. Atakujący może przechwycić token używany w interfejsie WWW ofiary.

W systemie OpenBao uprzywilejowany operator mógł wykorzystać podsystem grup tożsamości do dodania polityki root do grupy, eskalując uprawnienia własne lub innego użytkownika. Problem dotyczy operatorów z dostępem do endpointów identity/groups w przestrzeni nazw root, którzy nie mają dostępu do polityk. Podatność naprawiono w wersji 2.4.4.

OpenBao to system zarządzania sekretami. W wersjach przed 2.4.2 dziennik audytu nie redagował odpowiednio pól, gdy podsystemy wysyłały parametry []byte zamiast ciągów znaków. Dotyczy to m.in. sys/raw z encoding=base64 oraz Transit przy operacjach podpisywania kluczem Ed25519, co powodowało ujawnienie danych w logach audytu. Problem naprawiono w wersji 2.4.2.

W OpenBao w wersjach od 2.2.0 do 2.4.1 dziennik audytu nieprawidłowo redagował surowe ciała HTTP dla niektórych endpointów. Może to prowadzić do ujawnienia krótkotrwałych kodów weryfikacyjnych ACME oraz kodów odpowiedzi OIDC i oświadczeń w logach audytu.

OpenBao w wersjach przed 2.4.1 może zużywać znacznie więcej pamięci po dekodowaniu JSON niż jego serializowana wersja, podobnie do zip bomby, z współczynnikiem do około 35. Umożliwia to obejście parametru max_request_size i przeprowadzenie ataku typu denial of service poprzez wyczerpanie pamięci przez nieuwierzytelnionego atakującego, a także zwiększone zużycie CPU w podsystemie audytu.