Podatności OpenAM

W OpenAM 10.1.0 występuje podatność XXE (XML External Entity) w ścieżce /SSOPOST/metaAlias/%realm%/idpv2, która pozwala zdalnym atakującym na odczyt dowolnych plików za pomocą parametru SAMLRequest.

W OpenAM w wersjach przed 16.1.2 endpoint pre-autoryzacji /authservice PLL przyjmuje element XML CustomCallback, którego wartość className pozwala na załadowanie i utworzenie dowolnej klasy Java bez weryfikacji, czy implementuje DSAMECallbackInterface. Domyślna konfiguracja udostępnia ten endpoint bez uwierzytelnienia, co umożliwia atakującemu wykonanie kodu w procesie serwera poprzez niebezpieczną deserializację. Włączenie opcji sunRemoteAuthSecurityEnabled nie zapobiega temu, ponieważ sprawdzenie następuje zbyt późno.

W OpenAM w wersjach przed 16.1.2 metoda WebAuthnAuthentication.deserialize stosuje ObjectInputFilter, który zezwala na każdy serializowany obiekt na głębokości większej niż 1, ograniczając jedynie obiekt główny AuthenticatorImpl. Atakujący przed uwierzytelnieniem może dostarczyć userHandle, którego graf serializacji zawiera prawidłowy obiekt główny AuthenticatorImpl oraz zagnieżdżoną klasę gadget, powodując wykonanie readObject lub readResolve przed weryfikacją. Omija to niekompletną naprawę wcześniejszej podatności deserializacji WebAuthn.

W OpenAM w wersjach przed 16.1.1 AuthorizationCodeGrantTypeHandler wymaga code_verifier tylko wtedy, gdy włączone jest ustawienie codeVerifierEnforced dla całego realm. Ponieważ ustawienie jest domyślnie wyłączone, atakujący, który przechwyci kod autoryzacyjny chroniony przez PKCE, może pominąć code_verifier i wymienić kod na token. Klienci publiczni są bezpośrednio narażeni, a wykorzystanie dla klientów poufnych wymaga dodatkowo materiału uwierzytelniającego klienta.

W OpenAM w wersjach przed 16.1.1 moduł uwierzytelniania MSISDN w MSISDNValidation konkatenuje wartość MSISDN z żądania do filtra wyszukiwania LDAP bez escapowania, a domyślna pusta lista zaufanych bram pozwala na cały ruch. W realmie, w którym moduł MSISDN jest włączony w osiągalnym łańcuchu uwierzytelniania, nieuwierzytelniony zdalny atakujący może wstrzyknąć metaznaki filtra LDAP, wybrać dowolnego pasującego użytkownika i uzyskać sesję OpenAM bez hasła.

W OpenAM w wersjach przed 16.1.1 odbiornik SOAP Liberty Web Services pozwala nieuwierzytelnionym zdalnym żądaniom zapisywać trwałe wpisy przez SOAPReceiver i DiscoveryService do magazynu Liberty Discovery użytkownika oraz współdzielonej gałęzi Discovery root-realm. Handlery po stronie serwera omijają ACL LDAP i tożsamości, a ścieżka globalna używa wewnętrznego tokenu administracyjnego. Wdrożenia korzystające z danych Liberty discovery mogą następnie używać zmanipulowanych rekordów routingu usług lub mechanizmów bezpieczeństwa.

W OpenAM w wersjach przed 16.1.1 WebAuthnAuthentication ładuje serializowany graf obiektów AuthenticatorImpl z skonfigurowanego userAttribute przez loadAuthenticators bez ObjectInputFilter. Wykorzystanie wymaga osiągalności przepływu WebAuthn oraz wcześniejszego zapisania kontrolowanych danych do tego atrybutu przez delegowaną administrację, provisioning, dostęp do katalogu, starszą samo-rejestrację REST lub niebezpieczną konfigurację. Gdy te warunki są spełnione, dane są deserializowane przed weryfikacją asercji i mogą wykonać gadget z classpath w procesie serwera aplikacji.

OpenAM przed wersją 16.0.6 jest podatny na zdalne wykonanie kodu (RCE) przed uwierzytelnieniem poprzez niebezpieczną deserializację Java parametru HTTP jato.clientSession. Atakujący omija zabezpieczenie WhitelistObjectInputStream zastosowane dla parametru jato.pageSession po CVE-2021-35464. Wystarczy wysłać spreparowany serializowany obiekt Java jako parametr GET/POST do dowolnego endpointu JATO ViewBean zawierającego tagi <jato:form>.

OpenAM do wersji 14.7.2 nieprawidłowo weryfikuje podpisy odpowiedzi SAML w procesie SSO, co pozwala atakującym na podszywanie się pod dowolnego użytkownika OpenAM, w tym administratora.

W OpenAM przed wersją 16.1.1 moduł uwierzytelniania RADIUS otwiera niepołączony socket datagramowy i ufa pierwszemu datagramowi UDP odebranemu na porcie źródłowym klienta. Ścieżka odbioru nie weryfikuje źródłowego IP i portu, nie dopasowuje identyfikatora odpowiedzi do żądania ani nie sprawdza Response Authenticator (RFC 2865); Message-Authenticator (RFC 2869) nie jest wysyłany ani wymagany. Każdy pakiet inny niż Reject/Challenge jest traktowany jako sukces, więc atakujący może wyścignąć prawdziwy serwer lub rozsyłać sfałszowane Access-Accept i uzyskać sesję dla dowolnej nazwy użytkownika mapowanej na RADIUS bez znajomości wspólnego sekretu.

W OpenAM przed wersją 16.1.1 servlet Cross-Domain Single Sign-On (CDSSO) pozwala na wysłanie surowego tokenu sesji zalogowanego użytkownika metodą POST na adres URL kontrolowany przez atakującego. Atakujący może nakłonić uwierzytelnioną ofiarę do odwiedzenia spreparowanego adresu i przechwycić poświadczenie sesji.

OpenAM przed wersją 16.1.3 zawiera podatność na SSRF (Server-Side Request Forgery). Atakujący, którzy mogą rejestrować lub modyfikować klientów OAuth 2.0, mogą sprawić, że OpenAM pobierze wewnętrzne zasoby poprzez niezweryfikowany jwks_uri. Mogą wywołać nieuwierzytelnione pobrania w celu badania wewnętrznych hostów, punktów metadanych lub plików lokalnych, a także wyczerpać wątki żądań dla DoS.

OpenAM przed wersją 16.1.3 zawiera podatność na nieprawidłową autoryzację, która pozwala delegowanym administratorom niszczyć sesje poza ich realmami, ponieważ sprawdzanie realm używa realmu żądającego. Uwierzytelnione konta z atrybutem iplanet-am-session-destroy-sessions mogą podać identyfikator lub uchwyt sesji, aby wylogować użytkowników w dowolnym realmie.

OpenAM przed wersją 16.1.3 zawiera podatność na obejście autoryzacji w operacji zapytania w REST endpoint sesji, która pozwala administratorom realm na listowanie sesji wszystkich realmów. Atakujący z uprawnieniami delegowanego RealmAdmin mogą podać _queryFilter wskazujący inny realm, aby ujawnić nazwy użytkowników, uniwersalne ID i uchwyty sesji poza granicami dzierżawców.

OpenAM przed wersją 16.1.3 stosuje wymuszanie PKCE dla OAuth2 Provider tylko do żądań autoryzacji, których response_type jest dokładnie 'code'. Kody wydane przez hybrydowe przepływy OpenID Connect (code token, code id_token, code token id_token) nie mają powiązanego challenge. Atakujący, który przechwyci taki kod, może go wymienić na tokeny publicznego klienta z dowolnym niepustym code_verifier.

OpenAM przed wersją 16.1.3 zawiera podatność na otwarte przekierowanie, która pozwala nieuwierzytelnionym atakującym przekierowywać użytkowników poprzez podanie niezweryfikowanego id_token_hint do endpointu /oauth2/connect/endSession. Atakujący mogą wskazać dowolnego klienta realm w sfałszowanym hincie, aby przekierować ofiary do dowolnego zarejestrowanego URI po wylogowaniu, co umożliwia phishing wykorzystujący zaufanie do hosta OpenAM.

OpenAM w wersji przed 16.1.3 zawiera podatność na wstrzyknięcie treści wiadomości e-mail, która pozwala nieuwierzytelnionym atakującym kontrolować treść powiadomień e-mail poprzez akcje forgotPassword i register na /json/{realm}/users. Atakujący mogą podać pola subject i message, aby wysyłać wiadomości phishingowe z skonfigurowanego adresu From organizacji lub wykorzystać register jako przekaźnik do dowolnych odbiorców.

OpenAM w wersji przed 16.1.3 zawiera ukrytą wadę cross-site scripting, która umieszcza komunikat SAML, stan przekaźnika i docelowy URL bez kodowania na stronie automatycznego przesyłania pliku cookie load-balancera. Jeśli strona jest osiągalna przy włączonym cookieHashRedirectEnabled, spreparowane żądania mogą wykonać skrypt w origin OpenAM, choć niezwiązany błąd HTTP 500 uniemożliwia wykorzystanie w wydanych wersjach.

OpenAM przed wersją 16.1.3 zawiera podatność na nieuwierzytelnioną instancjację dowolnych klas w starszym interfejsie JAX-RPC SOAP. Zdalny atakujący może wysyłać żądania SOAP do /jaxrpc/* z niezweryfikowanym identyfikatorem sesji i wybraną nazwą klasy, co może doprowadzić do awarii serwera, badania classpath lub potencjalnie wykonania kodu.

OpenAM w wersji przed 16.1.3 zawiera podatność na odbity cross-site scripting, która pozwala nieuwierzytelnionym atakującym wstrzyknąć skrypt poprzez dostarczenie spreparowanych parametrów renderowanych bez kodowania na stronie błędu autoryzacji OAuth2. Atakujący mogą zwabić ofiary do spreparowanego linku /oauth2/authorize z powtórzonymi parametrami, aby uruchomić JavaScript w origin OpenAM, działając w istniejących sesjach lub przekierowując do stron phishingowych.

OpenAM od wersji 13.0.0 do 16.1.2 ma podatność na odbity XSS w endpointzie OAuth2 authorize z parametrem display=wap. Strona zgody odzwierciedla wartości pochodzące z żądania bez kodowania HTML, co pozwala atakującemu na wykonanie JavaScriptu w kontekście OpenAM, kradzież sesji lub ciasteczek, ujawnienie tokenów CSRF i działania z uprawnieniami ofiary. Wymagany jest co najmniej jeden zarejestrowany klient OAuth2, ale atakujący nie musi go kontrolować.

W OpenAM domyślna konfiguracja inicjalizuje ciasteczko SSO iPlanetDirectoryPro z wyłączonym HttpOnly i bez ochronnego domyślnego SameSite, a przepływy zgody OAuth i OpenID Connect używają tego ciasteczka przez CsrfProtection jako tokenu CSRF. W połączeniu z XSS w tej samej domenie i kliknięciem przez użytkownika linku kontrolowanego przez atakującego ciasteczko może zostać odczytane i użyte do kradzieży sesji SSO oraz realizacji zgód zainicjowanych przez atakującego. Problem naprawiono w wersji 16.1.1.

W OpenAM ścieżka uwierzytelniania klienta private_key_jwt używa ClientJwksResolverCache bez niezawodnego powiązania buforowanego resolvera jwks_uri i zweryfikowanego asercji z oczekiwanym clientID w ClientCredentialsReader. Atakujący kontrolujący dowolnego zarejestrowanego klienta z opublikowanymi kluczami, w tym uzyskanego przez otwartą rejestrację dynamiczną, może uwierzytelnić się jako inny klient, którego klucze są udostępnione przez jwks_uri, i wystawiać tokeny w jego imieniu w różnych realmach w tym samym procesie OpenAM. Problem naprawiono w wersji 16.1.1.

W OpenAM GroovySandboxValueFilter pozwala uwierzytelnionemu autorowi skryptów po stronie serwera na ucieczkę z sandboxa pomimo domyślnych list dozwolonych i zabronionych klas. Użytkownik taki jak RealmAdmin podrealm, który może tworzyć lub edytować skrypty w kontekście wykonywanym, może wywoływać polecenia systemu operacyjnego jako konto serwera aplikacji OpenAM, przekraczając granicę administracji realmem i kompromitując JVM oraz wszystkie obsługiwane realmy. Problem naprawiono w wersji 16.1.1.

W OpenAM moduł uwierzytelniania OAuth2 aktualizuje istniejące konto lokalne atrybutami profilu, które mogą zawierać userPassword i inetUserStatus, przepisując hasło na nazwę użytkownika i reaktywując wyłączone konta. Brak filtrowania OAuth.removeRestrictedAccountUpdateAttributes pozwala tym polom poświadczeń i statusu dotrzeć do aktualizacji konta. Przy włączonym tworzeniu kont powtarzane logowanie OAuth powoduje, że domyślny łańcuch ldapService akceptuje nazwę użytkownika jako identyfikator i hasło, co pozwala nieuwierzytelnionemu atakującemu przejąć konto lokalne bez interakcji z dostawcą tożsamości. Problem naprawiono w wersji 16.1.1.

W OpenAM OAuthTokenStore odczytuje identyfikatory tokenów dostarczone przez wywołującego ze wspólnego Core Token Store (CTS) bez przestrzeni nazw przeznaczonej tylko dla OAuth, a OAuthAdapter akceptuje wiersz, którego BLOB rzekomo zawiera token OAuth, bez powiązania zaufanego typu CTS i weryfikacji integralności. Atakujący, który może umieścić kontrolowany JSON w CTS pod znanym identyfikatorem tokenu, na przykład przez Push Registration, a następnie anonimowe wywołanie zwrotne SNS w włączonym realmie, może wygenerować tokeny bearer OAuth i tokeny ID OpenID Connect z wybranym podmiotem, klientem, realmem i zakresem. Problem naprawiono w wersji 16.1.1.

W OpenAM anonimowe wywołanie zwrotne SNS Push Notification obsługiwane przez SnsMessageResource po wygaśnięciu messageId z dyspozytora w pamięci sięga do predykatu blob CTS, traktuje klucze najwyższego poziomu blob jako nazwy klas Java dla Class.forName i deserializuje kontrolowany przez atakującego JSON przez Jackson. Użytkownik o niskich uprawnieniach, który rozpocznie Push Registration i uzyska messageId, wspólny sekret i wyzwanie, może poczekać na wygaśnięcie, zastąpić trwały blob przez anonimowe wywołania zwrotne i wywołać ładowanie i konstrukcję klas w JVM OpenAM. Problem naprawiono w wersji 16.1.1.

W OpenAM SessionRequestHandler w punkcie końcowym zarządzania sesjami nie wymusza kontroli własności ani uprawnień, gdy użytkownik o niskich uprawnieniach odpytuje informacje o sesji w środowiskach z stanowym przechowywaniem sesji. Wnioskujący znający identyfikator tożsamości celu może pobrać aktywne poświadczenia sesji innego użytkownika, w tym konta o wyższych uprawnieniach, i użyć ich do przejęcia tej sesji. Problem naprawiono w wersji 16.1.1.

W OpenAM w wersjach przed 16.1.1 niektóre punkty końcowe federacji w niedomyślnej konfiguracji klastrowej niekonsekwentnie kodują parametry dostarczane przez użytkownika, renderowane do HTML w ścieżce przekierowania cookie-hash SAML2. Nieuwierzytelniony atakujący może nakłonić użytkownika do otwarcia spreparowanego żądania i wykonania skryptu w domenie OpenAM. Problem naprawiono w wersji 16.1.1.

W OpenAM w wersjach przed 16.1.1 punkt końcowy autoryzacji OAuth 2.0 i OpenID Connect nie koduje wystarczająco parametrów dostarczanych przez użytkownika, zanim szablony FormPostResponse.ftl i checkSession.ftl wyrenderują je do HTML w trybie odpowiedzi form_post. Nieuwierzytelniony atakujący może nakłonić użytkownika do otwarcia spreparowanego żądania autoryzacji i wykonania skryptu w domenie OpenAM. Problem naprawiono w wersji 16.1.1.

OpenAM przed wersją 16.1.1 ma podatność w operacji addSessionListener w /sessionservice, która pozwala uwierzytelnionemu użytkownikowi na zarejestrowanie dowolnego adresu URL powiadomień bez wymaganego tokena administracyjnego lub aplikacji klienckiej. Serwer OpenAM może wysyłać żądania wychodzące do kontrolowanego przez atakującego miejsca, potencjalnie ujawniając dane powiadomień sesyjnych.

W OpenAM w wersjach przed 16.1.1 metoda IdentityResourceV1.queryCollection() przekazuje parametr _queryId z /json/{realm}/users do CrestQuery z wyłączonym escapeQueryId, omijając ochronę dodaną dla CVE-2021-29156. Nieescapowana wartość trafia do DJLDAPv3Repo.getFilter(), gdzie jest łączona z filtrem LDAP, co pozwala uwierzytelnionemu atakującemu wstrzykiwać metaznaki LDAP w celu enumeracji użytkowników i ślepej injekcji LDAP. Problem naprawiono w wersji 16.1.1.

W OpenAM w wersjach przed 16.0.0, jeśli parametr "claims_parameter_supported" jest aktywny, skrypt "oidc-claims-extension.groovy" pozwala wstrzyknąć dowolną wartość do claimu w id_token lub user_info. W żądaniu autoryzacji można wstrzyknąć parametr claims zawierający JSON, który pozwala atakującemu dostosować zwracane claimy. Wersja 16.0.0 naprawia problem.

OpenAM (OpenAM Consortium Edition) w wersjach od 14.0.0 do 14.0.1 zawiera podatność, która może powodować nieprawidłowe działanie jako SAML IdP z powodu zmodyfikowanego żądania. Problem dotyczy wersji 14.0.0 do 14.0.1.