Tuesday, March 12, 2013

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


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




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:



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,


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


Try to access my app from facebook.com domain


Find a Site Redirection Vulnerability in facebook.com.

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


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


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


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:


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



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

Exploit Summary


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


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


Bypass the warning message in l.php with 5 byte (https://www.facebook.com/l/ggggg;touch.facebook.com)


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


 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 touch.facebook.com, facebook.com   , x.facebook.com,etc..




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


See you next time :)

Thursday, February 21, 2013

How I Hacked Facebook OAuth To Get Full Permission On Any Facebook Account (Without App "Allow" Interaction)


I decided to share one of my favorite flaws i discovered in  facebook.com, 
This flaw allowed me to take a full control over any Facebook account,
By exploiting this flaw I could steal unique access tokens that provides me full control over any Facebook account,
just to clarify there is no need for any installed apps on the victim's account, Even if the victim never allowed any application in his  Facebook account, I could still be getting full permissions (This bug works on any browser)

To make this exploit work, The victim only need to visit a webpage,
So OAuth is used by Facebook to communicate between Applications and Facebook users, Usally users must allow/accept the application request to access their account before the communication can start.

Any Facebook application might ask for different permissions,

For example: 

Diamond Dash,Texas Holdem Poker only have permission to basic information and post on user's wall,

I found a way in to get a full permissions (read inbox, outbox, manage pages, manage ads, read private photos, videos,etc..) over the victim account even without any installed apps on the victim's account, 
Another advantage in the flaw I found is that there is no "Expired date" of the Token like there would be on any other application usage, In my attack the token never expires unless the victim change his password :),

Every application in Facebook have different app_id, For example 'Diamond Dash' will be app_id=2, And 'Texas Holdem Poker' will be app_id=3

The next,redirect_uri parameter (next=,redirect_uri=), only accepts the owner app domain,
For example app_id=2389801228 belongs to 'Texas Holdem Poker' app, So the 'next' parameter will allow only zynga.com domain (i.e next=http://zynga.com), 
If the domain is different (nirgoldshlager.com) in  the 'next', 'redirect_uri' parameter, Facebook will block this action,

Facebook perform match between your app_id and your next parameter, Facebook also sends the access token via GET request to the owner application after the user allowed it,
Now that we know how Facebook OAuth works, Lets talk about my finding, 
I started to think of my options, what if i can redirect the application OAuth Request to a different 'NEXT' URL?? First i tried to change the 'next' parameter to a different domain and they block my action,
Then  i tried to change the next parameter to facebook.com domain, and got blocked again with general error message,

I found that if you use a sub-domain for example: xxx.facebook.com, Facebook will allow this action,
But if you try to access folders / files in x.facebook.com (x.facebook.com/xx/x.php), Facebook block you,
So i notice that facebook.com use a Hash sign and ! in there URL (x.facebook.com/#!/xxxx),
I tried to perform this action in the next parameter (next=x.facebook.com/%23!/), And Facebook blocked me again!,
Then i tried to put "something" between the hash sign and the ! (%23x!), And Facebook didn't block this action,
Seems that there is a Reg-ex protection, Cool!,

But wait!,

If we put something like this (https://beta.facebook.com/#xxx!/messages/), the action will not treat at is the same as #! in our client, and will not redirect us to the message screen,
I figured I had to find a way around it, so I started to fuzz characters between ! and # so I can make any browsers (IE,CHROME,Safari, Firefox..) treat it like #!,   
Now it's time for fuzzing!,
%23~!   (Works on all browsers) 
%23%09! (Works on all browsers)
Cool!, this trick works on touch.facebook.com/#%09!/,m.facebook.com/#~!/, or any other Facebook mobile, touch domain),
So Now I'm able to redirect the victim to any Files / Directories in any Facebook Sub-domain,
Then i created a Facebook application that will redirect the victim to external website for sending the access_token of the victim to my "malicious" external website, 

For Example: (Zynga Texas Holdem OAuth Bypass):
And my Facebook application will redirect to files.nirgoldshlager.com domain and save the victim access_token in a log file (files.nirgoldshlager.com/log.txt),

Amazing!, Now I'm able to steal access tokens of any Facebook application,

But wait!!!, 


To make a successful attack, the victim need to use a Facebook application (Texas Holdem Poker, Diamond Dash, etc..),
And these applications only have a basic permissions, We can always change the scope of the application permission and set a new permission but this method not powerful, Because the victim need to accept the new permissions of the app (https://www.facebook.com/connect/uiserver.php?app_id=2389801228&next=http://zynga.com&display=page&fbconnect=1&method=permissions.request&response_type=token&perms=ads_management%20create_event%20create_note%20email%20export_stream%20manage_friendlists%20manage_groups%20manage_notifications%20manage_pages%20offline_access%20photo_upload%20publish_actions%20publish_checkins%20publish_stream%20read_friendlists%20read_insights%20read_mailbox%20read_page_mailboxes%20read_requests),

I wanted something more powerful!,

Something that will give me full permissions (read inbox, outbox, manage pages, manage ads,access to private photos, videos, etc.) on the victim's account without any installed application on the victim and make Facebook do the Goldshake ;),

So i started thinking 
How this can be done?,
What if i will use a different app_id?? app_id of Facebook Messenger for Example,
Does the user need to accept Facebook Messenger app in his Facebook account?,

The answer is no,
There are built-in Applications in Facebook that users never need to accept , And this application have a full control on your account,
Also i found that this access_token never expired in Facebook messenger,

Only after the victim change his password, Then the access_token will be expired, But why the hell the user would change his password?,

PoC (Works on all browsers, No need for installed application on the victim account) :


Facebook Security Fixed this bug

Full description of permission for Facebook messenger app:

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

Works also on 2 step verification accounts, When it came to access_token , 2 Step verification will fail.


PoC Video:

How I Hacked Facebook OAuth To Get Full Permission On Any Facebook Account from Nir on Vimeo.

Cya Next time!,

Monday, January 7, 2013

How I Hacked Facebook Employees Secure Files Transfer service (http://files.fb.com )



I want to share my finding regarding Password Reset logic flaw in Facebook Secure Files Transfer for Employees.

Sometimes when you add a new security measure (Such as Secured File Transfer by Acellion),  You may unintentionally expose your organization to these kind of risks

First of all,

If you look at https://files.fb.com, You can understand that this service belongs to Accellion (http://www.accellion.com/solutions/secure-file-transfer),

Now to test a Password Reset logic flaw, We need an account to test for Reset Password Right?,

It seems that Facebook was trying to avoid the creation of accounts in Accellion after removing the register form from the pageview,

I discovered that if you know the direct location of the form (/courier/web/1000@/wmReg.html), You can easily bypass that protection and create an account in files.fb.com,

Now this vulnerability has been fixed and you can't open a new account in files.fb.com, Fixed:

OK, So now we got a new account in files.fb.com Right?, Cool!,
The next step was to download the 45 days trial of Accellion Secure File Sharing Service (http://www.accellion.com/trial-demo),

I realized that that there is two kinds of trial versions of Accellion,

1. Free 45 Day Cloud Hosted Trial (5 users)

2. Free 45 Day Virtual Trial (5 users)

So I chose the VM(virtual) trial, Just for getting all the files and source code of this Accellion application,

The "Bad News" was that the VM trial got a protection and you can't access to the files through the VM Version,

Anyway you can bypass it by mounting the virtual drive in second linux machine ,
This solution made it possible to get all the files names and folders in Accellion Secure File Transfer,

Accellion encrypt their source files content (php) by using ionnCube PHP Encoder (http://www.ioncube.com/sa_encoder.php).

In some older versions of Ioncube you can decrypt this "encrypted" files:

Bad news again!, This Version of ionCube was not vulnerable to a possible decryption , I was disappointed because If I had the source I had the core.

This could help me to find more cool issues such as: Command Execution, Local File Inclusion, etc..,

Anyway i dropped this subject and keep my research on,

I found this interesting file called wmPassupdate.html,

This file used for a Password Recovery in Accellion Secure Files Transfer,

I realized that there is another parameter in the Cookie when you are trying to recover your password in wmPassupdate.html,

This parameter call referer, I found that the value of this parameter use Base64 encoding, Wtf?, I didn't think Base64 (for encryption) was still alive these days, Yes, It appears so :),

So i decoded the base64 value, And so that the decoded data appeared to be my email address ("dbeckyxx@gmail.com"), Cool!, I started to delete all the "junk" cookies un-uneeded parameters and kept only the referer parameter,

I encoded back to Base64 a different email of my test account in files.fb.com, And then copied it into the referer cookie parameter,

Then i started to change the email address parameter in my POST request, to the victim email account and change the pass1,pass2, to my chosen password,


PoC Image:

PoC Video:
Facebook, Accellion Fixed this issues, I also reported 20+ different bugs in Accellion Secure File Transfer Service, They fixed all of them :) Soon i will publish OAuth bypass in Facebook.com, Cya Next time!,

Thursday, January 3, 2013

Another Stored XSS in Facebook.com

Another Stored XSS in Facebook.com, Another 3500$ Bounty


I want to share my Stored XSS finding in facebook.com,

First of all, I must mention discovering Stored XSS issues in facebook.com is quite rare these days , 
For a start I would like to present some steps that I have made to make this Stored XSS Work,
Currently, If you want to open a page (facebook.com/pages/create.php) with a malicious Page Name (Javascript Payload), You get blocked by automated system:

 (I'm "sure" there might be a bypass, I didn't spend time to test it yet). 

1. I was able to use another feature in order to bypass the protection and therefor change the page title name by using Facebook Api for Updating Page Attributes (https://developers.facebook.com/docs/reference/api/page/#page_access_tokens), (The Pages API is just a Hint :)),
In this case, I changed my Page Title name to "malicious" javascript payload (<img src="xx.jpg"onerror=alert(6)>),

2. In Facebook Pages, You can Add Application to your Page by using  Adding To A Page Box:

When you add a tab to your page, Facebook will display which pages you own/manage by the title of each page,

As a result of that situation I was able to execute a Stored XSS, (Facebook didn't filter the Page Title Name),

Now it seems to be only a Self Stored XSS, although In Facebook Pages You can use the Admin Roles Settings to add admins to your Page.
  In this situation, I added the victim to be the administrator of my "malicious page", The victim didn't need to accept this admin request, it will be added automatically to my Page, So now I was able to exploit this XSS By sending a Single link to the Victim


PoC Image:

PoC Video


Tuesday, January 1, 2013

FusionChart 2013 Flash New Attacking Vectors

My Findings about FusionCharts Vulnerabilites:

A) I found that an attacker is able to execute a XSS attacks by loading a external XML File via dataUrl Parameter,

This Parameter looking for a valid configuration fie for display Graph Data in FusionChart,

In this case, An attacker is able to use the link parameter (http://docs.fusioncharts.com/charts/contents/DrillDown/LinkFormat.html) to execute javascript payloads on the client
for example (Click the Graph For XSS PoC):


When the victim will click on the malicious graph, The XSS Payload will be run on his client,

B) An attacker is able to perform redirection attack (New Tab) in Firefox, This can be done by using the LogoURL Parameter,

This Parameter allow to attacker loading a external swf file (swf),
To perform a Redirection attack, The attacker will use the req.send function in ActionScript and use his malicious swf file,

Req.send function:
(req.send("http://nirgoldshlager.com", "_blank", "GET");),




Cross Domain Policy file:


What about anti-XSS Regex action script?

We all remember the old debugmode=1 Bug in FusionChart Right :)?

I have examined the fusionchart's action script and discovered they do perform a poor trial of blocking Cross site scripting attacks using regex to match dangerous XSS attempts

FusionChart action-script is trying to block the Dataurl=XXX XSS Attack  by using a poor regex that is only looking for javascript/asfunction keywords, don't let the colon ":" check to trick you ;) this check is only performed in case javascript/asfunction is detected.

Line 126-128:

function filterXSSChars(strURL)
    if (_isOnline == true && ((strURL.toLowerCase().indexOf("javascript") != -1 || strURL.toLowerCase().indexOf("asfunction") != -1) && (strURL.indexOf(":") != -1 || strURL.indexOf("%3A") != -1)))

An attacker is able to bypass this regex easily in IE by using vbscript instead of javascript,



Also you can use data:text/html; to bypass it or mocha,livescript for older version in Netscape,

The correct solution might be:

asfunction|javascript|vbscript|data|mocha|livescript|feed|pcast (Thanks to @irsdl for the feed tip, And @Milad_Bahari for the pcast, (feed,pcast XSS Works on some older versions of Firefox)

 As discovered by security researcher "Ben Hayak"(@benhayak)
a new paramter(defaultDataFile) has been revealed which is vulnerable to new XSS Attack.

There is another parameter called defaultDataFile this parameter can be used to trigger another XSS incase the DataURL parameter is protected/blocked

Line 125:

var _defaultDataFile = unescape(getFirstValue(rootAttr.defaultdatafile, "Data.xml"));

We can use this parameter to execute a XSS attack,

Sunday, December 9, 2012

swfupload.swf XSS


Just want to share my finding,

I found another XSS Vulnerability in swfupload.swf



Vulnerable Parameter:


Vulnerable Code:

this.buttonTextField.htmlText = this.buttonText;

(For Wordpress Fans, Works on Version 3.3.1 and below)


Wednesday, June 13, 2012


Killing a bounty program, Twice (HITB 2012 Slides) by Nir Goldshlager, Itzhak (Zuk)


Google Picnik File Inclusion (Shell on Google server), The Picnik is Over!


Google Affliate Network, Hijack any user account by permission vulnerability,


XSS in blogger.com

PoC Videos:

Google Books DOM XSS:

Google Calender Stored XSS: 

Google Analytics, Cool Stored XSS: 

Google Friend Connect Stored XSS: 

Google Knol, Access to privates docs using Google Knol Translator Tool: 

Google Feedburner Stored XSS:


To Be Continue ;) Enjoy....