A couple more common OAuth 2.0 vulnerabilities

Dor1s — Mon, 18 Sep 2017 13:58:53 +0000

TL;DR The couple of bugs described below are common across different OAuth 2.0 implementations. The bugs may allow a malicious application to maintain an access to victim's account even after access revocation performed by the victim.

1. Race Condition for access_token / refresh_token generation

According to any OAuth 2.0 API documentation and to OAuth 2.0 RFC, when an application (client in terms of OAuth) obtains code value from OAuth 2.0 Provider (i.e. the moment when user authorizes an application), this value should be exchanged for access_token. It seems to be obvious that one code value should be exchanged for one access_token (or for a single pair of access_token and refresh_token, if resresh tokens are supported). Also RFC contains quite explicit requirements about that:

1) https://tools.ietf.org/html/rfc6749#section-4.1.2:

If an authorization code is used more than

once, the authorization server MUST deny the request and SHOULD

revoke (when possible) all tokens previously issued based on

that authorization code. The authorization code is bound to

the client identifier and redirection URI.

2) https://tools.ietf.org/html/rfc6749#section-10.5:

Authorization codes MUST be short lived and single-use. If the

authorization server observes multiple attempts to exchange an

authorization code for an access token, the authorization server

SHOULD attempt to revoke all access tokens already granted based on

the compromised authorization code.

However, most of OAuth 2.0 providers we've tested either didn't have that mechanism or had a race condition bug in it. Due to that, many of the provides had authorization issues.

Proof Of Concept

0) register an application with OAuth 2.0 provider you're going to test

1) open link to authorize the application

2) log into user (i.e. victim) account and Authorize the application

3) obtain code value from callback URL

4) try to exploit Race Condition for obtaining access_token:

#!/bin/bash
for i in {0..20}
do
 curl --data "code=$1&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&redirect_uri=CALLBACK_URL&grant_type=authorization_code" "https://OAUTH_PROVIDER/oauth/token" &
done
# where $1 is code value (first parameter passed to the script)

5) please note that you may have to do several attempts to explot the race condition

6) if several access_token values obtained, check whether each of them is valid

7) go to application settings for victim's account and revoke access for the application

8) check whether all access_token values became invalid; if only one access_token has been revoked and all the rest stay active -- this is the worst case

PoC for refresh_token is similar to the one just described, but on step 4 you may legally obtain access_token and refresh_token pair. Then you need to exploit Race Condition for reshresh_token request the same way:

#!/bin/bash
for i in {0..20}
do
 curl --data "refhresh_token=$1&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&redirect_uri=CALLBACK_URL&grant_type=refresh_token" "https://OAUTH_PROVIDER/oauth/token" &
done
# where $1 is refresh_token value (first parameter passed to the script)

Explotation of Race Condition for refresh_token is more dangerous than for access_token, as usually there is no way for an attacker to fail. Each exploitation gives at least one new refresh_token value that may be used later. So, number of token pairs grows exponentially, if provider is vulnerable.

Statistics

32 OAuth 2.0 providers tested
26 out of 32 had race condition bug:

5 providers returned the same access_token value for successful competing requests -> good behavior
1 provider generated different access_token values, but only one token is valid -> not bad behavior
20 providers generated different access_token values and all of them were valid -> bad behavior, as it violates the RFC + unexpected flaws caused by multiple tokens/contexts generation are possible

10 out of 20 providers had issues with revocation of access (step 8 from the PoC succeeded for them) -> the worst case: a victim sees that access is revoked, but malicious application still has access to victim's account

2. Missing invalidation of authorization code during access revocation

Another issue which is common for multiple OAuth 2.0 implementations. It is not race condition bug. It is a logical error caused by misunderstanding of some "states" in OAuth 2.0 flow.

OAuth 2.0 API makes it possible for users to grant access to their accounts to some third-side applications. Of course, users are able to manage such applications' access to their accounts and may deny access for any application. When user denies access for the application, all access_token values (and refresh_token as well) are being revoked and become invalid. But not only access_token should be revoked, authorization code (it is an intermediate token used in OAuth2 Authorization Flow) must be revoked as well. Sadly, most of OAuth2 API implementations do not revoke authorization code during access revocation. It may be exploited in order to restore access to user's account by malicious application right after access revocation.

Proof Of Concept

0) register an application for OAuth 2.0 provider you're going to test

1) open link for authorization of the application

2) log into user (i.e. victim) account and Authorize the application

3) obtain code value from callback URL

4) obtain access_token, check its validity if you wish

5) open link for authorization again (i.e. repeat step 1)

6) most of providers support automatic redirect to callback URL on this stage (also there may be additional parameters for that in URL: like force_approval or approval_prompt or some checkbox in applications settings), this makes exploitation easier; otherwise, Authorize the application manually

7) copy code value from callback URL and save it for furture usage

8) go to application settings page for victim's account and revoke access for the application

9) ensure that access_token obtained on step 4 is invalidated

10) exchange code value from step 7 for new access_token, check whether new access_token is valid

If new access_token is valid, that means malicious application still has access to user's account even after revocation of authorization by the user.

For real attack scenario it is important to mention the following:

a) it seems that step 5 requires interaction from user, actually it is not necessary

b) authorization code obtained via callback has certain lifetime, but it is not an issue as well

Malicious application that does not want to lose access to the user's account needs to place on its web site something like:

<html>
    <img src="https://OAUTH_PROVIDER/authorize?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&redirect_uri=CALLBACK_URL&scope=SOME_SCOPE&response_type=code">
</html>

Such code will "silently" produce new authorization code each time it has been loaded by the user. Check the traffic or contents of access.log on the callback server while opening a page with the html-snippet listed above:

root@server:/var/log/nginx# tail -f access.log
<...>
<IP hidden> - - [16/Apr/2015:13:08:56 +0000] "GET /callback?state=0123456789abcdef&code=xlDxVYdnJlsAAAAAAAAFQDUmzla7P8Jg9fM2rNxwP8U HTTP/1.1" 200 14 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36"

As you see, the malicious application has just obtained new code value that would not be revoked when user clicks "Delete Authorization".

Statistics

29 OAuth 2.0 providers tested
18 out of 29 of them had the issue

3 OAuth providers tested for the first issue are not included in statistics for the second one (32 - 29 = 3), as they had even bigger issues with access revocation: it was either not implemented at all or was not accessible by user.

Summary

read and understand RFCs and standards very attentively, many bugs are caused by bad implementation, not by bad requirements
be extremely careful when you develop multi-threaded applications
being a user, do not grant access to unknown apps :)

Tags:

oauth

oauth2.0

race condition

access_token

refresh_token

AVULN Blog - access_token

A couple more common OAuth 2.0 vulnerabilities