Hi friends! In this blog, I’m going to tell you how in a Cobalt pentest, I found an unvalidated and open redirect vulnerability in the OAuth server, which I managed to escalate to Account takeover through a little trick to get the user's access token.
Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials, tokens, etc.
Description
When I perform a pentest in Cobalt, the first issues I search for are Unvalidated and Open Redirect since they are straightforward to identify and give a lot of play.
In this case, through the Burp Bounty Pro tool (https://burpbounty.net), I was able to identify an "Unvalidated and Open Redirect" issue in the "ReturnUrl" parameter of the "http://localhost/login" endpoint.
Attack
To take advantage of this vulnerability, we need the victim’s interaction, in this case, an application user. If an authenticated user accesses the following link:
It redirects to:
The problem here is that when you send a request to http://attacker_server.tld with the id_token after the hashtag, browsers don't send the value of what's after the hashtag therefore, you can’t obtain the id_token and escalate the issue.
To solve this problem and be able to get the user's id_token, what I did was create a javascript code to host it on my web server so that it obtains the value after the hashtag and sends it, for example, to a burp collaborator host (although you could store it in a file).
Thus, the steps of the attack will be the following:
Step 1: An authenticated victim access to this URL with the javascript code in get_token.html:
Step 2: Using the mentioned javascript code, the attacker can retrieve the id_token value and send it to http://HASH.oastify.com attacker server:
Step 3: The attacker can access the victim's account using the following request and the previous id_token:
After accessing the victim's privileges, we can change the password since the functionality does not ask us for the previous password.
These types of issues due to misconfigurations of OAuth are very common in web applications. The only characteristic here is that, in this case, the “id_token” contained a hashtag before, which makes it challenging to get the token and elevate it to account takeover.
The open redirect on its own is Low. In this case, the victim will receive the malicious link in their email and, when clicked, will leak the id_token, access_token, token_type, expires_in, scope, state, and session_state values to the attacker leading to a complete account takeover.
Solution
Redirect URLs are a critical part of the OAuth flow. After a user successfully authorizes an application, the authorization server will redirect the user back to the application. Because the redirect URL will contain sensitive information, the service mustn’t redirect the user to arbitrary locations.
The best way to ensure the user will be redirected to appropriate locations is to require the developer to register one or more redirect URLs when creating the application. You can check these URLs for more information:
- https://www.oauth.com/oauth2-servers/redirect-uris/redirect-uri-registration
- https://www.oauth.com/oauth2-servers/redirect-uris/redirect-uris-native-apps
- https://www.oauth.com/oauth2-servers/redirect-uris/redirect-uri-validation
I hope you liked it.
Cheers!
