Podatności Lemur

Lemur w wersji 0.1.4 nie wykorzystuje wystarczającej entropii w wektora inicjalizacyjnego (IV) podczas szyfrowania AES w trybie CBC, co może prowadzić do osłabienia bezpieczeństwa danych.

Lemur przed wersją 1.9.2 ma podatność, która pozwala uwierzytelnionym użytkownikom wpływać na adres ACME authority (acme_url) bez skutecznego ograniczenia docelowego po stronie serwera, co umożliwia ataki SSRF na wewnętrzne usługi lub metadane chmury. Dodatkowo istnieje słabość autoryzacji, która może zachować dostęp do kluczy prywatnych po zmianie właściciela.

Lemur przed wersją 1.9.3 zawiera podatność w endpointach API, która pozwala nieuprzywilejowanemu użytkownikowi na utworzenie duplikatu certyfikatu bez wymaganych uprawnień, a następnie na jego unieważnienie, co może prowadzić do odmowy usługi dla wszystkich certyfikatów. Poprawka w wersji 1.9.3 odrzuca duplikaty i wymaga uprawnień do autorytetu.

Lemur przed wersją 1.9.3 ma podatność w funkcji CertificateExport, gdzie sprawdzenie własności CertificatePermission było wykonywane tylko w gałęzi plugin.requires_key. Plugin z requires_key false omijał to sprawdzenie, a handler nadal przekazywał klucz prywatny i rejestrował zdarzenie audytu key_view. Poprawka nie przekazuje klucza prywatnego pluginom, które go nie wymagają.

Lemur przed wersją 1.9.3 nie wymagał AuthorityPermission na nadrzędnym urzędzie certyfikacji przy tworzeniu sub-CA, gdy ADMIN_ONLY_AUTHORITY_CREATION było fałszywe. Uwierzytelniony użytkownik nie tylko do odczytu mógł utworzyć sub-CA i użyć klucza prywatnego nadrzędnego urzędu do podpisania nowego certyfikatu pośredniego, co pozwalało na wydawanie zaufanych certyfikatów poza normalnymi kontrolami.

Lemur do wersji 1.9.3 nie sprawdzał uprawnień CertificatePermission przy przypisywaniu identyfikatorów do pola replaces w żądaniach tworzenia, przesyłania i edycji certyfikatów. Umożliwiało to atakującemu z uprawnieniami nie tylko do odczytu wyłączenie powiadomień o ofierze i oznaczenie jej certyfikatu jako zastąpionego, co mogło prowadzić do wdrożenia atakującego certyfikatu na punktach końcowych ofiary. Problem naprawiono w wersji 1.9.3.

Lemur przed wersją 1.9.3 udostępniał endpointy GET /api/1/destinations i GET /api/1/destinations/ tylko z uwierzytelnieniem, bez wymogu uprawnień administratora, a odpowiedzi zawierały nieprzefiltrowane opcje, w tym hasła i klucze prywatne w postaci jawnego tekstu. Umożliwiało to użytkownikowi z uprawnieniami tylko do odczytu pobranie poświadczeń do zdalnych hostów wdrażania certyfikatów. Problem naprawiono w wersji 1.9.3.

Lemur przed wersją 1.9.3 nie sprawdzał listy dozwolonych hostów ACME przy aktualizacji acme_url przez PUT /api/1/authorities/, co pozwalało użytkownikowi z rolą authority na ustawienie adresu URL wewnętrznej usługi lub metadanych chmury (np. 169.254.169.254). Podczas kolejnej operacji wydawania certyfikatu Lemur wysyłał żądanie do tego adresu, co mogło ujawnić wewnętrzne usługi lub metadane chmury. Problem naprawiono w wersji 1.9.3.

Lemur przed wersją 1.9.3 pozwalał użytkownikowi z rolą authority na aktualizację acme_url bez ponownej walidacji i skierowanie klienta ACME do kontrolowanego przez atakującego serwera. Serwer ten mógł zwracać adresy URL (newNonce, newOrder, authorizations, finalize) wskazujące na wewnętrzne usługi lub metadane chmury, a Lemur podążał za nimi bez sprawdzania zgodności hosta. Problem naprawiono w wersji 1.9.3.

Lemur przed wersją 1.9.3 zawiera podatność w funkcji _validate_revocation_url, która nie waliduje poprawnie adresów URL po przekierowaniach HTTP, co pozwala na dotarcie do adresów wewnętrznych (loopback, RFC1918, link-local, instance-metadata). Dodatkowo istnieje okno czasowe typu time-of-check time-of-use umożliwiające ataki DNS rebinding. Operator przesyłający certyfikat przez POST /api/1/certificates/upload może wywołać niepożądane żądania wewnętrzne.

Lemur przed wersją 1.9.2 ma podatność w weryfikatorze JWT, który używa niezweryfikowanego algorytmu z nagłówka tokena. W konfiguracji domyślnej PyJWT odrzuca alg=none, więc nie jest to bezpośrednie obejście uwierzytelniania, ale stanowi lukę w obronie warstwowej. Po migracji na podpisy asymetryczne może dojść do pomylenia algorytmów, a anomalie oparte na algorytmach są osłabione.

Lemur przed wersją 1.9.2 ma podatność w lemur.users.service.update, która przypisuje nowe hasło bezpośrednio do pola users.password, bez wywołania funkcji hash_password (zarejestrowanej tylko dla zdarzenia before_insert). W rezultacie zmiany hasła przez administratora przez PUT /api/1/users/ są zapisywane w postaci jawnego tekstu, co uniemożliwia normalne logowanie i naraża hasła na ujawnienie.

Lemur przed wersją 1.9.2 ma podatność w PUT /api/1/roles/, która autoryzuje aktualizacje na podstawie członkostwa w roli, a nie tylko administratora. Pozwala to nieuprzywilejowanemu członkowi roli na dodawanie lub usuwanie innych użytkowników oraz zmianę nazwy roli, co może prowadzić do eskalacji uprawnień i odmowy dostępu.

Lemur przed wersją 1.9.2 ma podatność w lemur/certificates/verify.py, która akceptuje adresy URL CRL i OCSP z przesłanych certyfikatów bez odpowiedniej walidacji miejsca docelowego. Uwierzytelniony operator może przesłać certyfikat przez POST /api/1/certificates/upload i spowodować, że verify_string dotrze do adresów wewnętrznych, takich jak loopback, RFC1918, link-local czy instance-metadata (np. 169.254.169.254). Ponadto ścieżka CRL używa nieograniczonej pamięci podręcznej, co może prowadzić do wyczerpania pamięci.

Lemur przed wersją 1.9.1 ma domyślnie wyłączone flagi ADMIN_ONLY_AUTHORITY_CREATION i LEMUR_STRICT_ROLE_ENFORCEMENT, co powoduje, że kontrola uprawnień przepuszcza każdego uwierzytelnionego użytkownika, w tym rolę tylko do odczytu. Użytkownik może tworzyć urzędy certyfikacji, przesyłać certyfikaty, tworzyć powiadomienia i wpisy domen.