Podatności Keycloak

W org.keycloak.services administrator z delegowanym dostępem do odczytu członkostw grup i użytkowników może ominąć uprawnienia profilu użytkownika, uzyskując dostęp do endpointu członków grupy, co pozwala na wyświetlenie atrybutów użytkownika, które są jawnie zabronione.

W Keycloak wykryto podatność, która przy włączonej opcji revokeRefreshToken=true i użyciu trwałego przechowywania sesji, umożliwia atakującemu ponowne użycie unieważnionego tokena odświeżania po restarcie serwera. Atakujący, który wcześniej przechwycił token odświeżania ofiary, może uzyskać nieautoryzowany dostęp do jej konta.

W Keycloak wykryto podatność umożliwiającą atakującemu z wysokimi uprawnieniami (np. administratorowi domeny konfigurującemu złośliwy serwer LDAP lub osobie atakującej kompromitującej nadrzędny serwer LDAP) wywołanie błędu OutOfMemoryError poprzez wysłanie nieprawidłowej odpowiedzi polityki haseł LDAP podczas żądania uwierzytelnienia. Prowadzi to do zatrzymania maszyny wirtualnej Java (JVM) Keycloak i odmowy usługi (DoS) dla wszystkich domen na zaatakowanym węźle.

W Keycloak wykryto podatność w funkcji Fine-Grained Admin Permissions (FGAPv2). Administrator z ograniczonymi uprawnieniami do zarządzania klientami może przypisać dowolną rolę realm, w tym wysoce uprzywilejowane, do mapowania zakresu klienta. Obejście to pozwala na wstrzyknięcie roli do tokena uwierzytelniającego użytkownika.

W Keycloak wykryto podatność, która umożliwia uwierzytelnionemu użytkownikowi z członkostwem w organizacji ujawnienie metadanych organizacji w tokenach OIDC lub poprzez API konta, nawet po wyłączeniu funkcji Organizacji przez administratora. Może to prowadzić do błędnych decyzji autoryzacyjnych na serwerach zasobów.

W Keycloak wykryto błąd, w którym dowód weryfikacji krzyżowej sesji jest kluczowany tylko przez (localUserId, idpAlias) i nie jest powiązany z rzeczywistą tożsamością upstream. Drugie konto upstream na tym samym IdP może skonsumować dowód i zostać połączone z lokalnym kontem ofiary.

W Keycloak wykryto podatność na fiksację sesji w endpointach logowania. Nieuwierzytelniony atakujący może stworzyć sesję uwierzytelniającą i nakłonić ofiarę do kliknięcia spreparowanego linku, co pozwala na przejęcie formularza wymaganych akcji bez znajomości jej danych logowania. Udane wykorzystanie może prowadzić do całkowitego przejęcia konta, w tym kont administracyjnych.

W Keycloak wykryto podatność w logice walidacji URL podczas operacji przekierowań. Poprzez spreparowanie złośliwego żądania atakujący może ominąć walidację i przekierować użytkowników na nieautoryzowane adresy URL, co może prowadzić do ujawnienia wrażliwych informacji w domenie lub ułatwić dalsze ataki. Podatność dotyczy klientów Keycloak skonfigurowanych z symbolem wieloznacznym (*) w polu "Valid Redirect URIs" i wymaga interakcji użytkownika.

W Keycloak wykryto podatność, która pozwala zdalnemu, nieuwierzytelnionemu atakującemu na wysłanie specjalnie spreparowanego wejścia XML do punktu końcowego SAML. Może to spowodować wysokie zużycie CPU i wygłodzenie wątków roboczych, prowadząc do odmowy usługi (DoS) i uniemożliwienia dostępu do serwera.

W Keycloak wykryto błąd, w którym przy jednoczesnym skonfigurowaniu polityk unieważniania `notBefore` na poziomie realm i klienta, funkcja OIDC Introspection nie honoruje polityki realmowej. Tokeny, które powinny być unieważnione, pozostają aktywne.

Uwierzytelniony użytkownik może ominąć skonfigurowane polityki WebAuthn podczas rejestracji poświadczeń poprzez manipulację JavaScript po stronie klienta. Serwer nie sprawdza, czy parametry nowego poświadczenia (np. algorytmy klucza publicznego) są zgodne z politykami WebAuthn domeny.

W Keycloak wykryto lukę, która pozwala uwierzytelnionemu użytkownikowi z rolą uma_protection na ominięcie walidacji zasad User-Managed Access (UMA). Atakujący może w żądaniu utworzenia polityki podać identyfikatory zasobów należących do innych użytkowników, nawet jeśli ścieżka URL wskazuje na jego własny zasób. Umożliwia to uzyskanie nieautoryzowanego dostępu do wrażliwych danych lub wykonanie nieuprawnionych działań.

W Keycloak wykryto podatność, która pozwala nieuwierzytelnionemu atakującemu na przeprowadzenie ataku DoS poprzez wysłanie specjalnie spreparowanego żądania POST z nadmiernie długim parametrem scope do punktu końcowego tokena OIDC. Powoduje to wysokie zużycie zasobów i wydłużony czas przetwarzania, prowadząc do odmowy usługi.

W Keycloak wykryto lukę w SingleUseObjectProvider, globalnym magazynie klucz-wartość, który nie zapewnia odpowiedniej izolacji typów i przestrzeni nazw. Umożliwia to atakującemu usuwanie dowolnych jednorazowych wpisów, co może pozwolić na ponowne użycie zużytych tokenów akcji, takich jak linki do resetowania hasła. Może to prowadzić do nieautoryzowanego dostępu lub przejęcia konta.

W Keycloak wykryto lukę w SingleUseObjectProvider, globalnym magazynie klucz-wartość, który nie zapewnia odpowiedniej izolacji typów i przestrzeni nazw. Umożliwia to nieuwierzytelnionemu atakującemu fałszowanie kodów autoryzacyjnych.

W Keycloak wykryto podatność umożliwiającą atakującemu kontrolującemu inną ścieżkę na tym samym serwerze WWW ominięcie dozwolonej ścieżki w przekierowaniach URI używających symbolu wieloznacznego. Udany atak może prowadzić do kradzieży tokena dostępu i ujawnienia informacji.

W Keycloak wykryto podatność SSRF. Uwierzytelniony atakujący może manipulować parametrem `client_session_host` podczas odświeżania tokenów, co pozwala na wysyłanie żądań HTTP z kontekstu sieciowego serwera Keycloak. Problem występuje, gdy klient Keycloak jest skonfigurowany z `backchannel.logout.url` zawierającym placeholder `application.session.host`.

W Keycloak wykryto błąd umożliwiający zdalnemu atakującemu wykorzystanie zróżnicowanych komunikatów błędów w przepływie logowania identity-first przy włączonych Organizations. Podatność pozwala ustalić istnienie użytkowników, prowadząc do ujawnienia informacji poprzez enumerację użytkowników.

W Keycloak wykryto lukę polegającą na nieprawidłowej kontroli dostępu w punkcie końcowym resource_set mechanizmu User-Managed Access (UMA). Atakujący z ważnymi poświadczeniami może obejść ograniczenie allowRemoteResourceManagement=false z powodu niepełnego egzekwowania kontroli dostępu przy operacjach PUT na tym punkcie końcowym, co umożliwia nieautoryzowaną modyfikację chronionych zasobów.

W Keycloak, rozwiązaniu do zarządzania tożsamością i dostępem, zidentyfikowano błąd polegający na niewłaściwym śledzeniu przekierowań HTTP podczas przetwarzania określonych żądań konfiguracji klientów. Umożliwia to atakującemu oszukanie serwera, aby ten wysyłał niezamierzone żądania do wewnętrznych lub zastrzeżonych zasobów.

W Keycloak wykryto lukę umożliwiającą zdalnemu atakującemu ominięcie kontroli bezpieczeństwa poprzez wysłanie prawidłowej odpowiedzi SAML z zewnętrznego dostawcy tożsamości (IdP) do punktu końcowego SAML Keycloak dla logowań brokerskich inicjowanych przez IdP. Pozwala to na zalogowanie się nawet wtedy, gdy dostawca SAML jest wyłączony.

W Keycloak wykryto podatność w punkcie końcowym brokera SAML. Nieprawidłowa walidacja zaszyfrowanych asercji w przypadku braku podpisu całej odpowiedzi SAML umożliwia atakującemu wstrzyknięcie asercji dla dowolnego użytkownika.

W Keycloak wykryto podatność obejścia autoryzacji w API administracyjnym, która pozwala każdemu uwierzytelnionemu użytkownikowi, nawet bez uprawnień administracyjnych, na wyliczenie członkostw organizacji innych użytkowników. Ujawnienie informacji następuje, gdy atakujący zna unikalny identyfikator (UUID) ofiary i funkcja Organizations jest włączona.

Wykryto wadę w Account REST API Keycloak, która pozwala użytkownikowi uwierzytelnionemu na niższym poziomie bezpieczeństwa wykonywać wrażliwe działania przeznaczone tylko dla sesji o wyższym poziomie zaufania. Konkretnie, atakujący, który już zdobył hasło ofiary, może usunąć zarejestrowane poświadczenie MFA/OTP ofiary bez uprzedniego udowodnienia posiadania tego czynnika. Następnie atakujący może zarejestrować własne urządzenie MFA, skutecznie przejmując pełną kontrolę nad kontem. Ta słabość podważa ochronę zapewnianą przez uwierzytelnianie wieloskładnikowe.

W Keycloak znaleziono lukę w komponencie org.keycloak.broker.saml. Gdy wyłączony klient SAML jest skonfigurowany jako docelowy punkt docelowy brokera inicjowanego przez dostawcę tożsamości (IdP), nadal może on zakończyć proces logowania i ustanowić sesję SSO. Pozwala to zdalnemu atakującemu uzyskać nieautoryzowany dostęp do innych włączonych klientów bez ponownego uwierzytelniania, skutecznie omijając ograniczenia bezpieczeństwa.

Podatność w Keycloak umożliwia uwierzytelnienie przez wyłączonego dostawcę tożsamości (IdP) poprzez ponowne użycie wcześniej wygenerowanego żądania logowania. Atakujący znający alias IdP może ominąć administracyjne ograniczenie i uzyskać dostęp.

W komponencie rejestracji WebAuthn w Keycloak znaleziono wadę. Podatność pozwala atakującemu ominąć skonfigurowaną politykę atestacji i zarejestrować niezaufane lub sfałszowane authenticatory poprzez przesłanie obiektu atestacji z fmt: "none", nawet gdy realm jest skonfigurowany do wymagania bezpośredniej atestacji. Może to prowadzić do osłabienia integralności uwierzytelniania i nieautoryzowanej rejestracji authenticatorów.

Podatność w Keycloak polegająca na ujawnianiu wrażliwych nagłówków, w tym Authorization i Cookie, w postaci jawnej w logach, gdy format logowania jest ustawiony na rozwlekły wzorzec dostarczony przez użytkownika (np. predefiniowany wzorzec 'long'). Atakujący z dostępem do odczytu plików logów może wyodrębnić poświadczenia (tokeny bearer, ciasteczka sesji) i podszyć się pod użytkowników.

W Keycloak wykryto lukę, która pozwala atakującemu na modyfikację identyfikatora organizacji i docelowego adresu e-mail w ważnym tokenie zaproszenia JWT. Brak weryfikacji podpisu kryptograficznego umożliwia atakującemu samodzielną rejestrację w nieautoryzowanej organizacji.

W Keycloak wykryto podatność w przepływie jwt-authorization-grant, gdzie serwer nie sprawdza, czy dostawca tożsamości (IdP) jest włączony przed wydaniem tokenów. Mechanizm wyszukiwania IdP (lookupIdentityProviderFromIssuer) pobiera konfigurację, ale nie filtruje po isEnabled=false. Osoba posiadająca klucz podpisu wyłączonego IdP może nadal generować ważne asercje JWT, które Keycloak akceptuje, co prowadzi do wydania ważnych tokenów dostępowych.

Ten numer CVE został odrzucony. Po dalszej analizie przez projekt Keycloak i Red Hat stwierdzono, że zgłoszona podatność SSRF poprzez URI rejestracji klienta/powiadomień zwrotnych nie stanowi luki bezpieczeństwa. Opisane zachowanie jest oczekiwaną funkcjonalnością kontrolowaną przez administratora, a Keycloak zapewnia udokumentowane środki łagodzące poprzez Polityki Klienta.

W Keycloak znaleziono wadę związaną z nieprawidłową walidacją danych wejściowych. Keycloak akceptuje zgodne z RFC parametry macierzowe w segmentach ścieżek URL, podczas gdy typowe konfiguracje reverse proxy mogą je ignorować lub błędnie obsługiwać. Zdalny atakujący może tworzyć żądania maskujące segmenty ścieżek, potencjalnie omijając filtrowanie ścieżek na poziomie proxy. Może to ujawnić administracyjne lub wrażliwe punkty końcowe, które operatorzy uważają za nieosiągalne z zewnątrz.

W Keycloak znaleziono lukę, która dotyczy parsera nagłówka autoryzacji. Parser ten jest zbyt tolerancyjny wobec formatowania schematu autoryzacji 'Bearer', akceptując niestandardowe znaki jako separatory oraz tolerując różnice w wielkości liter, które odbiegają od specyfikacji RFC 6750.

W Keycloak wykryto lukę IDOR (naruszenie kontroli dostępu) w punktach końcowych admin API do zarządzania zasobami autoryzacji, konkretnie w ResourceSetService i PermissionTicketService. System sprawdza autoryzację względem identyfikatora resourceServer (klienta) podanego w żądaniu API, ale operacje w bazie danych (findById, delete) używają tylko resourceId. Ta niezgodność pozwala uwierzytelnionemu atakującemu z uprawnieniami administratora dla jednego klienta (np. Client A) usuwać lub modyfikować zasoby należące do innego klienta (Client B) w tym samym realmie, podając prawidłowy identyfikator zasobu.

W Keycloak Admin REST API wykryto lukę, która pozwala na ujawnienie poufnych metadanych ról poprzez niewystarczające sprawdzanie autoryzacji na endpointcie /admin/realms/{realm}/roles.

Wada w providerze LDAP User Federation w Keycloak pozwala uwierzytelnionemu administratorowi realm na wywołanie deserializacji niezaufanych obiektów Java poprzez złośliwą konfigurację serwera LDAP.

W dystrybucji serwera Keycloak włączenie trybu debugowania (--debug <port>) domyślnie wiąże port JDWP ze wszystkimi interfejsami sieciowymi (0.0.0.0), co naraża port debugowania na sieć lokalną.

W Keycloak użytkownik może przypadkowo uzyskać dostęp do sesji innego użytkownika, jeśli obaj korzystają z tego samego urządzenia i przeglądarki. Dzieje się tak, ponieważ Keycloak czasami ponownie używa identyfikatorów sesji i nie czyści ich prawidłowo podczas wylogowania, gdy brakuje plików cookie przeglądarki. W rezultacie jeden użytkownik może otrzymać tokeny należące do innego użytkownika.

W Keycloak znaleziono błąd. Zalecenia Keycloak mówią, aby nie wystawiać ścieżki /admin na zewnątrz, gdy instalacja używa proxy. Problem występuje przynajmniej przez ha-proxy, które może zostać oszukane do użycia względnych/nieznormalizowanych ścieżek, aby uzyskać dostęp do ścieżki /admin względem /realms, która powinna być wystawiona.

W Keycloak sesja offline pozostaje ważna po usunięciu zakresu offline_access z klienta. Token odświeżania jest nadal akceptowany i można żądać nowych tokenów dla tej sesji.

W Keycloak wykryto błąd logiczny w zarządzaniu sesjami. Keycloak nie wymusza natychmiastowego wyłączenia ustawienia realm „Remember Me” dla istniejących sesji użytkowników; sesje utworzone, gdy „Remember Me” było aktywne, zachowują wydłużony czas życia do wygaśnięcia, nadpisując niedawną zmianę konfiguracji administratora. Zwiększa to ryzyko przejęcia sesji lub nieautoryzowanego długoterminowego dostępu.

W Keycloak konsola konta i inne strony akceptują dowolny tekst w parametrze zapytania error_description, który jest renderowany bez walidacji i sanityzacji. Choć kodowanie HTML zapobiega XSS, atakujący może tworzyć adresy URL z mylącymi komunikatami (np. fałszywe numery telefonu wsparcia), wyświetlanymi w zaufanym interfejsie Keycloak.

W Keycloak znaleziono lukę, która pozwala uwierzytelnionemu atakującemu na połączenie swojego konta z istniejącym kontem ofiary podczas logowania przez dostawcę tożsamości. Atakujący może zmienić swój adres e-mail na adres ofiary, co prowadzi do wysłania wiadomości weryfikacyjnej do ofiary.

W Keycloak pakiet org.keycloak.authorization może być podatny na obejście wymaganych akcji, takich jak konfiguracja uwierzytelniania dwuskładnikowego.

W Keycloak wykryto błąd polegający na tym, że przy uwierzytelnianiu opartym na tokenach JWT są one buforowane do momentu wygaśnięcia. Jeśli klient używa tokenów JWT z bardzo długim czasem ważności (np. 24 lub 48 godzin), pamięć podręczna może rosnąć w nieskończoność, prowadząc do błędu OutOfMemoryError.

W funkcji organizacji Keycloak wykryto błąd umożliwiający nieprawidłowe przypisanie organizacji do użytkownika, gdy jego nazwa użytkownika lub e-mail pasuje do wzorca domeny organizacji. Problem występuje na poziomie mappera i prowadzi do błędnego odwzorowania w tokenach.

W Keycloak wykryto usterkę, która pozwala użytkownikom Active Directory na ominięcie ograniczeń konta. Gdy użytkownik AD resetuje swoje hasło, system aktualizuje je bez wykonania bindowania LDAP w celu weryfikacji nowych poświadczeń. Dzięki temu użytkownicy z wygasłymi lub wyłączonymi kontami AD mogą odzyskać dostęp w Keycloak, omijając ograniczenia AD.

W Keycloak wykryto podatność, która pozwala użytkownikom administracyjnym na dostęp do wrażliwych zmiennych środowiskowych serwera i właściwości systemowych poprzez konfigurowalne adresy URL. Podczas konfigurowania adresów URL wylogowania backchannel lub adresów URL administratora, administratorzy mogą umieszczać placeholdery takie jak ${env.VARNAME} lub ${PROPNAME}, które serwer zastępuje rzeczywistymi wartościami podczas przetwarzania URL.

W Keycloak wykryto podatność na odmowę usługi, która pozwala użytkownikowi administracyjnemu z uprawnieniami do zmiany ustawień realm na zakłócenie działania usługi. Polega to na modyfikacji nagłówków bezpieczeństwa i wstawianiu znaków nowej linii, co powoduje, że serwer Keycloak zapisuje do już zakończonego żądania, prowadząc do jego niepowodzenia.

W Keycloak znaleziono podatność, w której opcja środowiskowa `KC_CACHE_EMBEDDED_MTLS_ENABLED` nie działa i konfiguracja replikacji JGroups jest zawsze używana w postaci zwykłego tekstu, co może pozwolić atakującemu mającemu dostęp do sąsiednich sieci związanych z JGroups na odczyt wrażliwych informacji.