Penetration Testing AWS Cognito applications: From Unauth to Admin in 0

UserName

IMAGINE THIS: Starting as an unauthenticated user and exploiting AWS Cognito vulnerabilities to gain full admin access in an online banking mobile application without even using the app. Suddenly, you’re approving unauthorized transactions or viewing sensitive data—all without valid credentials.

We’ve used these exact techniques to bypass authentication in real-world mobile apps, uncovering how minor misconfigurations can lead to catastrophic breaches. We’ll show you how attackers exploit these flaws and how you can secure your applications against them.

AWS Cognito is widely used in web and mobile applications like online banking, healthcare, SaaS platforms, and e-commerce to manage user authentication and authorization.

However, misconfigurations can expose serious security risks. In this guide, we demonstrate how to exploit AWS Cognito vulnerabilities to completely bypass authentication mechanisms and directly attack the service, achieving admin or privileged access within the application.

Understanding AWS Cognito

AWS Cognito is a fully managed authentication and authorization service for mobile and web applications. It enables developers to implement secure user sign-up, sign-in, and access control with minimal effort.

Key Components

User Pools: A user directory for managing user authentication and accounts. Includes features like sign-up, sign-in, password recovery, and multi-factor authentication.
Identity Pools: Provides temporary AWS credentials to authenticated users from a User Pool or third-party identity provider (e.g., Google or Facebook).
Client ID: A unique identifier for applications using the Cognito User Pool. Required for all interactions with the Cognito AP

Step-by-Step Attacks

Prerequisite: The Client ID

To execute the following attacks, you will need the Client ID of the AWS Cognito User Pool. This unique identifier is used to interact with the Cognito APIs. At the end of this guide, we’ll explain how to obtain the Client ID from web and mobile applications.

1. User Enumeration Attacks

1.1 Targeting the Forgot Password Functionality

				
					aws cognito-idp forgot-password \
  --client-id [ClientID] \
  --username [Email]

Real-World Scenario (Healthcare Application):
Attackers could enumerate valid patient accounts, which could then be targeted with phishing emails claiming to require account updates for insurance purposes, potentially compromising sensitive patient data.

Prevention:
Use generic error messages and implement rate-limiting to prevent user enumeration.

1.2 Targeting the Sign-Up Process

				
					aws cognito-idp sign-up \
  --client-id [ClientID] \
  --username [Email] \
  --password CyphireRocks!

Real-World Scenario (SaaS Platform):
In a corporate SaaS platform, attackers could confirm the existence of executive email addresses (e.g., CEO, CFO). This information could facilitate business email compromise (BEC) attacks or spear-phishing attempts.

Prevention:
Implement CAPTCHA and rate-limiting to block automated sign-up attempts.

2. Registering a User via AWS CLI

				
					aws cognito-idp sign-up \
  --client-id [ClientID] \
  --username [Username] \
  --password [Password] \
  --user-attributes '[{"Name":"given_name","Value":"Cyphire"},{"Name":"family_name","Value":"Penetration Testing"}]'

Real-World Scenario (E-commerce Application):
Attackers could create fake accounts to exploit first-time user discounts or promotional offers. In some cases, these fake accounts could be used to commit fraud, such as purchasing items with stolen credit cards.

Prevention:
Validate all user inputs and require email verification to prevent abuse.

3. Confirming User Registration

				
					aws cognito-idp confirm-sign-up \
  --client-id [ClientID] \
  --username [Username] \
  --confirmation-code [ConfirmationCode]

Real-World Scenario (Online Banking Application):
An attacker could confirm unauthorized accounts, bypassing weak email verification mechanisms, and then use these accounts to apply for fraudulent loans or conduct unauthorized transfers.

Prevention:
Use strong confirmation codes and enforce server-side validation.

4. Extracting User Attributes

				
					aws cognito-idp get-user \
  --access-token [AccessToken]

Real-World Scenario (Social Media Application):
Attackers could extract sensitive profile details to perform social engineering attacks, such as impersonation or spreading misinformation.

Prevention:
Restrict access to sensitive attributes and monitor API requests for unusual activity.

5. Modifying User Attributes

				
					aws cognito-idp update-user-attributes \
  --access-token [AccessToken] \
  --user-attributes '[{"Name":"custom:access","Value":"admin"}]'

Real-World Scenario (Collaboration Tool):
An attacker could elevate privileges to gain administrative access, enabling them to delete or steal sensitive project files in a workplace collaboration tool, potentially halting business operations.

BONUS POINTS!! CHAINED ATTACK IMPACT!: When this attack is combined with the self-registration attack, an attacker could escalate from an unauthenticated user to an admin role within the application. This means starting without any credentials and ending with full administrative control over the system. This chained attack demonstrates how seemingly minor flaws can result in complete compromise of an application—a striking and impactful finding for penetration testers.

Prevention:
Restrict sensitive attribute modifications to authorized users or administrators.

6. Exploiting Identity Pools for AWS Credentials

6.1 Obtain Identity ID

				
					aws cognito-identity get-id \
  --region [region] \
  --identity-pool-id '[IdentityPool_Id]' \
  --logins "cognito-idp.{region}.amazonaws.com/{UserPoolId}={idToken}"

6.2 Get AWS Credentials

				
					aws cognito-identity get-credentials-for-identity \
  --region [region] \
  --identity-id '[Id-found]' \
  --logins "cognito-idp.{region}.amazonaws.com/{UserPoolId}={idToken}"

Real-World Scenario (Cloud-Based Document Sharing Application):
Stolen credentials could allow attackers to download sensitive corporate documents or modify AWS Lambda functions to plant malware, causing data breaches and operational disruptions.

Prevention:
Use scoped permissions and monitor credentials for unusual usage patterns.

Obtaining the Client ID in Web and Mobile Applications

The Client ID is essential for interacting with AWS Cognito APIs and is often exposed in applications. Here are several ways to locate it:

1. Inspecting Network Requests

Open the application in your browser and perform an action like signing in or signing up.
Use the browser developer tools (usually accessible via F12) and navigate to the Network tab.
Look for requests to Cognito endpoints, such as https://cognito-idp.[region].amazonaws.com/, and inspect the request headers or body for the ClientId parameter.

2. Examining Local Storage

Many web applications store configuration data, including the Client ID, in the browser’s Local Storage, Session Storage, or cookies.

Steps to Find the Client ID in Local Storage:

Open the developer tools in your browser and navigate to the Application tab.
Check Local Storage or Session Storage for entries related to authentication, such as Auth or Cognito.
Look for JSON objects containing ClientId or similar keys.

3. Analyzing JSON Web Tokens (JWTs)

Some applications use JWTs for user authentication and authorization. These tokens often contain AWS Cognito information in their payload.

Steps to Inspect a JWT:

Obtain the JWT from:

Open the developer tools in your browser and navigate to the Application tab.
Check Local Storage or Session Storage for entries related to authentication, such as Auth or Cognito.
Look for JSON objects containing ClientId or similar keys.

Look for fields like iss (Issuer) or aud (Audience), which often contain:

Cognito User Pool ID.
Client ID.
AWS Region.

Example JWT Payload:

				
					{
  "sub": "12345678-1234-1234-1234-123456789012",
  "aud": "1a2b3c4d5e6f7g8h9i0j",
  "iss": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_ABCDEFG",
  "token_use": "id",
  "email": "info@cyphire.io"
}

In this example, the aud field contains the Client ID, and the iss field provides the User Pool ID and region.

4. Analyzing JavaScript Files

Some applications hardcode the Client ID in their front-end code.

Steps to Inspect JavaScript Files:

Use the browser developer tools and go to the Sources tab.
Search through the JavaScript files for terms like ClientId, cognito, or config.
The Client ID is often part of a configuration object used to initialize the AWS Cognito SDK.

5. Reviewing API Documentation

Public API documentation or SDKs provided by the application may include Cognito-related configurations, including the Client ID. Search through:

Online API documentation.
Developer guides or help sections.

6. Decompiling Mobile Applications

Mobile app binaries often contain hardcoded configurations for AWS Cognito.

Steps for Android (APK) Files:

Use APKTool or JD-GUI to decompile the APK file.
Search files like strings.xml, config.js, or environment.ts for Cognito configurations, including the Client ID.

Steps for iOS (IPA) Files:

Extract the IPA file and search for configuration files within the Payload directory.
Look for terms like ClientId or Cognito.

7. Examining Configuration Endpoints

Applications sometimes host configuration files that are accessible via public URLs.

Look for endpoints like /config.json or /settings.js that might contain Cognito-related settings.
These files may reveal the Client ID along with other sensitive information.

8. Using Burp Suite or Proxy Tools

Intercept application traffic using Burp Suite, OWASP ZAP, or similar tools:

Proxy requests from the web or mobile application.
Inspect HTTP headers and payloads for references to the Client ID.

Pro Tip: Use the Burp Suite Extension “AWS Cognito”
The AWS Cognito extension, available in PortSwigger’s BApp Store, automates the process of identifying AWS Cognito configurations. This tool can:

Detect Cognito User Pool IDs and Identity Pool IDs in application traffic.
Extract regions and endpoints related to AWS Cognito. This extension significantly speeds up reconnaissance efforts and ensures no Cognito-related details are overlooked.

9. Monitoring Logs

Some applications log sensitive configuration data, including the Client ID, during debugging or error handling.

Check publicly accessible logs or error pages for Cognito-related values.

Conclusion

AWS Cognito simplifies authentication for web and mobile applications, making it easier for developers to integrate secure sign-up, sign-in, and access control. However, as demonstrated in this guide, even minor misconfigurations can lead to severe vulnerabilities, such as bypassing authentication mechanisms or escalating privileges to gain full administrative access.

Remember this: All the security measures in your web or mobile application—firewalls, encryption, and secure coding practices—can be rendered useless if AWS Cognito is not correctly configured and hardened. Attackers often target weak points in cloud services, and AWS Cognito is no exception. Without proper attention to its security, the very system meant to protect your users can become an attacker’s greatest advantage.

To safeguard your applications:

Regularly audit your AWS Cognito configurations for misconfigurations.
Implement best practices like least privilege, secure API usage, and robust error handling.
Stay updated on AWS security guidelines and patches.

At Cyphire, we specialize in penetration testing for web and mobile applications, helping businesses identify vulnerabilities before attackers can exploit them. Whether it’s uncovering misconfigurations or conducting a full security assessment of your application, our team of experts is here to help