This post is the second one I’ve done in regard to Facebook OAuth Vulnerabilities.
But, just so everything’s clear from the start, no apps need to be installed on the victim’s account. Even if the victim never allowed a single application on their Facebook account, it’s still possible to gain access on the account with the use of the Facebook Messenger app_id. This bug works on virtually any browser.
In the Facebook Messenger app_id, there’s also a special regex protection (app_id=220764691281998), but I was able to bypass it.
This bug was reported on 6 March 2013 and the Facebook Security Team fixed it right away.
On 26 February 2013, more OAuth bugs were reported that the Facebook Security Tem fixed quickly.
The Facebook OAuth Double URL encoding on Firefox browsers was reported on 6 February 2013 and fixed very quickly.
After I discovered the first OAuth Vulnerability http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-to-get-full.html, the Facebook Security Team tried to protect OAuth Token Hijacking attacks with the use of Regex Protection (%23xxx!,%23/xxx,/)
They rejected on hash sign request in “redirect_uri, next parameter” (next=%23/xxxx,next=%23xxx!) to thwart any OAuth Attacks.
However, instead of actually avoiding any attacks, Facebook allowed for a two-hash or multiple-hash sign request in “redirect_uri, next parameter” (next=%23/xxx/%23/xxx). This is largely because no one considered that you could exploit Facebook Oauth with a multiple-hash sign request.
So, is it possible to exploit OAuth with a two-hash sign request (%23/x/%23/xxxx)?
Yes, you definitely can.
I found that the redirection exhibits strange behavior when someone uses a multiple-hash sign request on Facebook.com
Example of a Multiple-Hash Sign Request:
This is pretty simple, but kind of amazing.
So, now we know that it’s possible to use a multiple-hash sign request (#/xxx/#/xxx) in our “redirect_uri, next parameter” in order to get past the one-hash sign request (#/xx) regex protection in Facebook OAuth (next=http://facebook.com/#/xxx).
Even so, a little bit more is required in order to exploit the OAuth Bug. One thing I discovered was that the Facebook OAuth rejects unauthorized subdomains in “redirect_uri, next parameter.”
Facebook only permits subdomains linked to the Facebook Mobile Version.
At the same time, Facebook rejects any unknown subdomains like:
It also rejects main domains like:
Again, this is bad news because, none of Facebook’s mobile versions (touch, m, 0) exhibit multiple-hash sign behavior in the request.
This request will be invalid and won’t redirect us to the desired messages screen. Thus, we need to work with a domain that’s the same as Facebook’s official domain (facebook.com). This domain needs to exploit the peculiar redirection behavior with the multiple-hash sign request (#/xx/#/xx) at facebook.com. But, at first glance, Facebook appears to reject any subdomain that is not an authorized mobile subdomain (like touch.facebook.com, etc.).
One way I found to bypass that protection is by using Facebook itself as a subdomain (that is, facebook.facebook.com). Sometimes, the answer can be right in front of you.
But, some other issues can still present themselves.
At this point, I should be able to access the files and directories in facebook.com by using the “redirect_uri, next parameter.” But, I can’t access my app that redirects the victims to the external website (files.nirgoldshlager.com) in order to save the access_token of the victim. This is because of the “malicious” app found at touch.facebok.com/apps/xxx and apps.facebook.com/apps/xxxx.
I came up with a few ways to take advantage of this situation.
First, I attempted to use my App or Page tab in the “redirect_uri, next parameter.”
(My “Malicious” App—located in facebook.com):
(Page Tab that redirects to external website—located in facebook.com)
Again, we encounter some bad news because I am not able to use these methods. There is simply too much redirection process for this attack. The Access_token of the victim won’t be sent to the external site even after 3 redirection requests in GET URL.
The thought then occurred to me that perhaps there is some way to redirect the victim right to my app (touch.facebook.com/apps/myapp). This would effectively limit the redirection process to three times.
So, I located a file called l.php in facebook.com. Many people are familiar with this file because it’s responsible for redirecting individuals to external websites. With this, Facebook provides a warning message which asks the user to confirm prior to redirection.
Thus, it seems like I am at a loss again.
But, I found that if I use 5 byte prior to the external website in l.php, it’s possible to bypass the warning message when redirecting the victim to facebook.com subdomains.
Bypass warning message by using 5 byte which then redirects the user to touch.facebook.com subdomain:
Now we can combine all of these methods to fully bypass Facebook OAuth/
1. Utilizing facebook.facebook.com subdomain bypasses subdomain regex protection in OAuth (facebook.facebook.com)
3. Get past the warning message in l.php with 5 byte (https://www.facebook.com/l/ggggg;touch.facebook.com)
4. Redirect the victim to external websites located within files.nirgoldshlager.com through my Facebook app in order to save the victim’s access_token in a log file.
Final PoC One Click (Works on every browser, Can bypass 2-STEP verification, the access token does not expire until the victim changes his password):
Full description of permission for Facebook Messenger Access Token:
ads_management create_event create_note email export_stream manage_friendlists manage_groups manage_notifications manage_pages offline_access photo_upload publish_actions publish_checkins publish_stream read_friendlists read_insights read_mailbox read_page_mailboxes read_requests read_stream rsvp_event share_item sms status_update video_upload xmpp_login
This particular bug was remedied a few weeks ago. I was looking for something unique for Facebook users within the contexts of the Firefox browser.
I discovered that an attacker can encode their payload with Double URL Encoding (%25xx) to attack Facebook users within Firefox and still bypass Facebook OAuth regex protection. This effectively sidesteps the hash sign regex protection in touch.facebook.com, facebook.com, x.facebook.com, and so on.
Also, if you’d like to use OAuth 2.0 on your own website, you can take a look at Egor Homakov (@homakov)’s post at http://homakov.blogspot.co.il/2013/03/redirecturi-is-achilles-heel-of-oauth.html. This post illustrates how exactly to repair these vulnerabilities in OAuth 2.0.
Be sure to read the risks in relation to OAuth 2.0 prior to using it on your own site.
Also please read the risks regarding OAuth 2.0 before you use it in your own site