Podatności Keycloak

W Keycloak Policy Enforcer wykryto lukę, która pozwala każdemu uwierzytelnionemu użytkownikowi ominąć wszystkie polityki autoryzacji, w tym sprawdzanie ról, zakresów i uprawnień UMA. Poprzez dodanie ścieżki strony odmowy dostępu do URL żądania (jako segment ścieżki lub parametr zapytania) atakujący może uzyskać nieautoryzowany dostęp do chronionych zasobów.

Znaleziono lukę w komponencie autoryzacji Keycloak. Uwierzytelniony użytkownik posiadający bilet UMA dla jednego zasobu może ominąć kontrolę dostępu dla wszystkich zasobów tego samego typu na serwerze zasobów, używając odpowiedniego prefiksu żądania uprawnień. Podatność wymaga trybu PERMISSIVE polityki egzekwowania oraz włączenia opcji ownerManagedAccess dla typowanych zasobów bez jawnej polityki ochrony.

W usłudze rejestracji klientów Keycloak wykryto lukę, która pozwala zdalnemu atakującemu z wcześniej wydanym tokenem RAT na ponowne włączenie klienta wyłączonego przez administratora. Atakujący może zresetować sekret klienta i potencjalnie odzyskać uprzywilejowany dostęp do API.

W Keycloak wykryto brak autoryzacji w punkcie końcowym GroupResource.addChild() w Admin REST API. Uwierzytelniony użytkownik z ograniczonymi uprawnieniami administracyjnymi może przepiąć dowolną istniejącą grupę, w tym grupę z rolą realm-admin, pod swoją zarządzaną grupę, gdy włączone jest FGAPv2.

W Keycloak wykryto podatność, która pozwala zdalnemu atakującemu z uprawnieniami administracyjnymi (posiadającemu uprawnienie `manage-client` lub dostęp do punktów końcowych rejestracji klientów) na ominięcie walidacji URI klienta. Atakujący może zarejestrować złośliwego klienta z odpowiednio spreparowanym URI przekierowania, używając schematów `javascript:` lub `data:` bez uwzględniania wielkości liter, co prowadzi do podatności na Cross-Site Scripting (XSS).

W Keycloak wykryto podatność, w której administrator realm z rolą 'manage-realm' może podać dowolną ścieżkę systemu plików jako parametr keystore podczas tworzenia komponentu dostawcy kluczy. Umożliwia to sprawdzenie, które pliki istnieją i są odczytywalne przez proces Keycloak.

Zgłoszona podatność została odrzucona, ponieważ opisane zachowanie nie stanowi eskalacji uprawnień. Atakujący musi już posiadać rolę administracyjną manage-realm w kliencie realm-management, która z założenia jest równoważna roli realm-admin. Importowanie użytkowników z mapowaniem roli realm-admin przez endpoint POST /admin/realms/{realm}/partialImport nie przyznaje dodatkowych uprawnień.

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 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, 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.

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 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 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 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.

W Keycloak Server znaleziono podatność na odmowę usługi (DoS) z powodu nieprawidłowego obsługiwania nagłówków proxy. Gdy Keycloak jest skonfigurowany do akceptowania nagłówków proxy, może przyjmować wartości niebędące adresami IP (np. zaciemnione identyfikatory) bez odpowiedniej walidacji, co prowadzi do kosztownych operacji DNS i może zablokować wątki IO, powodując DoS. Atakujący musi mieć dostęp do instancji Keycloak skonfigurowanej do akceptowania nagłówków proxy, gdy reverse proxy nie nadpisują nagłówków przychodzących.

Podatność w Keycloak pozwala użytkownikowi z wysokimi uprawnieniami na odczyt wrażliwych informacji z pliku Vault poza oczekiwanym kontekstem. Atakujący musi mieć wcześniejszy wysoki dostęp do serwera Keycloak, aby na przykład skonfigurować dostawcę LDAP i ustawić odczyt pliku Vault, co ujawnia jedynie, czy plik istnieje.

W Keycloak wykryto podatność polegającą na tym, że wrażliwe wartości, takie jak hasła, mogą być przechwytywane podczas procesu budowania i osadzane jako wartości domyślne w kodzie bajtowym, co prowadzi do nieautoryzowanego ujawnienia informacji. Dotyczy to również wartości ze zmiennych środowiskowych w Keycloak 26 oraz pośredniego użycia zmiennych środowiskowych w starszych wersjach.

Podatność w pakiecie Keycloak-services. Jeśli niezaufane dane zostaną przekazane do metody SearchQueryUtils, może to prowadzić do odmowy usługi (DoS) poprzez wyczerpanie zasobów systemowych z powodu złożoności wyrażeń regularnych.

W Keycloak znaleziono wadę błędnej konfiguracji. Może ona pozwolić atakującemu na przekierowanie użytkowników na dowolny adres URL, jeśli 'Valid Redirect URI' jest ustawione na http://localhost lub http://127.0.0.1, co umożliwia ujawnienie wrażliwych informacji, takich jak kody autoryzacyjne, potencjalnie prowadząc do przejęcia sesji.

W rejestracji klientów SAML w Keycloak wykryto błąd, który pozwala administratorowi na zarejestrowanie złośliwych URI JavaScript jako adresów URL POST Binding dla Assertion Consumer Service (ACS), co stwarza ryzyko Cross-Site Scripting (XSS). Może to umożliwić złośliwemu administratorowi w jednym realmie lub klientowi z prawem rejestracji atakowanie użytkowników w innych realmach lub aplikacjach, wykonując dowolny JavaScript w ich kontekście po przesłaniu formularza.

W Keycloak wykryto podatność na wstrzykiwanie logów. Poprzez formularz uwierzytelniania w trybie WebAuthn możliwe jest wstrzyknięcie tekstu do logów, co może nieznacznie wpłynąć na ich integralność.

Podatność w Keycloak polega na nieprawidłowym walidowaniu adresów URL zawartych w przekierowaniu. Atakujący może skonstruować złośliwe żądanie, aby ominąć walidację i uzyskać dostęp do innych adresów URL oraz wrażliwych informacji w obrębie domeny lub przeprowadzić dalsze ataki. Problem dotyczy klientów używających symbolu wieloznacznego w polu Valid Redirect URIs i wymaga interakcji użytkownika ze złośliwym adresem URL.