Skip to main content

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


So after my first OAuth Vulnerability discovery

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

Multiple Hash Sign Request Example:

Redirect to:


Redirect to:

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=,

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:

But rejects unknown subdomains:

(, main domains (,,etc..)

Again, Bad News!
That's Because In any mobile version of Facebook (,,, We won't see the multiple hash sign behaviour in our request

For Example:!messages!/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,

I need it to exploit the strange redirection behavior with multiple hash sign request  (#/xx/#/xx) under
At first sight it seems that facebook rejects any subdomain except the mobile subdomain version (,etc...),

I found that if I use facebook as a subdomain (, 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 via the redirect_uri,next parameter right?,
But i can't access my app that redirect victims to the attacker's external website ( , To Save the access_token of the victim,
That's Because my "malicious" App located at,
I thought of a few ways to exploit this situation,


Create a Page Tab in Facebook Page that redirect to external website (,


Try to access my app from domain


Find a Site Redirection Vulnerability in

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


(My "Malicious" App, Located in

(Page Tab that redirect to external website, Located in

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 to limit the redirection process to three times for example.

So, I found that there is a file called l.php in, 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

For example:

Warning message:;

Bypass warning message by using  5 byte , Redirect to subdomain:;


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

Exploit Summary


Using subdomain to bypass subdomain regex protection in OAuth (


Exploit the strange redirection behavior in with multiple hash signs (;


Bypass the warning message in l.php with 5 byte (;


Redirect the victim to external websites located in 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):

 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


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,   ,,etc..


See you next time :)


Share this with your friends