Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Identity pools serve a crucial role by enabling your users to acquire temporary credentials. These credentials are essential for accessing various AWS services, including but not limited to Amazon S3 and DynamoDB. A notable feature of identity pools is their support for both anonymous guest users and a range of identity providers for user authentication. The supported identity providers include:
Amazon Cognito user pools
Social sign-in options such as Facebook, Google, Login with Amazon, and Sign in with Apple
Providers compliant with OpenID Connect (OIDC)
SAML (Security Assertion Markup Language) identity providers
Developer authenticated identities
To generate Identity Pool sessions, you first need to generate and Identity ID. This Identity ID is the identification of the session of that user. These identifications can have up to 20 datasets that can store up to 1MB of key-value pairs.
This is useful to keep information of a user (who will be always using the same Identity ID).
Moreover, the service cognito-sync is the service that allow to manage and syncronize this information (in the datasets, sending info in streams and SNSs msgs...).
Pacu, the AWS exploitation framework, now includes the "cognito__enum" and "cognito__attack" modules that automate enumeration of all Cognito assets in an account and flag weak configurations, user attributes used for access control, etc., and also automate user creation (including MFA support) and privilege escalation based on modifiable custom attributes, usable identity pool credentials, assumable roles in id tokens, etc.
For a description of the modules' functions see part 2 of the blog post. For installation instructions see the main Pacu page.
Sample cognito__attack usage to attempt user creation and all privesc vectors against a given identity pool and user pool client:
Sample cognito__enum usage to gather all user pools, user pool clients, identity pools, users, etc. visible in the current AWS account:
Cognito Scanner is a CLI tool in python that implements different attacks on Cognito including unwanted account creation and identity pool escalation.
For more information check https://github.com/padok-team/cognito-scanner
The only thing an attacker need to know to get AWS credentials in a Cognito app as unauthenticated user is the Identity Pool ID, and this ID must be hardcoded in the web/mobile application for it to use it. An ID looks like this: eu-west-1:098e5341-8364-038d-16de-1865e435da3b (it's not bruteforceable).
The IAM Cognito unathenticated role created via is called by default Cognito_<Identity Pool name>Unauth_Role
If you find an Identity Pools ID hardcoded and it allows unauthenticated users, you can get AWS credentials with:
Or you could use the following aws cli commands:
Note that by default an unauthenticated cognito user CANNOT have any permission, even if it was assigned via a policy. Check the followin section.
The previous section followed the default enhanced authentication flow. This flow sets a restrictive session policy to the IAM role session generated. This policy will only allow the session to use the services from this list (even if the role had access to other services).
However, there is a way to bypass this, if the Identity pool has "Basic (Classic) Flow" enabled, the user will be able to obtain a session using that flow which won't have that restrictive session policy.
If you receive this error, it's because the basic flow is not enabled (default)
An error occurred (InvalidParameterException) when calling the GetOpenIdToken operation: Basic (classic) flow is not enabled, please use enhanced flow.
Having a set of IAM credentials you should check which access you have and try to escalate privileges.
Remember that authenticated users will be probably granted different permissions, so if you can sign up inside the app, try doing that and get the new credentials.
There could also be roles available for authenticated users accessing the Identity Pool.
For this you might need to have access to the identity provider. If that is a Cognito User Pool, maybe you can abuse the default behaviour and create a new user yourself.
The IAM Cognito athenticated role created via is called by default Cognito_<Identity Pool name>Auth_Role
Anyway, the following example expects that you have already logged in inside a Cognito User Pool used to access the Identity Pool (don't forget that other types of identity providers could also be configured).
It's possible to configure different IAM roles depending on the identity provider the user is being logged in or even just depending on the user (using claims). Therefore, if you have access to different users through the same or different providers, if might be worth it to login and access the IAM roles of all of them.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
