Amazon Cognito Misconfiguraitons

Amazon Cognito is a powerful service for managing user authentication and authorization in web and mobile applications. However, misconfigurations in Cognito can open the door to serious security risks, such as account takeovers, privilege escalations, and unauthorized access to AWS resources. In this blog post, we’ll explore common Cognito misconfigurations, provide a detailed table of test cases to identify vulnerabilities, and share practical tips to secure your Cognito setup. Whether you’re a developer, security professional, or DevOps engineer, this guide will help you strengthen your AWS environment.

Why Amazon Cognito Security Matters

Amazon Cognito simplifies user management with its user pools (for sign-up and sign-in) and identity pools (for AWS resource access). However, its flexibility can lead to misconfigurations that attackers exploit. Recent research, including case studies like the Flickr account takeover, highlights how seemingly minor oversights—such as allowing unverified email updates or exposing sensitive IDs—can lead to catastrophic breaches. By proactively testing for these issues, you can protect your application and users from such risks.

Common UserPools attacks

• Detect Cognito UserPools usage: Extract UserPoolID or ClientId from the JS/HTML or Signup/Login

• Zero Click Account Takeover via Updating Email Before Verification: Updating email attributes to already registere email addresses and before verification try to login with the new email address Leads to ATO Reference: Flickr Account Takeover Advisory aws cognito-idp admin-update-user-attributes --user-pool-id <your-user-pool-id> --username <username> --user-attributes Name="email",Value="[e-mail]"

  
• Privilege Escalation via Updating User Attributes: Use AWS CLI to update custom attributes and check if it results in elevated privileges aws cognito-idp admin-update-user-attributes --user-pool-id <your-user-pool-id> --username <username> --user-attributes Name="custom:role",Value="admin" Reference: Amazon Cognito Misconfiguration Reference: Exploit Two of the Most Common Vulnerabilities in Amazon Cognito with CloudGoat

• Authentication Bypass through Self Signup API: Verify if the Signup API is enabled and attempt a direct sign-up using AWS - Self Registration aws cognito-idp sign-up --client-id <your-client-id> --username <test-user> --password <test-password> - Confirm the email address aws cognito-idp confirm-sign-up — client-id — username — confirmation-code — region Reference: Amazon Cognito Misconfiguration Refrences: https://infosecwriteups.com/attacking-aws-common-cognito-misconfigurations-a898bf092218

  

  When creating a new user pool, self-registration may be enabled by default, allowing users to sign up for an account on their own.
• Unverified Email/Phone Attributes:

• If application doesn't require email verification this may lead to duplicate registerationa, Account Overwrite and ATO attacks

  
• If an email address is configured as an alias and a new user is created with a duplicate email, the alias can be transferred to the newer user, un-verifying the former user's email https://repost.aws/knowledge-center/cognito-email-verified-attribute

• Insecure Callback URLs: Insecure callback URL configurations are a common misconfiguration in OAuth 2.0 and OIDC flows used by Cognito. This includes using HTTP instead of HTTPS (except for http://localhost for testing), configuring overly broad wildcard URLs (e.g., * or *.example.com), or failing to strictly validate the redirect URI in authentication requests https://community.auth0.com/t/security-risks-of-using-localhost-for-callback-url/118781/1 https://repost.aws/questions/QURn-XLoSyQoGDbfqr6H_BAw/adding-localhost-to-hosted-ui-callback-urls-for-testing-security-risks
• MFA Enforcement Bypass Scenarios:

• Attempt to authenticate without providing MFA after password entry.

• Test if MFA can be disabled by a standard user (User unintentionally has the Wright permission).

• Password Reset and Account Recovery: Test for race conditions or token replay vulnerabilities in the reset process

• Misconfigured Attributes read and write permissions: In some websites users can't update their info like email in the UI so attacker can change this info via the API if the attribute write permission is enabled

• Token Revocation Issues: Cognioto Succesfully revoked the code but the application's api didn't

• Token Intigriti Issues:

• The session is indeed checked to see if it lines up with the correct username.

• The IdToken is checked to see if it’s valid (i.e., not expired).

• However, there wasn’t any code linking that IdToken to the specific session or user. That’s because the dev who wrote the custom challenge logic didn’t do that last piece of validation!

https://boom-stinger-c76.notion.site/AWS-Cognito-Chaos-The-Major-Flaw-That-Let-Attackers-Takeover-User-Accounts-17953b6a0d6e80bf8a75f6d03654eecf

Test Third-Party Identity Providers (IdP) and Federation

• Test for Arbitrary Identity Token Acceptance: If Cognito accepts ID tokens from any IdP without validation, it may allow attackers to impersonate users

1. Forge a valid-looking JWT token (for OIDC) with your own IdP (e.g., a local Keycloak or Auth0 instance).

2. Set the iss (issuer) to match the target’s expected IdP.

3. Replace the aud with the expected Cognito client ID.

curl -X POST https://<domain>.auth.<region>.amazoncognito.com/oauth2/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code&code=...&redirect_uri=..." \
  -H "Authorization: Bearer <your_forged_token>"

• IDP Role Injection via Claims Mapping: If role/permission claims from IdP are mapped to AWS roles or Cognito groups without validation, an attacker could elevate privileges

• Forge or modify an identity assertion (SAML or JWT) that includes elevated claims like:

jsonCopyEdit"custom:role": "admin"

• Use a test IdP you control to submit these claims.

• Watch if Cognito accepts the claim and assigns privileges (e.g., in app or AWS permissions).

• Scope/Claims Overreach: If the application doesn’t restrict OIDC/SAML scopes/claims, attackers might access unintended user data.

• Try requesting excessive scopes:

httpCopyEditscope=openid profile email aws.cognito.signin.user.admin

• Look at returned claims in id_token or access_token

Common IdentityPools attacks

• Dorks

IdentityPoolId 
Aws_cognito_identity_pool_id 
Identity Pool Id 
AWSCognitoIdentityService 
clientId 
client_id 
aws_user_pools_web_client_id

• Leakage of Secrets like Identity Pool ID in JS Files: Inspect client-side code or API responses for exposed Identity Pool IDs, then attempt to generate temporary AWS credentials then use tool to enumerate permissions associated with these credentials like Enumerate-iam. aws cognito-identity get-id --identity-pool-id '[IdentityPoolId]' --logins "cognito-idp.{region}.amazonaws.com/{UserPoolId}={idToken}" aws cognito-identity get-credentials-for-identity --identity-id '{IdentityId}' --logins "cognito-idp.{region}.amazonaws.com/{UserPoolId}={idToken}" Reference: AWS Cognito Pitfalls: Default Settings Attackers Love Reference: Exploit Two of the Most Common Vulnerabilities in Amazon Cognito with CloudGoat Reference: AWS Cognito Pitfalls: Default Settings Attackers Love Reference: Hacking AWS Cognito Misconfigurations

  

  js file leak the AWS credentials ( User Pool ID, User Pool ID, Region)

How to Use These Test Cases

To execute these test cases, you’ll need tools like the AWS CLI, Burp Suite for intercepting requests, or enumeration tools like enumerate-iam and ScoutSuite. Here’s a quick guide to get started:

1. Set Up AWS CLI: Configure AWS CLI with temporary credentials or a test account to interact with Cognito APIs safely.

2. Inspect Client-Side Code: Use browser developer tools or Burp Suite to check for exposed IDs like App Client ID or Identity Pool ID in JavaScript files or API responses.

3. Test Attribute Updates: Use AWS CLI commands like admin-update-user-attributes to attempt modifying email or custom attributes, checking for verification bypasses or privilege escalations.

4. Verify Permissions: Review your Cognito user pool settings in the AWS Management Console, ensuring that self-signup is disabled (if not needed) and attribute permissions are restricted.

For example, to test for the "Zero Click Account Takeover" vulnerability (inspired by the Flickr case), you can try updating a user’s email attribute with a case-sensitive variation (e.g., [e-mail] vs. [e-mail]) using the following AWS CLI command:

aws cognito-idp admin-update-user-attributes --user-pool-id <your-user-pool-id> --username <username> --user-attributes Name="email",Value="[e-mail]"

If the update succeeds without verification, your setup may be vulnerable.

Refrences

For further reading, check out these excellent resources:

• Hacking AWS Cognito Misconfigurations
• https://medium.com/@mukundbhuva/account-takeover-due-to-cognito-misconfiguration-earns-me-xxxx-3a7b8bb9a619
• https://www.youtube.com/watch?v=rJEealvGdJo
• Flickr Account Takeover Advisory
• Exploit Two of the Most Common Vulnerabilities in Amazon Cognito with CloudGoat
• AWS Cognito Pitfalls: Default Settings Attackers Love

Stay secure, and happy testing!