Code phishing attack on OAuth 2.0 [RFC6749]

Code phishing attack is the attack that the adversary obtains the code and client credentials from the legitimate client and uses them against the honest token endpoint to obtain tokens thereby accessing the protected resources illegitimately.

Assumptions

There are not much assumptions needed for this attack.

1. The client and the server uses OAuth 2.0 [RFC6749].
2. The client developer is naive enough to be fooled by emails etc. (Compromised developer documentation.)

Attack Flow

There are several ways to achieve it but the simplest way to do it is to deceive the client developer and have them change the token endpoint to the one prepared by the adversary.

A sample attack would go like this in the case of unmodified RFC6749.

1. The adversary send an email from spoofed legitimate address saying something like:Dear valued customer:
   We are proud to announce that we have cut over the new token endpoint with better security and features. We are going to deprecate the existing token endpoint in 6 months time. During the transition period, the old endpoint continue working, but we urge you to move to the new endpoint https://example.com/v2.0/token at the earliest convenience
2. Believing the mail, the client developer changes the token endpoint to the bogus one.
3. Since the authorization endpoint has not changed, it continues to work normally and returns code.
4. The client sends the client credential and the obtained code to the “new” endpoint.
5. The adversary now has the client credential and the code so that he can use it against the honest token endpoint to obtain tokens. The ATTACK SUCEEDS.

Mitigations

There can be a couple of mitigation strategies

1. Make it illegal to use different authority for the Authorization endpoint and the Token endpoint. If they are different, the client MUST err. This does not involve wire protocol change.
2. Tell the client where the code can be used authoritatively.  [OAuth Meta] Draft-sakimura-oauth-meta, which has been there since 2012¹ achieves it. Also, using the issuer returned in draft jones-oauth-mix-up, which came out Jan 2016 ² to discover the token endpoint would also work. Note, just comparing the issuer does not do the job. See below.

Mitigation by OAuth Meta

OAuth Meta is a simple spec. The primary design of it is to return the metadata associated with the response together with the response, e.g, return the endpoint uris as query parameter in the case of authorization response, and link header in the case of token response. Although it was not specifically designed to address this code phishing attack, it actually works.

1. The adversary send an email from spoofed legitimate address saying something like:
   Dear valued customer:
   We are proud to announce that we have cut over the new token endpoint with better security and features. We are going to deprecate the existing token endpoint in 6 months time. During the transition period, the old endpoint continue working, but we urge you to move to the new endpoint https://example.com/v2.0/token at the earliest convenience
2. Believing the mail, the client developer changes the token endpoint to the bogus one.
3. Since the authorization endpoint has not changed, it continues to work normally and returns the code but with token endpoint uri, turi to the redirection uri. where the code is supposed to be sent.
4. The client sends the client credential and the obtained code to turi.
5. The ATTACK FAILS.

Why just comparing the issuer does not work?

This is a solution proposed by the participants of the Darmstadt seminar held in December 2016.

1. The adversary send an email from spoofed legitimate address saying something like:
   Dear valued customer:
   We are proud to announce that we have cut over the new token endpoint with better security and features. We are going to deprecate the existing token endpoint in 6 months time. During the transition period, the old endpoint continue working, but we urge you to move to the new endpoint https://example.com/v2.0/token at the earliest convenience
2. Believing the mail, the client developer changes the token endpoint to the bogus one.
3. Since the authorization endpoint has not changed, it continues to work normally and returns code to the redirection uri. It returns the OAuth issuer string, which is the location of the discovery file truncated before .wellknown, and the client_id.
4. The client checks the issuer string is the same as what it knew, and the client_id is the same as its client_id. They are the same, so the test passes. (Section 4.)
5. The client sends the client credential, code, state, and redirect url to the “new” endpoint.
6. The adversary now sends the obtained client credential, code, state, and redirect url to the honest token endpoint to obtain tokens. The ATTACK SUCEEDS. 

For this approach to work as a mitigation, you have to actually fetch the content of the discovery document and use the value included in it instead. If it were to be done every time, in case of Google, this approach requires over 1060 bytes. (The oauth-meta’s over head was only 61 bytes.) Also, it adds an extra round trip adding latency. Thus, it has to cache the payload of the discovery file.

1. https://tools.ietf.org/html/draft-sakimura-oauth-meta-05
2. http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01