Oauth security misconfiguration on facebook

Published 2016-05-14 00:00:00 +0200 5 min read 8 comments

OAuth is an open standard for authorization, commonly used as a way for Internet users to log in to third party websites using their Microsoft, Google, Facebook, Twitter, One Network etc. accounts without exposing their password.

Misconfigured OAuth setting could lead to Account take-over, CSRF attack and Token leakage(code and access token). Visit http://www.oauthsecurity.com for more list of OAUTH attacks. This blog post is about facebook Misconfigured OAuth setting that has a security impact on its users. The bugs were reported, and Facebook had mitigated the bugs Before I disclosed it.

Quick Jump

0x01-Bypass moves(Facebook Aquisition) oauth 2 redirect_uri

I created an OAuth application which registered redirect_url is https://www.google.com/,  so it authorization_uri must not be

 https://api.moves-app.com/oauth/v1/authorize?response_type=code&client_id=<client_id>&scope=<scope>&redirect_uri=https//yahoo.com

https://api.moves-app.com/oauth/v1/authorize?response_type=code&client_id=<client_id>&scope=<scope>&redirect_uri=facebook.com

But when I changed the redirect_uri to this https://www.google.com.ph (appends .ph suffix domain on moves redirect_uri). Surprisingly, it works :) Besides the redirect_uri can also be bypassed via /../../. for example, if the redirect_uri is https://www.google.com/app/url change the redirect_uri to ` https://www.google.com/app/url/../../ `

The flaw could be used to leak access_token of victim user to attacker’s domain.

According to the OAuth 2 documentation, the redirect_uri must be equal to registered redirect_uri http://tools.ietf.org/html/rfc6819#page-62

0x02 - Leak mailchimp access_token via open redirector

Facebook sends email notification about saved link of the user every week. If the user clicks any link in his email notification, the browser will be redirected to facebook.com then redirect to the original link without the use of Facebook linkshim. It seems this is an Open redirector bug. 

 https://www.facebook.com/saved/redirect/?user_id=100000169908395&object_id=1007549219269324&surface=saved_email_reminder&mechanism=clickable_content

 The vulnerable parameter is object_id, we can get the object_id in https://www.facebook.com/saved/?cref=38 when we use using this endpoint 

 https://www.facebook.com/timeline/app/collection/item/curation/(used to delete saved link).

Exploitation

In the exploitation part, I used the open redirect of facebook to leak access_token of MailChimp OAuth. Facebook Ads Manager https://www.facebook.com/ads/manage/?act=109060336 can import MailChimp customer data by using OAuth 2. I have found there is no restriction of redirect_uri value in MailChimp OAuth (Covert Open redirect), so we can abuse the open redirect vulnerability of facebook to leak the access_token of the victim user.

Step of Reproduction

  • Go to your profile then post a link (link to malicious site)
  • save the link by clicking the dropdown button on upper right of a post then click the save link.
  • now you need to use your user_id and the object_id of the link.
  • The final open redirect PoC must be
  https://www.facebook.com/saved/redirect/?user_id=100000169908395&object_id=910603298986679&surface=saved_email_reminder&mechanism=clickable_content
  • Use the final open redirect PoC as redirect_uri of mailchimp oauth 2 i.e.
 https://login.mailchimp.com/oauth2/authorize?response_type=token&client_id=112041070777&redirect_uri=https%3A%2F%2Fwww.facebook.com%2Fsaved%2Fredirect%2F%3Fuser_id%3D100000169908395%26object_id%3D910603298986679%26surface%3Dsaved_email_reminder%26mechanism%3Dclickable_content

Video Demostration

0x03 - Cross-site request forgery on OAuth Clients(Modifies Victim’s spotify playlist Via CSRF),

Facebook user can embed a spotify playlist on his facebook timeline by posting a spotify link such as this one

 https://play.spotify.com/album/31d6jaMCDe28dAmBv63bBY,

on that embedded playlist, user has an option to add that playlist on his spotify account by using oauth 2, facebok uses spotify oauth 2 to do that action.

I have found that facebook uses the spotify oauth 2 without using the state parameter of the oauth, according to OAuth 2.0 Threat Model and Security Considerations and spotify oauth documentation, the state parameter is used to prevent CSRF attack on oauth(see http://tools.ietf.org/html/rfc6819#section-3.6 and https://developer.spotify.com/web-api/authorization-guide/ -‘Your application requests authorization’). Because there is not csrf protection malicious user could make a csrf attack against facebook that updates victim’s playlist.

Hack Steps

  • post the link on your timeline
 https://play.spotify.com/album/31d6jaMCDe28dAmBv63bBY)

to generate the embbed playlist then copy the authorization url of spotify. This is the authorization url of spotify that uses by facebook

 https://accounts.spotify.com/en/authorize?client_id=9cc4aaeb43f24b098cff096385f00233&response_type=code&redirect_uri=https%3A%2F%2Fwww.facebook.com%2Fmusic%2Fspotify%2Fauth%2F&scope=user-library-modify+user-library-read&show_dialog=true
  • now removed the &show_dialog=true parameter of the authorization url so the final url will be 
 https://accounts.spotify.com/en/authorize?client_id=9cc4aaeb43f24b098cff096385f00233&response_type=code&redirect_uri=https%3A%2F%2Fwww.facebook.com%2Fmusic%2Fspotify%2Fauth%2F&scope=user-library-modify+user-library-read
  • If the victim visits the PoC link, CSRF will be triggered

video Demonstration csrfonouathfacebookandspotify.mp4?dl=0