Incognito Travel
Challenge Lab (Easy) - by Tyler Ramsbey
The following post by 0xb0b is licensed under CC BY 4.0
Scenario
Incognito Travel is rolling out a new authentication process for their flagship travel application. Before deploying to production, they have contracted Hack Smarter to rigorously test the new authentication flow. The target application leverages Amazon Cognito to handle its identity and access management.
Summary
Summary
In Incognito Travel we begin with reconnaissance, identifying the target user Cory from the About page and confirming his existence through username enumeration at the login portal. We then enumerate the frontend source code and extract AWS Cognito configuration parameters, including the userPoolId and clientId. We create a new user account with credentials we control and retrieve the access token from browser local storage. Using this token with the AWS CLI, we query the Cognito identity provider to verify current user attributes. We then exploit Cognito's misconfiguration by updating our account's email address to a case-variant of the target user Cory@hacksmarter.hsm. Due to the application's improper reliance on email for user identification rather than the OpenID Connect sub claim, combined with Cognito's default allowance for authenticated users to modify their own email attributes, the case-insensitive email matching allows us to assume the victim's identity. Logging in with the modified credentials grants us authenticated access as the victim account
Recon
We start the scenario and get the following website in scope.
We do not perform a port scan and initially enumerate the page manually. When visiting the site, we have a travel portal infront of us with an about page and a login.
From the About page, we can identify the user Cory with his email address cory@hacksmarter.hsm.
Next, we visit the login page, this is preset with another mail address agent@hacksmarter.hsm. We try this with arbitrary credentials and can see that this user does not exist by the resulting error message. Username enumeration is possible here.
Next, we try the mail of Cory and this time we get an incorrect password message.
Source Code Inspection
We take a closer look at the source code and find a COGNITO_CONFIG containing the userPoolId and clientId.
Account Creation
But we also saw that we can request access at the login page. When we click the link, we're taken to a registration modal where we can create our own user account. We'll choose the following credentials:
After registering the user we are able to log in. We have a dashboard in forn of us as a Guest user as it seems.
From the local storage tab in our developers tool we can retrieve the access token. Which would allow us to query user attributes... But more on that in the next section.
AWS Cognito
From the scenario and the source code, we can see that AWS Cognito is being used.
AWS Cognito is a service that handles user login, permissions, and user management for apps. It has two main parts: User Pools and Identity Pools.
User Pools let users create accounts and log in. Once logged in, users get an access token that lets them use AWS tools to view and change their account information.
Access as cory@hacksmarter.hsm
However, AWS Cognito can also be misconfigured, as described in the following article, which could allow an account takeover if the app uses the email attribute to identify users. With that the app can be tricked into treating an attacker as someone else.
The vulnerability exists due to two key issues:
Writable Attribute(s): By default, AWS Cognito allows authenticated users to modify their own attributes (including email) using the access token via the AWS API.
Improper User Identification: Applications using the email attribute instead of the sub (subject) claim to identify users. According to the OpenID Connect specification, only the sub claim is guaranteed to be unique and should be used for user identification.
We'll follow the blog and recreate the steps.
Get Cognito Access Token
We're using the session with our newly created account. With the Dev Tools of our Browser of choice we inspect the Cookies, local storage, etc. to get the access token and do find it in the local storage.
Verify Current User Attributes
First, we'll try to query the cognito-idp using the access token we received, and list the users attributes.
We save the TOKEN in a variable in our terminal to use it to query for the cognito-idp using AWS CLI.
Next, we retrieve the user's information from AWS Cognito.
Update Email to Victim's Address (Case-Variant)
With the clientId and your access_token we update the email attribute of the newly created account to CORY@hacksmarter.hsm.
Next, we verify the change.
Login as cory@hacksmarter.hsm
After we've configured the user's email of our newly created account, we'll try to log in agina as cory@hacksmarter.hsm using our credential pair:
We succefully logged in and are authenticated as cory. We get access to the flag on the dashboard.
Last updated