Hunting For Amazon Cognito Security Misconfigurations

Hunting For Amazon Cognito Security Misconfigurations

Speakers: Yassine Aboukir, Application Security Consultant, HackerOne

Conference: HITB Phuket

YouTube: https://www.youtube.com/watch?v=U9EAov5tvl0

Overview

In this insightful talk from HITB Phuket, Yassine Aboukir, an Application Security Consultant at HackerOne, delves into the prevalent security misconfigurations affecting Amazon Cognito implementations. As a cloud-based authentication and authorization solution, AWS Cognito has seen widespread adoption due to its comprehensive features, simplifying the complex task of managing user identities for applications. However, its power and flexibility come with a significant caveat: the shared responsibility model. This model places the onus on customers to correctly configure their Cognito instances, a task that, as Aboukir demonstrates, is often fraught with errors due to the service's inherent complexity and sometimes ambiguous documentation.

Aboukir, drawing from his extensive experience as a penetration tester and bug bounty hunter, highlights that many security issues in Cognito arise not from inherent vulnerabilities in the AWS service itself, but from mistakes made during its implementation and configuration by developers. The presentation systematically breaks down several common misconfigurations, illustrating how seemingly minor oversights can lead to critical security flaws, including unauthorized access to AWS resources, authentication bypasses, privilege escalation, and even account takeovers.

This talk is crucial for anyone involved in developing, securing, or auditing applications that leverage AWS Cognito. It provides practical, actionable insights for both attackers looking to identify weaknesses and defenders aiming to harden their cloud authentication infrastructure. By dissecting real-world examples and providing concrete steps for exploitation and remediation, Aboukir demystifies the complexities of Cognito security, empowering attendees to navigate its configuration landscape more effectively.

Background

▶ Watch: Introduction to AWS Cognito and shared responsibility (0:00)

AWS Cognito is a fully managed cloud service designed to handle user authentication and authorization for web and mobile applications. It offers a robust solution for managing user directories, sign-up, sign-in, and access control, thereby abstracting away much of the complexity traditionally associated with building secure identity systems. This is particularly valuable for developers who might otherwise struggle with the intricate details of password management, token handling, and multi-factor authentication.

The service is primarily composed of two core components:

1. User Pools: These are responsible for the sign-up and sign-in processes, essentially acting as a user directory. A User Pool handles user registration, authentication, and manages user attributes. Upon successful authentication, a User Pool issues three JSON Web Tokens (JWTs): an ID Token (containing user identity information), an Access Token (used to authorize API operations), and a Refresh Token (used to obtain new ID and Access Tokens).
2. Identity Pools: These are responsible for authorization. An Identity Pool allows users (both authenticated via a User Pool or federated identity provider, and unauthenticated "guest" users) to obtain temporary AWS credentials. These credentials, which include an access key, secret key, and session token, grant users permission to access other AWS services like Amazon S3, DynamoDB, Lambda, and API Gateway.

The typical flow involves a user authenticating against a User Pool, receiving JWTs, and then using the ID Token to exchange it for temporary AWS credentials from an Identity Pool. These temporary credentials are then used by the client application to interact with various AWS services. Identifying Cognito usage in an application is often straightforward; observing API calls to endpoints like cognito-idp..amazonaws.com (for User Pool operations) and cognito-identity..amazonaws.com (for Identity Pool operations) in a web proxy like Burp Suite is a clear indicator.

The existence of these misconfigurations stems directly from the shared responsibility model. While AWS is responsible for the security of the cloud (e.g., the underlying infrastructure, physical security, global network), the customer is responsible for security in the cloud. This includes configuring Cognito user pools, identity pools, IAM policies, and application-level security. The talk emphasizes that the issues discussed are not vulnerabilities within AWS Cognito itself, but rather common mistakes made by developers and administrators during its setup and integration, making it "really easy to mess up" the configuration.

Key Findings

▶ Watch: Over-permissive AWS credentials for unauthenticated users (7:45)

Yassine Aboukir's presentation uncovered several critical security misconfigurations prevalent in AWS Cognito implementations, each with distinct implications for application security:

• Unauthorized Access to AWS Services due to Liberal AWS Credentials: This misconfiguration occurs when the temporary AWS credentials granted by an Identity Pool are overly permissive, allowing authenticated or even unauthenticated users to access AWS services (like S3 buckets, DynamoDB tables, or Lambda functions) that they should not have access to. This often arises from poorly scoped IAM policies attached to Identity Pool roles.
• Authentication Bypass due to Enabled Sign-up API Action: Even if an application's user interface disables self-registration, developers often leave the underlying Cognito User Pool's sign-up API action enabled by default. Attackers can directly invoke this API to create new user accounts, bypassing application-level controls and potentially gaining access to internal systems.
• Privilege Escalation through Writable User Attributes: Cognito allows for custom user attributes (e.g., user_role, is_admin). If these custom attributes are not explicitly set to "readable only" and remain "writable by default," an authenticated user can modify their own attributes to elevate their privileges (e.g., changing their role from user to admin).
• Updating Email Attribute Before Verification: Applications might allow users to update their email addresses via direct Cognito API calls, even if the UI restricts this or server-side checks are in place. If the application then fails to verify the new email address's authenticity or its email_verified status, it can lead to account takeovers, especially when combined with case-sensitivity issues or domain-based access controls.
• User Account Enumeration via the Sign-up API: While AWS has mitigated user enumeration issues on the login endpoint, the sign-up API in Cognito can still be exploited to determine if a username or email address exists in a User Pool. This allows attackers to build lists of valid users, facilitating brute-force or social engineering attacks.
• Un-invalidated Access Tokens: Although not covered in detail in the slides, Aboukir briefly mentioned that access tokens are sometimes not properly invalidated upon logout or password change, leading to broken authentication issues where an old token might still grant access.

These findings collectively underscore the importance of meticulous configuration and a deep understanding of Cognito's security implications, moving beyond the assumption that a managed service automatically ensures security.

Technical Deep Dive

▶ Watch: Privilege escalation through writable user attributes (19:20)

The core of Yassine Aboukir's presentation lies in the detailed technical walkthrough of each misconfiguration, providing specific commands and methodologies for identification and exploitation.

Unauthorized Access to AWS Services due to Liberal AWS Credentials

This misconfiguration is a direct result of overly permissive IAM policies attached to the roles assumed by users via an Identity Pool. The goal for an attacker is to obtain temporary AWS credentials and then enumerate their associated permissions.

Information Gathering:

To obtain temporary AWS credentials, an attacker first needs three pieces of information, typically hardcoded in the application's source code (JavaScript files, .env files), found in API requests, or discovered through directory brute-forcing:

• Identity Pool ID (e.g., us-east-1:xxxx-xxxx-xxxx-xxxx)
• Client ID (for the User Pool, if applicable)
• AWS Region (e.g., us-east-1)

Tools and techniques for discovery:

• Source Code Analysis: Inspecting loaded JavaScript files for hardcoded IDs.
• Web Proxy History: Using Burp Suite to search for keywords like identityPoolId, clientId, userPoolId in network requests.
• Directory Brute-forcing: Tools like favtool can uncover configuration files (.env, .json) containing these IDs.
• Automated Scanners: Nuclei, with its community templates, can identify these IDs using regular expressions.

Exploitation Steps (Unauthenticated Guest Access):

Assuming Unauthenticated Access is enabled in the Identity Pool:

1. Get Identity ID: Use the aws cognito-identity get-id command, providing the Identity Pool ID and Region.

This returns an IdentityId (e.g., us-east-1:yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy).

1. Get Temporary AWS Credentials: Use the obtained IdentityId with aws cognito-identity get-credentials-for-identity.

This returns AccessKeyId, SecretKey, and SessionToken.

Exploitation Steps (Authenticated Access):

If a user is authenticated, the application often automatically fetches and uses these temporary AWS credentials. An attacker can simply intercept these credentials from the application's network traffic (e.g., via Burp Suite) after logging in.

Permission Enumeration:

Once temporary AWS credentials are acquired, tools are used to enumerate the permissions associated with them:

• enumerate_em: A lightweight Python script for quickly listing permissions.

• Scout Suite: A more comprehensive cloud security auditing tool that generates detailed reports.

Common findings include permissions to list or read contents of S3 buckets, list DynamoDB tables or backups, or enumerate Lambda functions, potentially exposing sensitive data or application logic.

Authentication Bypass due to Enabled Sign-up API Action

Many applications disable self-registration through their user interface (e.g., for internal admin panels or paid subscriptions). However, developers frequently overlook disabling the underlying Cognito User Pool's sign-up functionality in the AWS console, which is enabled by default.

Information Gathering:

The primary piece of information needed is the Client ID of the Cognito User Pool, easily found in the application's source code or login request traffic. The Region is also required.

Exploitation Steps:

1. Direct Sign-up: Use the aws cognito-idp sign-up command, providing the Client ID, a desired Username/Email, and a Password.

Alternatively, a direct HTTP POST request to the Cognito endpoint can be made, ensuring proper JSON formatting and HTTP headers.

A successful response indicates that a confirmation code has been sent to the provided email/phone.

1. Confirm Sign-up: If a verification code is sent (e.g., to the attacker's controlled email), use aws cognito-idp confirm-sign-up.

This verifies the account, allowing the attacker to log in to the application, bypassing the UI's registration restrictions.

Privilege Escalation through Writable User Attributes

Cognito allows developers to define standard and custom user attributes. A critical misconfiguration arises when custom attributes (e.g., custom:user_role, custom:is_admin) are left writable by default instead of being explicitly set to "readable only."

Information Gathering:

An authenticated attacker needs their Access Token, which is obtained during a successful login to the application.

Exploitation Steps:

1. Enumerate User Attributes: Use the aws cognito-idp get-user command with the attacker's Access Token to retrieve their current attributes.

The output will list all attributes, including standard ones (e.g., email_verified) and custom ones (prefixed with custom:). The attacker looks for custom attributes that might control roles or permissions, such as custom:user_role or custom:is_admin.

1. Update User Attribute: If a potentially sensitive custom attribute is found, attempt to modify its value using aws cognito-idp update-user-attributes. The attacker might need to guess valid roles (e.g., admin, super_admin) or find them in client-side code (e.g., JavaScript files).

If the attribute is writable, the value will be updated, potentially granting the attacker elevated privileges within the application upon re-authentication or subsequent API calls. Aboukir shared a real-world example where a friend escalated privileges by finding the super_admin role in a JavaScript file and updating a custom:user_role attribute.

Updating Email Attribute Before Verification (Account Takeover)

This misconfiguration is particularly dangerous, potentially leading to full account takeovers. It leverages the ability to directly update a user's email address via the Cognito API, bypassing application-level restrictions and verification checks.

Information Gathering:

An authenticated attacker needs their Access Token.

Exploitation Steps:

1. Update Email Address: Use aws cognito-idp update-user-attributes to change the email attribute to a new, attacker-controlled email.

The problem arises if the application, after this update, does not properly check the email_verified attribute. Many applications assume that if an email is present, it is verified, or they simply do not enforce the verification status. This allows the attacker to log in with the newly set, unverified email.

Flickr Case Study:

Aboukir presented a public HackerOne report on Flickr (a Yahoo acquisition) demonstrating a complex account takeover chain:

1. Victim: [email protected]
2. Attacker Action: An attacker with their own Flickr account directly calls the Cognito API to update their email address to [email protected] (note the capital 'M').
3. Misconfigurations:

• The email attribute was left writable.
• The email attribute was case-sensitive for Cognito, treating [email protected] and [email protected] as distinct.

1. Application Logic Flaws:

• Flickr's application did not check the email_verified status.
• Flickr's application normalized the email address to lowercase ([email protected]) upon login.

1. Result: The attacker, having [email protected] associated with their account in Cognito, logs out and tries to log in with [email protected]. Due to the application's normalization, it effectively logs them in as the victim [email protected], resulting in a full account takeover.

AWS introduced a setting in June 2022, "Keep original attribute value active when an update is pending," which prevents the email value from changing until it's verified. However, older applications deployed before this feature remain vulnerable.

User Account Enumeration via the Sign-up API

While AWS has addressed user enumeration on the login endpoint (returning a generic "Incorrect username or password" for both non-existent users and wrong passwords when "prevent user existence errors" is enabled), a similar vulnerability persists on the sign-up API.

Exploitation Steps:

1. Attempt Sign-up with Target Username/Email: Using the aws cognito-idp sign-up command, an attacker tries to register with a username or email they want to enumerate.

• If the username/email exists, the API returns User already exists.
• If the username/email does not exist, the API proceeds with a new sign-up (potentially sending a verification code, which the attacker can ignore).

This distinct response allows attackers to confirm the existence of users, which can be invaluable for brute-forcing credentials or targeted social engineering attacks. Aboukir notes that this is still an open issue on AWS's GitHub.

Un-invalidated Access Tokens

Aboukir briefly mentioned that in some Cognito implementations, the Access Token might not be invalidated upon user logout or password changes. This is a classic broken authentication issue, where an attacker could continue to use a compromised token even after the legitimate user has taken actions that should revoke it. This highlights the need for applications to explicitly revoke tokens or ensure short token expiry times.

Demo / Proof of Concept

▶ Watch: User enumeration vulnerability via Cognito sign-up API (33:00)

While the talk did not feature a live, interactive demonstration, the speaker meticulously walked through the command-line steps and examples for each misconfiguration. Yassine Aboukir presented precise AWS CLI commands, showing how to execute aws cognito-identity get-id, aws cognito-identity get-credentials-for-identity, aws cognito-idp sign-up, aws cognito-idp update-user-attributes, and aws cognito-idp get-user. He also provided screenshots of tool outputs, such as the enumerate_em script listing permissions or API responses indicating "User already exists." These detailed technical explanations, coupled with real-world scenarios like the Flickr account takeover and a friend's privilege escalation, served as a comprehensive proof of concept for each vulnerability discussed.

Defensive Implications

▶ Watch: Essential recommendations for secure AWS Cognito configurations (36:00)

The detailed analysis of Cognito misconfigurations provides a clear roadmap for defenders to harden their applications. Adhering to the principle of least privilege and performing thorough security reviews are paramount.

1. Secure Configuration IDs: While Cognito IDs (Client ID, User Pool ID, Identity Pool ID, Region) are not sensitive on their own, they should not be hardcoded directly into client-side code or publicly accessible configuration files. Wherever possible, fetch them securely or obfuscate their discovery. Remove any other sensitive information from server responses.
2. Disable Unnecessary Features:

• Self-Registration (Sign-up): If your application does not require users to create their own accounts, explicitly disable the sign-up API action in the Cognito User Pool settings. This prevents attackers from directly invoking the API to create accounts.
• Unauthenticated Access: If your application does not need to grant temporary AWS credentials to unauthenticated users, disable the unauthenticated role in the Cognito Identity Pool. This prevents guest users from generating credentials and enumerating permissions.

1. Strict IAM Policy Review: Rigorously review the IAM policies attached to both authenticated and unauthenticated roles in your Identity Pools. Ensure these policies grant only the absolute minimum permissions required for the application's functionality. Avoid wildcards (*) and restrict access to specific resources and actions. Regularly audit these policies.
2. Careful User Attribute Management:

• Custom Attributes: When creating custom user attributes (e.g., user_role, is_admin), always set them to "readable only" unless there is a specific, well-secured use case for users to update them. This prevents privilege escalation via attribute modification.
• Email Verification: Never trust the email attribute value blindly. Always check the email_verified attribute and ensure it is true before granting access or making critical decisions based on the email address.
• Email Update Setting: For applications deployed after June 2022, enable the Cognito setting "Keep original attribute value active when an update is pending." This ensures that a user's email address is not updated until the new address has been successfully verified.
• Case Sensitivity: Configure email attributes to be case-insensitive where appropriate to prevent account takeover scenarios like the Flickr example.

1. Address User Enumeration: While AWS has fixed enumeration for the login API when "prevent user existence errors" is enabled, the sign-up API remains vulnerable. Implement custom logic at the application layer to mitigate sign-up enumeration, such as returning generic error messages regardless of user existence.
2. Token Invalidation: Ensure that Access Tokens are properly invalidated and revoked upon logout, password changes, or account resets. Implement short token expiry times and consider using token revocation mechanisms where appropriate to prevent the reuse of compromised tokens.

By meticulously implementing these defensive measures, organizations can significantly reduce their attack surface and protect their AWS Cognito-backed applications from common misconfigurations.

Key Takeaways

• Shared Responsibility is Key: AWS Cognito's security hinges on proper customer configuration. Many vulnerabilities arise from misconfigurations, not inherent AWS flaws.
• Least Privilege for Credentials: Overly permissive IAM policies for Identity Pool roles (both authenticated and unauthenticated) can grant broad, unintended access to AWS services like S3, DynamoDB, and Lambda. Always enforce the principle of least privilege.
• Default Settings are Dangerous: Cognito's default settings, such as enabled sign-up API actions and writable custom attributes, are common attack vectors. Developers must actively disable unnecessary features and explicitly configure attributes for security.
• Email Handling is Critical: Flawed email update mechanisms, especially those bypassing verification and ignoring the email_verified status, are a prevalent path to account takeover. Case sensitivity issues further exacerbate this risk.
• User Enumeration Persists: Despite AWS's efforts, user enumeration through the Cognito sign-up API remains a valid technique for attackers to identify existing user accounts, aiding in further attacks.
• Proactive Review and Tooling: Regular security assessments, code reviews, and the use of tools like enumerate_em or Scout Suite are essential for identifying and remediating these misconfigurations before they are exploited in the wild.

About the Speaker(s)

Yassine Aboukir is an accomplished Application Security Consultant at HackerOne, where he specializes in penetration testing, security assessments, and code reviews for various companies. He is also an active member of the HackerOne Hacker Advisory Board, representing the security research community and advocating for the integration of hacker feedback into the platform's offerings. From 2017 to 2019, Aboukir served as a Security Analyst at HackerOne, where he gained extensive experience triaging security reports for high-profile companies such as PayPal, Airbnb, and Sony. With a decade of experience in bug bounty hunting since 2013, he has established himself as one of HackerOne's top 20 hackers on the leaderboard and was awarded the prestigious MVH (Most Valuable Hacker) title during a live hacking event in Orlando. His deep practical knowledge of application security and cloud misconfigurations makes him a highly credible voice in the cybersecurity community.