Podatności Keycloak

W komponencie keycloak-services wykryto usterkę w przepływie pierwszego logowania brokera. Umożliwia ona atakującemu zarejestrowanie pasującej nazwy użytkownika u zewnętrznego dostawcy tożsamości, co powoduje kolizję w Keycloak i zablokowanie legalnego użytkownika.

Keycloak to open-source'owe rozwiązanie do zarządzania tożsamością i dostępem. Wykryto podatność, w której użytkownik posiadający rolę impersonacji może podszyć się pod administratora realm, uzyskując pełną kontrolę administracyjną nad realm, w tym możliwość zarządzania użytkownikami, klientami i rolami.

Wykryto lukę w endpointach lokalizacji motywów komponentu keycloak-services, który jest kluczową usługą odpowiedzialną za przepływy uwierzytelniania i zarządzanie motywami w Keycloak. Problem polega na tym, że system przyjmuje dowolne znaczniki locale z nieuwierzytelnionych żądań i przechowuje je w trwałym cache w pamięci bez ograniczeń. Atakujący może wysłać dużą liczbę unikalnych znaczników locale, doprowadzając do wyczerpania pamięci i awarii serwera.

Wada w implementacji SAML Redirect Binding w Keycloak polega na tym, że niestandardowe pomocniki kompresji i dekompresji DEFLATE nie zwalniają natywnej pamięci zlib po użyciu. Nieuwierzytelniony atakujący może wysyłać powtarzające się zniekształcone żądania SAML, prowadząc do wyczerpania natywnej pamięci i odmowy usługi.

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 funkcji Fine-Grained Admin Permissions (FGAP v2) w Keycloak występuje luka polegająca na tym, że system nie sprawdza zawartości ról złożonych przy weryfikacji uprawnień delegowanego administratora. Administrator o ograniczonych uprawnieniach może przypisać rolę, która w ukryty sposób zawiera pełną kontrolę administracyjną.

W Keycloak funkcja mTLS holder-of-key binding wiąże token z certyfikatem klienta, który go zażądał. Nowa funkcja Standard Token Exchange V2 nie sprawdza tego certyfikatu, co pozwala atakującemu z skradzionymi poświadczeniami klienta uzyskać standardowy, nieograniczony token.

W interfejsie Admin REST API rozwiązania Keycloak wykryto błąd polegający na tym, że punkty końcowe służące do pobierania grup przypisanych do roli nie sprawdzają prawidłowo uprawnień widoczności poszczególnych grup. Umożliwia to delegowanemu administratorowi z podstawowymi uprawnieniami wyszukiwania przeglądanie szczegółowych informacji o wszystkich grupach przypisanych do roli, z pominięciem ograniczeń bezpieczeństwa.

W mechanizmie aktualizacji użytkownika w Keycloak Admin REST API wykryto błąd. Gdy włączone są szczegółowe uprawnienia administratora, system nie sprawdza uprawnień do resetowania hasła podczas ogólnej aktualizacji profilu użytkownika, co pozwala delegowanemu administratorowi zmienić poświadczenia użytkownika i przejąć jego konto.

W mechanizmie wymuszania poziomu uwierzytelniania w Keycloak występuje błąd logiczny. Gdy klient wymaga wyższego poziomu bezpieczeństwa dla użytkownika z aktywną sesją na niższym poziomie, Keycloak może błędnie wydać token na niższym poziomie zamiast wymusić wyższy, co może pozwolić na nieautoryzowany dostęp do zasobów wrażliwych.

Podatność w implementacji Pushed Authorization Request (PAR) w Keycloak. Gdy używana jest cicha autoryzacja (prompt=none), proces autoryzacji pomija niektóre kroki, co uniemożliwia egzekwowanie zasady jednorazowego użycia URI żądania. Atakujący może wielokrotnie użyć tego samego URI, aby uzyskać wiele kodów autoryzacyjnych dla zalogowanego użytkownika, naruszając standardy bezpieczeństwa takie jak FAPI-2.

Podatność w warunkowym uwierzytelnianiu OTP w Keycloak. System ocenia nagłówki HTTP, aby zdecydować, czy pominąć OTP, ale nie weryfikuje ich zaufanego źródła. Atakujący znający hasło użytkownika może obejść drugi składnik uwierzytelniania, dodając specjalnie spreparowany nagłówek.

W Keycloak wykryto lukę w dostawcy federacji Kerberos. Gdy używane jest uwierzytelnianie hasłem Kerberos bez SPNEGO, system nie weryfikuje tożsamości Centrum Dystrybucji Kluczy (KDC), co pozwala atakującemu w tej samej sieci podszyć się pod KDC i ominąć proces uwierzytelniania.

Znaleziono błąd w zarządzaniu sesjami uwierzytelniania w Keycloak. Gdy administrator wymusza silniejszy przepływ uwierzytelniania, np. obowiązkowe skonfigurowanie dwuskładnikowego uwierzytelniania (2FA), użytkownik może ominąć ten wymóg, ręcznie odwiedzając konkretny link restartu sesji podczas logowania. To działanie czyści wewnętrzne znaczniki śledzące wymagane kroki bezpieczeństwa, umożliwiając zalogowanie się tylko hasłem bez ukończenia wymaganego 2FA.

Znaleziono błąd w implementacji User-Managed Access (UMA) w Keycloak. Problem występuje w punkcie końcowym tokenów autoryzacji podczas przetwarzania biletów uprawnień. Jeśli dwóch różnych użytkowników posiada zasoby o tej samej nazwie, system błędnie scala uprawnienia z obu zasobów, gdy jeden użytkownik żąda tokena autoryzacji. Pozwala to atakującemu uzyskać zakresy dostępu do zasobu ofiary, które nigdy nie były przeznaczone do udostępnienia.

W Admin REST API produktu Keycloak wykryto usterkę polegającą na tym, że API używa pamięci podręcznej per-request do rozwiązywania klientów po ich unikalnym identyfikatorze bez weryfikacji, czy klient należy do realm określonego w ścieżce żądania. Umożliwia to administratorowi o ograniczonych uprawnieniach odczyt lub modyfikację poufnych konfiguracji klientów w realm master poprzez dostęp przez kontrolowany realm.

W komponencie Authorization Services produktu Keycloak wykryto usterkę w endpointcie oceny polityk, używanym przez administratorów do testowania, jak polityki dostępu mają zastosowanie do konkretnych użytkowników. Z powodu braku kontroli autoryzacji delegowany administrator o ograniczonych uprawnieniach przeglądania może uzyskać dostęp do pełnego profilu i informacji o rolach dowolnego użytkownika w realm, nawet jeśli nie ma uprawnień do przeglądania danych użytkowników.

W Admin REST API Keycloak, rozwiązania do zarządzania tożsamością i dostępem, wykryto lukę. Endpoint służący do usuwania poświadczeń użytkownika nie sprawdza poprawnie szczegółowych uprawnień do resetowania hasła, co pozwala delegowanemu administratorowi, który powinien być ograniczony od resetowania haseł, na usunięcie poświadczeń hasła użytkownika i uniemożliwienie mu zalogowania się.

W Admin REST API Keycloak, rozwiązania do zarządzania tożsamością i dostępem, wykryto lukę w endpointach członkostwa w grupach. System nie sprawdza, czy grupa przyznaje uprawnienia administracyjne, przed dodaniem użytkownika, co pozwala delegowanemu administratorowi z ograniczonymi uprawnieniami na dodanie siebie do grupy o wysokich uprawnieniach i potencjalne przejęcie pełnej kontroli nad całym realmem.

W implementacji protokołu OIDC w Keycloak, rozwiązaniu do zarządzania tożsamością i dostępem, wykryto lukę. Podczas odświeżania tokenu, gdy serwer przywraca żądane odbiorców z przechowywanych identyfikatorów klientów, Keycloak nie sprawdza, czy docelowy klient odbiorcy jest nadal włączony, przed wydaniem nowego tokenu dostępu. Pozwala to aplikacji z istniejącym tokenem odświeżania na dalsze uzyskiwanie ważnych tokenów dostępu dla wyłączonego klienta, potencjalnie omijając administracyjne kontrole dostępu dla serwerów zasobów opierających się na offline walidacji JWT.

W Keycloak wdrożonym w trybie bezstanowym z MySQL lub MariaDB niezgodność semantyki liczby wierszy między sterownikiem bazy danych a logiką aplikacji Keycloak pozwala atakującemu obejść ochronę przed powtórzeniem. Luka umożliwia atakującemu, który przechwyci jednorazowe artefakty bezpieczeństwa, takie jak asercje klienta JWT, dowody DPoP lub kody jednorazowe (TOTP), ich powtórne użycie. Udana eksploatacja daje nieautoryzowany dostęp do endpointu tokenów lub przepływu logowania.

Keycloak policy enforcer nieprawidłowo normalizuje adresy URL zawierające specjalne znaki kodowane, takie jak średniki lub segmenty przejścia katalogowego. Uwierzytelniony użytkownik może wykorzystać te znaki, aby zmusić enforcer do zastosowania mniej restrykcyjnej polityki bezpieczeństwa niż zamierzona, uzyskując nieautoryzowany dostęp do wrażliwych punktów końcowych administracyjnych lub prywatnych.

W Keycloak znaleziono błąd w pierwszym przepływie logowania brokera. Gdy użytkownik potwierdza żądanie połączenia konta z innej przeglądarki, tworzony jest tymczasowy dowód w celu weryfikacji połączenia. Jednak ten dowód nie jest prawidłowo usuwany po ustanowieniu połączenia lub gdy użytkownik później ręcznie usunie połączenie. Atakujący kontrolujący zewnętrzną tożsamość może wykorzystać ten pozostawiony dowód, aby po cichu ponownie ustanowić połączenie i uzyskać nieautoryzowany dostęp do konta ofiary bez dalszego potwierdzenia.

W usłudze Dynamic Client Registration w Keycloak wykryto usterkę polegającą na tym, że użytkownik z rolą view-clients uzyskujący dostęp do endpointu rejestracji klienta otrzymuje poufny sekret klienta w postaci jawnej z powodu braku maskowania danych wrażliwych.

W przepływie Device Authorization Grant w Keycloak występuje luka polegająca na tym, że proces wymiany tokenu nie sprawdza, czy konto użytkownika jest zablokowane przez ochronę przed atakami brute-force. Jeśli atakujący posiada aktywną sesję dla zablokowanego konta, może dokończyć logowanie urządzenia i otrzymać nowe tokeny bezpieczeństwa.

Znaleziono błąd w przepływie pierwszego logowania brokera w usłudze zarządzania tożsamością Keycloak. Gdy użytkownik łączy konto dostawcy tożsamości społecznościowej ze swoim lokalnym kontem, generowany dowód weryfikacji nie jest ściśle powiązany z konkretną tożsamością upstream, która jest weryfikowana. Pozwala to atakującemu z innym kontem u tego samego dostawcy społecznościowego na przechwycenie procesu i powiązanie własnego konta z profilem ofiary, uzyskując nieautoryzowany dostęp.

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.