Podatności Cloud Foundry UAA

Wykryto problem w Cloud Foundry, który dotyczy wersji v252 i wcześniejszych oraz UAA w wersjach od v2.0.0 do v2.7.4.12 i od v3.0.0 do v3.11.0. UAA jest podatny na atak typu session fixation, gdy jest skonfigurowany do uwierzytelniania zewnętrznych dostawców tożsamości opartych na SAML lub OpenID Connect.

W systemie Cloud Foundry w wersjach od v247 do v252 oraz w UAA w wersjach od v3.9.0 do v3.11.0 zidentyfikowano problem, który może prowadzić do ataku typu denial of service na klientów OAuth UAA.

Cloud Foundry oraz UAA w wersjach przed 248 oraz 2.x przed 2.7.4.12, 3.x przed 3.6.5 i 3.7.x do 3.9.x przed 3.9.3 mają lukę, która pozwala atakującym na uzyskanie uprawnień poprzez dostęp do logów UAA i uruchomienie specjalnie przygotowanej aplikacji współpracującej z dostawcą SAML.

Cloud Foundry UAA w wersjach od v76.12.0 do v78.12.0 zawiera lukę, która nieumyślnie ujawnia prywatne klucze EC przez publiczny endpoint /token_keys. Luka dotyczy tylko wdrożeń używających kluczy EC do podpisywania tokenów JWT.

Podatność w Cloud Foundry UAA w punkcie końcowym tokenów OAuth umożliwia uwierzytelnionemu atakującemu, posiadającemu ważny token dostępu użytkownika, uzyskanie tokenu client_credentials z pełnymi uprawnieniami klienta OAuth, który wydał ten token. Dzieje się to poprzez przedstawienie tokenu użytkownika jako poświadczenia Bearer w żądaniu client_credentials zamiast sekretu klienta, ponieważ UAA nie weryfikuje, czy poświadczenie Bearer jest faktycznie poświadczeniem klienta.

Podatność w Cloud Foundry UAA (wersje 4.5.0 do 79.6.0) wynika z niewystarczającej weryfikacji autentyczności danych w zewnętrznym wywołaniu zwrotnym OIDC. Umożliwia uwierzytelnionemu użytkownikowi UAA ominięcie wymiany kodu autoryzacyjnego OAuth i ustanowienie sesji przeglądarki OIDC poprzez podstawienie własnego tokena JWT jako parametru id_token.

Niewłaściwe obsługiwanie wielkości liter (CWE-178) w kontroli autoryzacji strefy tożsamości w Identity Zone Endpoint w Cloud Foundry UAA pozwala zdalnemu uwierzytelnionemu atakującemu posiadającemu tylko uprawnienie zones.write na ominięcie zamierzonego ograniczenia, że to uprawnienie nie daje dostępu do uprzywilejowanej strefy tożsamości uaa (system), poprzez odwoływanie się do identyfikatora strefy w formie innej niż małe litery (np. UAA) w ścieżce i treści żądania. Warstwa autoryzacji wykonuje porównanie uwzględniające wielkość liter z identyfikatorem strefy systemowej, podczas gdy warstwa trwałości MySQL rozwiązuje identyfikatory bez uwzględniania wielkości liter przy domyślnej kolacji, więc żądanie jest autoryzowane nieprawidłowo, a następnie rozwiązywane względem rzeczywistego rekordu strefy systemowej. Pozwala to atakującemu nadpisać klucz podpisywania JWT strefy systemowej materiałem kontrolowanym przez atakującego, sfałszować JWT z zakresami klienta admin i administratora oraz w pełni skompromitować UAA i każde wdrożenie Cloud Foundry, które mu ufa. Problem dotyczy tylko wdrożeń UAA korzystających z MySQL z domyślną kolacją; backendy PostgreSQL i HSQLDB nie są dotknięte.