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.

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 zarządzania klientami serwera Keycloak wykryto błąd. Podczas tworzenia lub importu klienta z włączonymi usługami autoryzacji system nie czyści prawidłowo atrybutu sesji używanego podczas konfiguracji. Uwierzytelniony atakujący z uprawnieniami do zarządzania klientami może ominąć mechanizmy bezpieczeństwa i przesłać złośliwą politykę JavaScript, która jest wykonywana na serwerze.

W implementacji wiązania SAML HTTP-Redirect w Keycloak występuje luka polegająca na tym, że serwer przetwarza nazwy parametrów zakodowane procentowo (np. %53AMLResponse), podczas gdy logika weryfikacji podpisu sprawdza tylko literalne nazwy parametrów. Atakujący może wykorzystać tę rozbieżność, dostarczając spreparowaną, niepodpisaną wiadomość SAML, którą serwer przetwarza zamiast legalnie podpisanej, co prowadzi do pełnego przejęcia konta użytkowników sfederowanych.

W Keycloak wykryto lukę w usługach administracyjnych (org.keycloak.services.resources.admin). Uprzywilejowany atakujący z rolą 'manage-clients' może m.in. manipulować zestawami kluczy JWKS klientów, podmieniać typy authenticatorów i resetować sekrety lub pobierać prawdziwe klucze podpisujące. Skuteczne wykorzystanie pozwala uzyskać token z przypisaną rolą 'realm-admin', co prowadzi do eskalacji uprawnień.

W Keycloak wykryto błąd w logice sanityzacji tokenów. Gdy mapper protokołu emituje strukturalne claims typu JSON, mechanizm usuwający nieautoryzowane mapowania ról rozpoznaje tylko standardowe mapy Java, a nie obiekty JSON oparte na Jacksonie. Umożliwia to atakującemu wstrzyknięcie sfałszowanych ról klienta do tokenów bezpieczeństwa.

W Keycloak Account REST API występuje błąd w obsłudze identyfikacji sesji. Złośliwy właściciel klienta może zmodyfikować własne tokeny bezpieczeństwa tak, aby wskazywały na aktywną sesję innego użytkownika. Pozwala to na dostęp i modyfikację danych ofiary, w tym zmianę adresu e-mail odzyskiwania i reset hasła.

W komponencie Dynamic Client Registration w Keycloak system nie ogranicza należycie nazw claims używanych przy tworzeniu nowych klientów. Atakujący z ważnymi poświadczeniami rejestracyjnymi może utworzyć klienta, który błędnie mapuje standardowe informacje profilu użytkownika na wrażliwe role bezpieczeństwa.

W mechanizmie token exchange w Keycloak (Standard Token Exchange V2) nowe tokeny otrzymują świeży czas życia oparty na konfiguracji klienta żądającego, zamiast być ograniczone do wygaśnięcia tokenu oryginalnego. Uwierzytelniony żądający może wielokrotnie wymieniać tokeny, aby w nieskończoność przedłużać dostęp dla kont usługowych.

W komponencie TokenManager w Keycloak występuje błąd podczas walidacji bezstanowych tokenów dostępu, gdy oryginalny identyfikator użytkownika już nie istnieje. Keycloak nieprawidłowo używa nazwy użytkownika do identyfikacji bez weryfikacji zgodności z podmiotem oryginalnego tokenu. Może to pozwolić atakującemu ze starym tokenem na dostęp do nowo utworzonego konta usługowego o tym samym client ID.

W komponencie SAML brokering w Keycloak, działającym jako pośrednik między dostawcą tożsamości a usługami końcowymi, system nie respektuje ograniczeń ProxyRestrictions w otrzymywanych komunikatach logowania. Użytkownik może zalogować się do usług końcowych, nawet gdy oryginalny dostawca tożsamości wyraźnie zabronił dalszego udostępniania sesji.

W Admin REST API w Keycloak występuje błąd polegający na braku weryfikacji docelowego odbiorcy tokenów bearer podczas uwierzytelniania. Atakujący obsługujący klienta w realmie może przechwycić token dostępu administratora i użyć go do wykonania nieautoryzowanych działań administracyjnych.

W Keycloak endpoint Dynamic Client Registration (DCR) nie weryfikuje należycie autoryzacji przy przetwarzaniu przestarzałego pola defaultRoles. Uwierzytelniony atakujący z uprawnieniami do tworzenia klientów lub Initial Access Token może wstrzyknąć nadmierne role do konfiguracji domyślnych ról realmu. Powoduje to generowanie rozbudowanych tokenów dostępu dla klientów w całym realmie.

W komponentach protocol mapper i identity resolution w Keycloak występuje błąd. Gdy menedżer klienta używa mapperów hardcoded-claim do nadpisania tożsamości w tokenach service-account bez sesji, Keycloak może błędnie rozpoznać posiadacza tokenu jako innego, wysoko uprzywilejowanego użytkownika. Może to pozwolić atakującemu z ograniczonymi uprawnieniami do zarządzania klientami na podszycie się pod administratora realm i przejęcie pełnej kontroli.

Występuje błąd w autentykatorze idp-auto-link komponentu keycloak-services, który obsługuje federację tożsamości. Keycloak automatycznie łączy tożsamość z zewnętrznego dostawcy z istniejącym kontem lokalnym na podstawie adresu e-mail, nie sprawdzając, czy dostawca zweryfikował ten e-mail. Może to pozwolić atakującemu na przejęcie konta ofiary przy użyciu pasującego, niezweryfikowanego adresu e-mail u dostawcy brokera.

W implementacji Client-Initiated Backchannel Authentication (CIBA) w Keycloak punkt końcowy CIBA nieprawidłowo waliduje parametr sub, pozwalając na zapisanie go jako dodatkowego parametru żądania. Podczas wydawania tokena wstrzyknięta wartość nadpisuje prawidłowy identyfikator podmiotu, co pozwala atakującemu uwierzytelnić się jako siebie i otrzymać tokeny należące do innego użytkownika.

Występuje błąd w narzędziu Keycloak Admin CLI kcadm, używanym przez administratorów do zarządzania serwerami Keycloak z wiersza poleceń. Gdy podano niestandardowy truststore do weryfikacji tożsamości serwera, narzędzie niepoprawnie akceptuje każdy certyfikat samopodpisany, o ile nazwa hosta się zgadza. Pozwala to atakującemu w sieci na podszycie się pod serwer Keycloak, kradzież poświadczeń administracyjnych i nieautoryzowane działania zarządzające.

Występuje błąd w komponencie SAML adapter w Keycloak, używanym do zabezpieczania aplikacji uwierzytelnianiem SAML. Adapter nie weryfikuje, czy wystawca podpisanej asercji SAML odpowiada oczekiwanemu dostawcy tożsamości skonfigurowanemu dla aplikacji. Jeśli wiele dostawców tożsamości współdzieli ten sam zaufany klucz podpisujący, atakujący kontrolujący jednego z nich może utworzyć poprawnie podpisaną asercję i zalogować się do aplikacji jako dowolny użytkownik, potencjalnie uzyskując pełną kontrolę administracyjną.

Keycloak udostępnia funkcję Dynamic Client Registration, która pozwala użytkownikom z określonymi tokenami rejestrować własne aplikacje. Błąd w walidacji tych żądań rejestracji pozwala atakującemu utworzyć złośliwą aplikację fałszującą informacje o tożsamości. Poprzez mapowanie własnych danych profilu na chronione pola, takie jak identyfikator użytkownika (sub) lub docelowa grupa odbiorców (aud), atakujący może generować podpisane tokeny bezpieczeństwa, które przedstawiają go jako innego użytkownika.

Występuje błąd w komponencie SAML identity broker w Keycloak, używanym do delegowania uwierzytelniania do zewnętrznych dostawców tożsamości. Broker nie weryfikuje, czy użytkownik faktycznie posiada klucz prywatny powiązany z asercją holder-of-key. Atakujący, który przechwyci podpisaną asercję ofiary, może ją odtworzyć, aby uzyskać nieautoryzowany dostęp i podszyć się pod ofiarę bez potrzeby posiadania jej klucza prywatnego.

W implementacji SAML w Keycloak punkty końcowe SAML Artifact Resolution i ECP SOAP nie ograniczają odpowiednio rozmiaru ani złożoności przychodzących żądań XML. Nieuwierzytelniony zdalny atakujący może wysłać specjalnie spreparowane, duże wiadomości XML powodujące nadmierne zużycie pamięci.

W UserManagedPermissionService serwera autoryzacji Keycloak wykryto błąd. API UMA Protection, zarządzające uprawnieniami użytkowników, nie waliduje pola resourceType podczas tworzenia nowej polityki przez użytkownika. Pozwala to atakującemu utworzyć politykę dotyczącą zasobów należących do innych użytkowników, co może prowadzić do nieautoryzowanego dostępu lub modyfikacji wrażliwych danych w całym realmie.

Błąd w przepływie logowania identity-first organizacji w serwerze uwierzytelniania Keycloak. Problem występuje, gdy atakujący należący do wielu organizacji rozpoczyna logowanie, a następnie przełącza się na ścieżkę rejestracji lub resetowania hasła. Flaga wskazująca pomyślne logowanie nie jest prawidłowo czyszczona, gdy użytkownik jest usuwany z sesji, co pozwala atakującemu podać nazwę użytkownika ofiary i obejść uwierzytelnianie.

W Keycloak wykryto błąd w punkcie końcowym zasobów motywów. Serwer nie weryfikuje nazw motywów przed użyciem ich jako kluczy w dyskowym cache gzip, co pozwala nieuwierzytelnionemu atakującemu wysyłać żądania z wymyślonymi nazwami motywów i trwale wyczerpać miejsce na dysku.

W parserze asercji SAML 1.1 w Keycloak występuje błąd przy obsłudze elementu AuthorityBinding w instrukcji uwierzytelniania. Z powodu niekompletnej wcześniejszej poprawki parser może wejść w nieskończoną pętlę zużywającą całą dostępną pamięć.

W logice parsowania XML SAML 1.1 w Keycloak występuje błąd, gdy parser napotyka nieoczekiwane elementy w sekcji informacji o kluczu tokenu bezpieczeństwa, co powoduje nieskończoną pętlę wątku przetwarzającego. Nieuwierzytelniony zdalny atakujący może to wykorzystać, wysyłając specjalnie spreparowane żądania.

W komponencie przetwarzania XML SAML w Keycloak występuje błąd podczas parsowania dokumentów XML zawierających nadmiernie długie wartości dateTime lub duration. Ponieważ ciągi te nie są odpowiednio walidowane, parser XML zużywa nadmierny czas CPU.

W obsłudze sesji uwierzytelniania komponentu keycloak-services w Keycloak występuje błąd polegający na braku weryfikacji, czy authenticator jest prawidłowy dla bieżącego przepływu uwierzytelniania przy przełączaniu między standardową ścieżką a ścieżką resetowania poświadczeń. Uwierzytelniony atakujący może wywołać warunek wyścigu podczas resetowania poświadczeń, aby powiązać swój stan uwierzytelnienia z sesją innego użytkownika.

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.

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.