Podatności Keycloak

Wada w listenerze metryk zdarzeń użytkownika Micrometer w Keycloak występuje, gdy listener jest skonfigurowany do uwzględniania tagu idp. Nieuwierzytelniony atakujący może wysyłać żądania do endpointu logowania brokera tożsamości z dowolnymi aliasami dostawców, powodując tworzenie nieograniczonej liczby szeregów czasowych metryk, co prowadzi do nadmiernego zużycia pamięci i degradacji wydajności serwera oraz narzędzi monitorujących.

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.

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.

Wykryto błąd w mechanizmie dostawcy wymaganych akcji w Keycloak. Gdy żądanie autoryzacji zawiera parametr kc_action wskazujący na obowiązkową akcję już przypisaną użytkownikowi (np. weryfikację profilu lub regulamin), Keycloak może pominąć te obowiązkowe wyzwania i wydać kod autoryzacyjny.

Wykryto błąd w punkcie końcowym rejestracji zasobów UMA w komponencie keycloak-services. Gdy włączone jest zdalne zarządzanie zasobami, uwierzytelniony użytkownik z określonymi uprawnieniami może zaktualizować zasoby, których nie jest właścicielem, podając w żądaniu identyfikator docelowego zasobu.

W polityce klienta secure-redirect-uris-enforcer w Keycloak, rozwiązaniu do zarządzania tożsamością i dostępem, wykryto błąd. Występuje on, gdy polityka zezwala na adresy loopback, ponieważ Keycloak rozwiązuje nazwy hostów przez DNS podczas walidacji. Atakujący może obejść ograniczenia listy dozwolonych domen, używając nazwy hosta rozwiązującej się na adres loopback, co potencjalnie pozwala zarejestrować nieautoryzowane URI przekierowania.

W mechanizmie uwierzytelniania HOTP komponentu keycloak-services system waliduje jednorazowe hasło i aktualizuje wewnętrzny licznik w dwóch oddzielnych krokach bez odpowiedniego blokowania. Atakujący znający hasło użytkownika może wykorzystać tę lukę czasową, aby użyć jednego kodu jednorazowego do wielokrotnego logowania jednocześnie.

W implementacji Pushed Authorization Request (PAR) komponentu keycloak-services ponowne uruchomienie przepływu uwierzytelniania nieprawidłowo czyści wewnętrzne znaczniki zużycia PAR, pozostawiając żądanie aktywne. Atakujący może ponownie użyć tego samego żądania autoryzacji do uzyskania wielu tokenów dostępu, omijając wymóg jednorazowości.

W komponencie rejestracji klienta Keycloak, gdy dostawca vault jest używany do przechowywania wrażliwych informacji, uwierzytelniony właściciel klienta może użyć specjalnie spreparowanego odwołania, aby ujawnić sekrety. Poprzez zmianę sekretu klienta na wpis w vault i następnie żądanie konfiguracji klienta właściciel może zobaczyć wartość sekretu w postaci jawnej.

W implementacji JWT Authorization Grant komponentu keycloak-services, gdy dostawca tożsamości OIDC lub Google jest skonfigurowany z określonymi ograniczeniami logowania, takimi jak filtrowanie oświadczeń, sprawdzenia te są stosowane podczas standardowych logowań w przeglądarce, ale pomijane w przepływie grantu opartego na JWT. Umożliwia to uwierzytelnionemu klientowi uzyskanie tokenów dostępu dla użytkownika, nawet jeśli jego oświadczenia dostawcy tożsamości powinny blokować logowanie.

Wykryto błąd w wymaganej akcji Update User Locale w rozwiązaniu Keycloak. Gdy akcja ta jest uporządkowana przed akcją Configure OTP w realmie, system może nie wymuszać obowiązkowej rejestracji uwierzytelniania wieloskładnikowego podczas logowania. Pozwala to atakującemu z ważnym hasłem uzyskać dostęp do konta bez skonfigurowania wymaganego jednorazowego hasła (OTP).

W komponencie keycloak-services Keycloak znaleziono błąd w implementacji Client-Initiated Backchannel Authentication (CIBA). Keycloak nie weryfikuje, czy klient jest autoryzowany do korzystania z przepływu CIBA, co pozwala publicznym klientom ominąć wymagania bezpieczeństwa. Atakujący może wykorzystać tę wadę, aby nakłonić użytkownika do zatwierdzenia żądania logowania, uzyskując pełny dostęp do konta bez znajomości sekretu klienta.

Podatność w komponencie renderowania motywu logowania w Keycloak. Filtr bezpieczeństwa odpowiedzialny za czyszczenie danych wejściowych użytkownika może zostać ominięty, co pozwala administratorowi realm na przechowywanie złośliwych skryptów w polach wyświetlania. Może to prowadzić do nieautoryzowanego wykonania JavaScript w przeglądarkach użytkowników odwiedzających stronę logowania.

W komponencie OIDC Dynamic Client Registration (DCR) systemu Keycloak występuje błąd w serializacji odpowiedzi, który powoduje pominięcie ustawienia unieważniania tokenów offline w kanale zwrotnym (backchannel logout). Podczas standardowej aktualizacji klienta brak tych informacji powoduje ciche wyłączenie tego ustawienia. W rezultacie tokeny offline mogą pozostać ważne nawet po zakończeniu sesji użytkownika przez backchannel logout.

W instalatorze i punktach końcowych rejestracji klientów usługi zarządzania tożsamością Keycloak występuje błąd, który pozwala administratorowi realm z tylko rolą tylko do odczytu view-clients na dostęp do aktywnego głównego sekretu dowolnego klienta poufnego, co normalnie powinno być zabronione. Ujawniony sekret może być użyty do podszycia się pod klienta i uzyskania nieautoryzowanego dostępu do uprawnień powiązanego konta usługi.

Wada w obsłudze konfiguracji poczty SMTP w komponencie keycloak-services. Gdy opcja STARTTLS jest włączona, Keycloak nie wymusza ściśle szyfrowanego połączenia i może wrócić do komunikacji nieszyfrowanej, jeśli żądanie szyfrowania zostanie zmodyfikowane. Atakujący przechwytujący ruch sieciowy może przechwycić poświadczenia e-mail i treść wiadomości w postaci jawnej.

W implementacji OIDC w Keycloak, w przepływie Device Authorization Grant, nie jest sprawdzany minimalny poziom uwierzytelniania wymagany przez konfigurację klienta. Umożliwia to atakującemu, który zdobył hasło użytkownika, ominięcie obowiązkowego uwierzytelniania wieloskładnikowego i uzyskanie nieautoryzowanego dostępu do Keycloak Admin REST API.

W przepływie Dynamic Client Registration serwera Keycloak wykryto lukę polegającą na braku filtrowania wrażliwych atrybutów klienta podczas rejestracji nowego klienta. Atakujący posiadający ważny Initial Access Token może zarejestrować klienta omijającego sprawdzanie odbiorcy (audience) podczas introspekcji tokenów, co pozwala mu odczytywać dane tożsamości, role i szczegóły sesji z tokenów innych aplikacji w tym samym realmie.

W mapperze User Session Note rozwiązania Keycloak wykryto lukę polegającą na braku walidacji, czy żądana notatka sesji zawiera wrażliwe wewnętrzne poświadczenia, takie jak sfederowane tokeny dostępu od zewnętrznych dostawców tożsamości. Umożliwia to delegowanemu administratorowi klienta wyciek tokenów bearer użytkownika do tokenów wydawanych zarządzanej przez niego aplikacji.

W authenticatorze certyfikatów klienta X.509 rozwiązania Keycloak wykryto lukę występującą, gdy serwer jest skonfigurowany do sprawdzania unieważnienia certyfikatów za pomocą CRL Distribution Points lub OCSP. Atakujący może dostarczyć specjalnie spreparowany certyfikat wskazujący na złośliwy serwer, powodując, że Keycloak wykonuje nieautoryzowane żądania wychodzące do wewnętrznych lub zewnętrznych punktów końcowych przed pełną walidacją certyfikatu.

W Keycloak znaleziono błąd w uwierzytelnianiu certyfikatów klienta X.509. Gdy włączone jest sprawdzanie punktów dystrybucji list CRL, serwer niepoprawnie weryfikuje ścieżki plików podane w certyfikacie klienta. Atakujący może dostarczyć specjalnie spreparowany certyfikat, który powoduje próbę odczytu wrażliwych plików z systemu lub przeciążenie pamięci przez ładowanie bardzo dużych plików, co może prowadzić do ujawnienia informacji lub awarii systemu.

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.