Podatności Keycloak

Znaleziono błąd w dostawcy polityk grupowych usług autoryzacji Keycloak, który jest używany do zarządzania precyzyjną kontrolą dostępu do zasobów. Problem występuje, gdy system ocenia polityki oparte na grupach przy użyciu tokenów zawierających tylko nazwy grup, a nie pełne ścieżki. Jeśli dwie grupy w różnych częściach organizacji mają tę samą nazwę, użytkownik z nieautoryzowanej grupy może zostać uznany za członka autoryzowanej grupy. Może to pozwolić użytkownikowi na nieautoryzowany dostęp do chronionych zasobów, do których nie powinien mieć dostępu.

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.

Wykryto, że ciasteczko używane do zapobiegania CSRF w Keycloak nie było unikalne dla każdej sesji. Atakujący mógł wykorzystać tę lukę, aby uzyskać dostęp do sesji uwierzytelnionego użytkownika, co może prowadzić do ujawnienia informacji lub dalszych ataków.

W komponencie keycloak-services Red Hat Build of Keycloak występuje błąd w implementacji grantu JWT Bearer. Grant nie sprawdza, czy klient wymaga zgody użytkownika przed wydaniem tokena. Pozwala to uwierzytelnionemu atakującemu z ważnymi poświadczeniami klienta i zaufanym asercją dostawcy tożsamości na obejście wymogu zgody i uzyskanie nieautoryzowanego dostępu do konta użytkownika w kliencie wymagającym zgody.

Keycloak zawiera podatność w legacy endpoint do łączenia kont, gdzie mechanizm ochrony oparty na hashu może być przewidziany przez złośliwego klienta OIDC. Atakujący może sfałszować link łączący, aby połączyć konto ofiary z zewnętrzną tożsamością atakującego, co prowadzi do pełnego przejęcia konta.

W komponencie SAML broker w Keycloak, gdy skonfigurowano przepływ IdP-Initiated, nie jest egzekwowany warunek OneTimeUse w asercjach SAML. Pozwala to atakującemu, który przechwyci ważną, nieużywaną asercję, na jej wielokrotne odtworzenie, co może prowadzić do przejęcia sesji użytkownika.

Podatność w komponencie SAML broker w Keycloak, używanym do zarządzania federacją tożsamości i uwierzytelnianiem użytkowników. Problem polega na tym, że punkt końcowy Single Sign-On inicjowany przez IdP nie sprawdza, czy dostawca jest ograniczony tylko do łączenia kont. Pozwala to atakującemu kontrolującemu powiązane upstream tożsamości ominąć ograniczenia logowania i uzyskać pełny dostęp do lokalnego konta użytkownika.

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.