Podatności Keycloak

Podatność w zarządzaniu polityką bezpieczeństwa Dynamic Client Registration (DCR) w Keycloak. Polityka "Allowed Protocol Mapper Types" nie ponownie weryfikuje typu mappera podczas aktualizacji klienta, jeśli konfiguracja mappera pozostaje niezmieniona. Atakujący z uprawnieniami rejestracji klienta może najpierw zarejestrować dozwolony typ mappera ze złośliwą konfiguracją, a następnie zamienić go na ograniczony typ o wysokich uprawnieniach (np. taki, który na sztywno ustawia role administracyjne), co pozwala uzyskać pełny dostęp administracyjny do realm.

Podatność w komponencie Dynamic Client Registration (DCR) w Keycloak. Domyślna polityka DCR nieprawidłowo waliduje ścieżkę claim dla mappera User Property, co pozwala zapisywać wartości w wrażliwych wewnętrznych lokalizacjach claim. Atakujący ze standardowym kontem użytkownika i ograniczonym Initial Access Token może sfałszować role administracyjne w swoim tokenie dostępu, co umożliwia przejęcie innych klientów, kradzież poufnych sekretów i potencjalnie pełną kontrolę administracyjną nad realm.

W Keycloak stwierdzono usterkę w rejestrowaniu metryk zdarzeń użytkownika. Gdy metryki są włączone, system zapisuje surowe komunikaty błędów z nieudanych operacji konta jako etykiety metryk Prometheus. Ponieważ komunikaty te mogą zawierać dane wprowadzone przez użytkownika, np. nieistniejące identyfikatory klientów, uwierzytelniony użytkownik może utworzyć ogromną liczbę unikalnych wpisów metryk, co prowadzi do wyczerpania pamięci systemu i awarii usługi.

W Keycloak stwierdzono usterkę w dostawcy magazynu LDAP, używanym do federacji tożsamości z zewnętrznych katalogów. Problem występuje, gdy delegowany administrator przeprowadza wyszukiwanie przy użyciu konkretnego wyróżnika (DN) wpisu LDAP. Z powodu braku walidacji system umożliwia wyszukiwanie użytkowników spoza skonfigurowanego zakresu, co prowadzi do ujawnienia informacji o kontach z nieautoryzowanych części katalogu oraz niechcianego importowania tych użytkowników do lokalnego magazynu.

Podatność w usługach autoryzacji Keycloak. Komponent PathMatcher, odpowiedzialny za dopasowywanie ścieżek żądań do polityk bezpieczeństwa, nie normalizuje poprawnie URI przed porównaniem. Dodając dodatkowe znaki, takie jak końcowy ukośnik lub parametry macierzowe, atakujący może sprawić, że system zastosuje mniej restrykcyjną politykę bezpieczeństwa niż zamierzono. Pozwala to uwierzytelnionemu użytkownikowi uzyskać dostęp do obszarów administracyjnych lub zastrzeżonych, do których nie powinien mieć uprawnień.

W funkcji importu metadanych SAML w komponencie keycloak-services stwierdzono błąd polegający na nieprawidłowym wyłączaniu weryfikacji podpisu odpowiedzi SAML, gdy metadane dostawcy tożsamości nie zawierają określonych atrybutów użycia kluczy. Umożliwia to nieuwierzytelnionemu atakującemu sfałszowanie odpowiedzi SAML i uzyskanie nieautoryzowanego dostępu do konta użytkownika, znając jego zewnętrzny identyfikator.

W komponencie keycloak-services (część Red Hat Build of Keycloak) wykryto błąd w endpointcie wylogowania backchannel. Gdy dostawca tożsamości OIDC jest skonfigurowany do pomijania weryfikacji podpisu, system błędnie akceptuje żądania wylogowania bez podpisu kryptograficznego. Atakujący znający szczegóły sesji użytkownika może wymusić jego wylogowanie.

W komponencie keycloak-services Keycloaka stwierdzono usterkę polegającą na nieprawidłowej ocenie stanu klienta podczas operacji aktualizacji. Administrator sfery może skonfigurować polityki wymuszające określone wymagania uwierzytelniania dla klientów poufnych. Atakujący z uprawnieniami do zarządzania klientami może ominąć te polityki, tworząc najpierw klienta publicznego, a następnie aktualizując go do klienta poufnego ze słabszym uwierzytelnianiem.

W Keycloaku wykryto usterkę w usługach autoryzacji, która pozwala użytkownikowi na dołączenie fałszywej wartości czasu w żądaniu autoryzacji, nadpisującej rzeczywisty czas serwera. Umożliwia to ominięcie ograniczeń czasowych i dostęp do chronionych zasobów w nieautoryzowanych godzinach.

W Keycloaku z włączonym Fine-Grained Admin Permissions V2 (FGAP V2) stwierdzono usterkę w komponencie tworzenia użytkowników. Pod-administrator z uprawnieniami do tworzenia użytkowników może dodawać nowych użytkowników do dowolnych grup, nawet do tych, którymi nie ma prawa zarządzać.

W komponencie keycloak-services Keycloaka stwierdzono usterkę w executorze polityki full-scope-disabled. Executor sprawdza pole fullScopeAllowed tylko wtedy, gdy jest ono jawnie podane w żądaniu. Pominięcie tego pola pozwala delegowanemu użytkownikowi na ominięcie polityki i utworzenie klienta z pełnym zakresem dostępu, co umożliwia uzyskanie tokenów z nieautoryzowanymi mapowaniami ról.

W komponencie TokenManager w Keycloak administrator próbujący unieważnić tokeny dla konkretnej aplikacji za pomocą polityki "not-before" może napotkać ciche ignorowanie unieważnienia, jeśli domena zabezpieczeń ma już starszą, niezerową politykę unieważnienia. Może to pozwolić na dalsze ważność tokenów do odświeżania sesji i dostępu do danych użytkownika.

W implementacji protokołu SAML w Keycloak, gdy klient jest skonfigurowany z wildcard URL przekierowania, atakujący może spreparować żądanie zawierające złośliwe parametry. Po uwierzytelnieniu użytkownika Keycloak dołącza swoją prawidłową odpowiedź do parametrów atakującego, co może spowodować, że dostawca usługi przetworzy dane atakującego zamiast prawdziwych danych logowania, potencjalnie prowadząc do zalogowania użytkownika na niewłaściwe konto.

W Keycloak funkcja token exchange nie sprawdza ograniczeń dotyczących konkretnej organizacji (tenanta) podczas logowania przez Microsoft. Atakujący z ważnym tokenem Microsoft z innej organizacji może uzyskać dostęp do domeny Keycloak, potencjalnie uzyskując dostęp do wrażliwych danych lub wykonując nieautoryzowane działania.

W Keycloak funkcja token exchange nie sprawdza ograniczeń domen Google Workspace podczas logowania przez Google. Atakujący z ważnym kontem Google z innej domeny może ominąć zabezpieczenia i uzyskać dostęp do domeny Keycloak.

W komponencie secure-client-uris w Keycloak sprawdzanie adresów URL opiera się tylko na początku adresu, a nie na prawidłowej weryfikacji hosta. Atakujący może ominąć zabezpieczenia wymagające szyfrowanych połączeń dla URI przekierowań, używając specjalnie spreparowanej nazwy domeny, co może pozwolić na przechwycenie kodów uwierzytelniających przez nieszyfrowane połączenia.

W komponencie keycloak-services w Keycloak, sprawdzanie bezpieczeństwa zapobiegające zanieczyszczeniu parametrów HTTP sprawdza tylko część zapytania URL, ignorując fragment. Gdy klient jest skonfigurowany z wildcard URI przekierowania, atakujący może wstrzyknąć zduplikowane parametry bezpieczeństwa do odpowiedzi logowania. Jeśli aplikacja kliencka nie jest poprawnie skonfigurowana, może zaufać danym atakującego zamiast prawdziwym informacjom z Keycloak, co prowadzi do fiksacji sesji lub pomylenia kont.

W punkcie końcowym OIDC token introspection w keycloak-services, poufny klient skonfigurowany do odbierania podpisanych odpowiedzi JWT może otrzymać pełny zestaw roszczeń tokena w podpisanym polu JWT, nawet jeśli token został wydany dla innego odbiorcy. Pozwala to nieautoryzowanemu klientowi ominąć ograniczenia oparte na odbiorcy i uzyskać dostęp do wrażliwych informacji.

W Keycloak, w komponencie keycloak-services, administrator domeny może użyć wildcarda (np. *.example.com) do ograniczenia rejestracji klientów. Z powodu nieprawidłowej walidacji system akceptuje dowolną nazwę hosta kończącą się na dany sufiks domeny, nawet jeśli nie jest to prawowita subdomena. Atakujący kontrolujący odwrotne DNS swojego połączenia może ominąć te ograniczenia i potencjalnie dokonać nieautoryzowanych modyfikacji klientów.

W Keycloak logika oceny polityk grupowych używa prostego sprawdzania prefiksu tekstowego do weryfikacji członkostwa w grupie, zamiast dokładnego dopasowania. Użytkownik należący do grupy o podobnej początkowej nazwie może ominąć zabezpieczenia i uzyskać nieautoryzowany dostęp do funkcji administracyjnych lub chronionych zasobów.

W komponencie RoleContainerResource w Keycloak, punkty końcowe admin REST API oparte na nazwach nie egzekwują prawidłowo kontroli autoryzacji podczas zarządzania rolami złożonymi. Delegowany administrator z uprawnieniami manage-realm może usunąć kluczowe role podrzędne z wbudowanych ról administracyjnych, potencjalnie zakłócając funkcje administracyjne w domenie.

Znaleziono błąd w mechanizmie wymuszania polityki klienta w Keycloak. Problem występuje, gdy system sprawdza członkostwo w grupie na podstawie nazwy zamiast unikalnego identyfikatora. Atakujący z uprawnieniami do zarządzania klientami może ominąć polityki bezpieczeństwa, dołączając do grupy o pasującej nazwie w innej części hierarchii grup, co potencjalnie pozwala na rejestrację lub aktualizację klientów bez przestrzegania wymaganych profili zabezpieczeń.

Keycloak umożliwia zarządzanie dostawcami tożsamości i organizacjami za pomocą API administracyjnego. Odkryto błąd, w którym administrator z uprawnieniami do zarządzania dostawcami tożsamości mógł połączyć nowego dostawcę z organizacją bez wymaganych uprawnień do zarządzania tą organizacją. Może to pozwolić nieautoryzowanemu administratorowi na wpływanie na to, jak użytkownicy logują się do określonych organizacji.

W bibliotece keycloak-services, będącej rdzeniem systemu zarządzania tożsamością i dostępem Keycloak, w punkcie końcowym role-users brakuje sprawdzenia, czy administrator ma uprawnienia do przeglądania poszczególnych użytkowników podczas wyświetlania członków roli. Ograniczony administrator może zobaczyć prywatne informacje, takie jak nazwy i adresy e-mail użytkowników, do których nie powinien mieć dostępu.

W Keycloak Admin REST API, używanym do zarządzania domenami bezpieczeństwa i klientami, podczas przetwarzania żądań dotyczących rotowanych sekretów klienta przechowywanych w bezpiecznym magazynie, delegowany administrator z uprawnieniami tylko do odczytu może pobrać rzeczywisty sekret zamiast symbolu zastępczego magazynu. Dzieje się tak z powodu niewłaściwego egzekwowania granic, co prowadzi do ujawnienia wrażliwych poświadczeń.

W Keycloak znaleziono błąd w endpoint REST default-groups oraz reprezentacji realm. Delegowany administrator z uprawnieniami do przeglądania realm może zobaczyć nazwy i identyfikatory ukrytych domyślnych grup, nawet jeśli nie ma do nich bezpośrednich uprawnień.

W REST API administracyjnym Keycloak wykryto brak autoryzacji podczas usuwania roli podrzędnej z roli złożonej. Delegowany administrator może usunąć uprzywilejowane role, do których nie ma uprawnień, co prowadzi do utraty dostępu dla innych użytkowników i administratorów.

W komponencie keycloak-services, będącym rdzeniem Red Hat Build of Keycloak, wykryto podatność polegającą na braku maskowania poufnych wartości konfiguracyjnych, takich jak tajne klucze reCAPTCHA, podczas ich wyświetlania administratorom z uprawnieniami tylko do odczytu. Może to prowadzić do ujawnienia poświadczeń usług zewnętrznych nieupoważnionym osobom lub w logach administracyjnych.

W Keycloak stwierdzono niekompletną poprawkę dla CVE-2026-9798. Ochrona przed atakami brute-force została dodana do procedury inicjacji CIBA, ale pominięto ją w procedurze wymiany tokenów. Pozwala to atakującemu z ważnymi danymi uwierzytelniającymi klienta uzyskać tokeny dostępu i odświeżania dla zablokowanego konta użytkownika, jeśli żądanie uwierzytelnienia zostało rozpoczęte przed blokadą i zatwierdzone przez użytkownika.

W Keycloak wykryto lukę w mechanizmie Client Policies, która umożliwia ominięcie wymogu uwierzytelniania za pomocą podpisanych asercji JWT. Atakujący posiadający prawidłowe dane logowania klienta może dostarczyć fałszywy, niepodpisany nagłówek asercji, oszukując system, że wymagania polityki zostały spełnione.

W komponencie keycloak-services Red Hat Build of Keycloak kody autoryzacyjne OAuth 2.0 nie są prawidłowo powiązane z klientem, który je pierwotnie zażądał. Atakujący, który przechwyci kod, może go zmodyfikować i zrealizować we własnym kliencie, uzyskując tokeny dostępu dla tożsamości ofiary.

W komponencie zarządzania organizacjami w Keycloak stwierdzono błąd. Delegowany administrator z uprawnieniami do zarządzania organizacjami może utworzyć zaproszenie dla nieistniejącego adresu e-mail, a następnie pobrać tajny link rejestracyjny bezpośrednio przez API. Używając tego linku, administrator może utworzyć nowe konta użytkowników i dodać je do organizacji bez wymaganych uprawnień do zarządzania użytkownikami ani dostępu do zaproszonego konta e-mail. Pozwala to administratorowi ominąć granice bezpieczeństwa i dodać nieautoryzowanych członków do organizacji.

W komponencie keycloak-services Keycloaka wykryto podatność polegającą na nieprawidłowej walidacji podczas aktualizacji dostawcy tożsamości OIDC przez delegowanego administratora. Gdy administrator używa maskowanej wartości zastępczej dla sekretu klienta, Keycloak ponownie wykorzystuje istniejący prawdziwy sekret, nawet jeśli zmieniono wrażliwe pola, takie jak URL tokena. Umożliwia to atakującemu przekierowanie i przechwycenie sekretu.

W Keycloak wykryto podatność w funkcji wyszukiwania grup w API administracyjnym. Gdy włączone są szczegółowe uprawnienia administracyjne (FGAP v2), delegowany administrator może ominąć ograniczenia dostępu i zobaczyć grupy nadrzędne, do których nie ma uprawnień. Wyszukując grupę podrzędną, system błędnie zwraca pełne dane grupy nadrzędnej, ujawniając wrażliwe atrybuty i konfigurację.

W Keycloak wykryto lukę w funkcji podglądu autoryzacji JWT. Gdy konto użytkownika jest wyłączone, system nie sprawdza jego statusu podczas przetwarzania grantu autoryzacyjnego JWT, co pozwala atakującemu na uzyskanie tokena dla wyłączonego użytkownika.

W pakiecie org.keycloak.broker.oidc wykryto błąd polegający na nieprawidłowej synchronizacji atrybutu email_verified. Gdy dostawca OIDC ma ustawione trustEmail=true i włączony jest endpoint userinfo, Keycloak pobiera adres email z odpowiedzi userinfo, ale status email_verified wyłącznie z id_token. Brak walidacji, czy email_verified w id_token dotyczy tego samego adresu email co z userinfo, pozwala na błędne oznaczenie dowolnego adresu email jako zweryfikowanego.

W implementacji Fine-Grained Admin Permissions (FGAP) v2 w Keycloak wykryto lukę, która pozwala delegowanemu administratorowi na przeglądanie szczegółów podgrup, do których nie ma bezpośredniego dostępu. Problem występuje, gdy system nie filtruje poprawnie podgrup na podstawie uprawnień wywołującego przy żądaniu przez grupę nadrzędną.

W Keycloak znaleziono podatność w komponencie ClientResource usług administracyjnych, gdy włączone są szczegółowe uprawnienia administracyjne (FGAP) v2. Umożliwia ona delegowanemu administratorowi, który powinien mieć ograniczoną kontrolę nad konkretnymi klientami, dołączanie lub usuwanie ukrytych zakresów klienta, do których nie ma autoryzacji.

W interfejsie administracyjnym Keycloak wykryto podatność, która umożliwia administratorom z ograniczonymi uprawnieniami podgląd informacji o grupach, do których nie powinni mieć dostępu. Gdy włączone są nowe szczegółowe uprawnienia administracyjne (FGAP v2), administrator widzący konkretną rolę może również zobaczyć listę wszystkich grup przypisanych do tej roli, bez weryfikacji uprawnień do tych grup. Pozwala to na ujawnienie ukrytych grup oraz ich szczegółów, takich jak nazwy wewnętrzne i ustawienia niestandardowe, które mogą zawierać wrażliwe informacje o wdrożeniu.

W Keycloak wykryto podatność, która pozwala użytkownikowi z uprawnieniem `manage-clients` na wstrzyknięcie twardo zakodowanego mapowania ról do dowolnego klienta. Działanie to umożliwia ominięcie istniejących ograniczeń zakresu i dodanie roli `realm-admin` do generowanych tokenów, co prowadzi do eskalacji uprawnień i pełnego dostępu administracyjnego do realm.

W Keycloak Admin UI wykryto podatność, która pozwala administratorom z ograniczonymi uprawnieniami na ominięcie zabezpieczeń. Gdy włączone są szczegółowe uprawnienia administracyjne (FGAPv2), administrator mający jedynie prawo wyszukiwania użytkowników może użyć endpointu 'brute-force-user', aby uzyskać pełny profil użytkownika, w tym wrażliwe dane i metadane bezpieczeństwa. Problem wynika z braku weryfikacji uprawnienia 'view' dla konkretnego użytkownika przy użyciu tej ścieżki wyszukiwania.

W komponencie mapowania dostawcy tożsamości (IdP) w Keycloak wykryto podatność, która pozwala administratorowi z ograniczonymi uprawnieniami na przypisanie sobie lub innym użytkownikom wysokopoziomowych ról administracyjnych (np. realm-admin) poprzez utworzenie mapowania „Hardcoded Role”. Umożliwia to ominięcie kontroli bezpieczeństwa i przejęcie pełnej kontroli nad całym realmem.

W Keycloak wykryto podatność polegającą na pomyleniu algorytmu JWT w przepływie JWT Authorization Grant. Umożliwia ona atakującemu posiadającemu ważne dane uwierzytelniające klienta ominięcie weryfikacji podpisu poprzez sfałszowanie asercji.

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