In Part 1 of this post, we discuss common problems in AWS Cognito security, as seen in client environments, which would benefit from automated scanning and exploitation. In Part 2, we walk through our solution: two new modules for Pacu, our open-source AWS exploitation framework. Feel free to skip to Part 2 now if you’re already familiar with Cognito.

AWS Cognito manages user authentication and authorization for client applications, usually mobile or web.  The standard user flow is below.

The “client,” “user pool” and “identity pool” have their own associated “ID” that can be used for direct API calls. These resources work as follows:

Client

The “client” is the app (usually web or mobile) the user registers for and logs in to. It is similar to an OAuth 2.0 client app.

User Pool

The “user pool” is a user directory that manages user registration and login for the “client.” It is similar to an OpenID Connect identity provider (OIDC IdP). 

Identity Pool

The “identity pool” gives temporary AWS credentials to end users. These IAM credentials allow direct interaction with the AWS account, which provides additional attack surface.

In recent pentesting engagements, we’ve seen many vulnerabilities in client AWS environments due to their handling of Cognito. Below are some of those common Cognito findings.

1. Cognito “client” and “user pool” IDs (e.g. “59f6tuhfmt5lq2mqrnvl8l00sx” and “us_east_2_0b0RfnML2”)  are shown in HTTP responses, allowing for enumeration.
2. Cognito user registration is left open (the default setting), allowing an attacker to register using the IDs from step 1, even if no login portal exists in the web or mobile app.
3. The “identity pool” ID (e.g. “us-east-2:a4531178-c987-4abc-9a22-9dm4dlmc2ee5”) is shown in HTTP responses, allowing an attacker to obtain IAM credentials.

1. Custom attributes that are user-modifiable (the default setting) are used for role-based access control (RBAC). This lets an attacker gain privileges by updating attributes.
2. Standard user-modifiable attributes such as “email” are case-sensitive, accept changes immediately, and perform RBAC. This lets an attacker take over an account by mimicking its “email” if the back end is not case-sensitive. See this report: https://hackerone.com/reports/1342088
3. The user’s “id” token lists extra IAM roles that can be assumed by the user via the API, allowing an attacker to obtain more permissions and pivot through the AWS account.

During penetration tests, we often see the need for tools to quickly test Cognito for security vulnerabilities. For this reason, we have created two new modules for our open-source AWS exploitation framework, Pacu.

Cognito__enum – Cognito enumeration module using IAM creds with Cognito Read permissions

Cognito__attack – Cognito attack module using at least one Cognito resource ID (such as an “identity pool” ID)

To see these demonstrated, check out part 2 of the post.