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 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?
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,
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.
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.
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.
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:
I’ve chosen two applications (Skype and Dropbox) to illustrate the risks of Facebook OAuth.
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)
then the attacker can use any valid subdomain of skype.com.
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).
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:
I gave Microsoft a heads up about the site redirection problem and all the attendant risks. They then repaired the problem.
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).
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):
The next parameter redirects us to the file I uploaded using the Dropbox file upload:
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.
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:
On the downside, Facebook can’t employ these fixes and the flaw in Facebook OAuth remains intact.
Cya Next time,