A two-part blog series by Rhino Security Labs that talks about common issues seen in deployments using AWS Cognito, and how they automated testing and attacking of said issues. AWS Cognito is a front-end solution by AWS for user auth and authorization, typically used for web and mobile apps. Cognito has this concept of “pools”, where you have a user pool for managing login and registration information (essentially an OpenID Connect Identity Provider), and an identity pool, which generates temporary AWS credentials for a user to access various assets stored on AWS. Due to insecure defaults, it’s easy to have problematic configuration issues that can give an attacker a lot of information, including IAM credentials.

Potential issues

• Client, user pool, and identity pool IDs are commonly found in HTTP responses, which can be pulled by an attacker to obtain IAM credentials
• Cognito’s user registration is left open by default, allowing an attacker to use the client and user pool IDs to register even if the application doesn’t export a login or registration portal
• Custom attributes used for Role-Based Access Control (RBAC) can be configured by the user by default
• Other attributes such as the email can be case-sensitive, which could allow account takeover if the backend isn’t case-sensitive

Rhino Security Labs used these findings to develop modules for their Pacu AWS exploitation framework called cognito__enum and cognito__attack. The enumerator will attempt to send requests and parse responses to pull user pool and client IDs, and check attributes such as the password policy and Multi-Factor Authentication (MFA) config to alert if MFA isn’t required or if the password policy is weak, and it’ll try to enumerate identity pool IDs to see if access keys and session tokens can be obtained.

The attack module will try to leverage those IAM credentials to perform various actions, such as registering an account, testing for registering with emails with different cases, and assuming roles to escalate privileges.