CVE-2025-62819
NieznaneStreszczenie
Keyfactor EJBCA w wersji do 9.3.3 wykonuje niewystarczające kontrole autoryzacji podczas samodzielnego odnawiania certyfikatu klienta za pośrednictwem interfejsu użytkownika RA (Registration Authority). Pozwala to zdalnemu użytkownikowi uwierzytelnionemu ważnym certyfikatem klienta odnowić certyfikat, nawet jeśli status końcowego podmiotu i/lub ustawienia profilu powinny odmówić odnowienia. Atakujący musi posiadać ważny certyfikat klienta TLS i być upoważniony do korzystania z interfejsu RA, albo za pomocą certyfikatu, albo poprzez członkostwo w roli PublicAccessAuthenticationToken.
Ocena ryzyka
Użytkownik z ważnym certyfikatem klienta może odnowić certyfikat wbrew politykom statusu lub profilu, co może utrzymać dostęp do systemu mimo cofnięcia uprawnień. Stanowi to naruszenie kontroli dostępu i może umożliwić nieautoryzowany dostęp do zasobów.
Rekomendacja
Zaktualizuj Keyfactor EJBCA do wersji nowszej niż 9.3.3, jeśli jest dostępna, lub wdróż dodatkowe kontrole autoryzacji przy odnawianiu certyfikatów przez RA. Przejrzyj i ogranicz uprawnienia do interfejsu RA oraz ról PublicAccessAuthenticationToken.
Inne podatności w Keyfactor EJBCA
Zobacz wszystkie- CVE-2025-49602Niskie ryzyko· EPSS 8%
W Keyfactor EJBCA 9 występuje problem z uwierzytelnianiem: gdy administrator zostanie pozbawiony roli administratora podczas aktywnej sesji TLS, EJBCA może w pewnych okolicznościach buforować uwierzytelnienie dłużej niż skonfigurowany maksymalny czas (domyślnie 30 sekund). W rezultacie były administrator zachowuje dostęp, którego nie powinien już mieć.
- CVE-2023-34196Wysokie
W EJBCA przed wersją 8.0.0, serwlet dystrybucji certyfikatów RA /ejbca/ra/cert umożliwia częściowe odmowy usługi z powodu problemu z uwierzytelnieniem. W konfiguracjach używających OAuth może dojść do ujawnienia certyfikatów CA (atrybutów i kluczy publicznych) nieautoryzowanym lub mniej uprzywilejowanym użytkownikom.
Oryginalny opis (angielski, źródło NVD)
Keyfactor EJBCA through 9.3.3 performs insufficient authorization checks when self-renewing a client certificate via the RA (Registration Authority) User Interface. This allows a remote user, authenticated with a valid client certificate, to renew their certificate even if the end entity status and/or profile settings should deny renewal. The attacker must have a valid TLS client certificate, and must be authorized to use the RA User Interface, either with the certificate, or via a role membership for PublicAccessAuthenticationToken.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS