Vulnerable Cognito

This is a laboratory from RhinoSecurity labs focusing in a vulnerable cognito AWS service, this post will describe all of my process to explore the laboratory focusing in the exploitation scenario: “In this scenario, you are presented with a signup and login page with AWS Cognito in the backend. You need to bypass restrictions and exploit misconfiguration in Amazon Cognito in order to elevate your privileges and get Cognito Identity Pool credentials.”

On the signup page, we need to input some information to create an account, there is a requirement that e-mail must contain the domain name “ecorp.com”, different domains will not be accepted (until now).

When we try to change the attribute of “email” to other, it says that the value needs to bee null or the same as username and the e-mail address inside the “Username” isn’t verified.

In some seconds the confirmation code was received in the interaction server (the registration was done without ecorp domain). Why don’t just create an account and try to login directly? The application refuses accounts without verification.

The same request used to create an account was used the confirm the registration, it’s only needed to change the “X-Amz-Target” value to “ConfirmSignup” and include the key “ConfirmationCode” in the JSON. After send the account was approved.

Back to login, after perform the authentication in the main panel, the application redirects the created user to a HTML page saying “you’re a reader!!”.

From this point, maybe we need to pass some arbitrary value to change the user permission. Reading the source code from the login page I could discover an “admin.html” file, so probably it’s the right permission that needs to be changed.

The access variable comes from result of authentication in cognito and the attribute that needs to be set is “custom:access”, information that can also be obtained reading JWT token. Attempts to change it in the registration request, assigning the new value was done, but it not worked. The next step was using AWS CLI with cognito-idp to change user attributes.

After change the attribute in command line and login, we obtained an administration account:

Looking the request history we could notice that, the second request done in the authentication process, returns an AWS secret key. Behavior that could appear making a request to “GetCredentialsforIdentity” target or getting credentials in CLI: https://docs.aws.amazon.com/cli/latest/reference/cognito-identity/get-credentials-for-identity.html

To setup the key is just needed to add it in the credentials configuration file.

aws configure --profile temp

From this point, we could obtain a list of lambda functions, returning a link to download the function and read the code, it’s an important thing to look because the execution of the lambda can be exploited resulting in escalating privileges or other actions.

Command used to get the function:

aws lambda get-function --function-name CognitoCTF-vulnerable_cognito_cgidc6jfu7dukd --profile temp --region us-east-1

Download the code, its used to update user-attributes in the pool. To leak other credentials the lambda function was modified to return the environment variables:

The following image shows the modification of the lambda function to the new code:

After updating, the function was invoked returning the environment variables. We could notice the presence of session token and secrets, this access didn’t returned more opportunities to elevate privileges.

aws lambda invoke --function-name CognitoCTF-vulnerable_cognito_cgidc6jfu7dukd /your/destination/path/ret --profile temp --region us-east-1