This is a GREAT article by Nir Goldshlager
Today, I’m going to share a few of my favorite Stored XSS Findings in Facebook (Facebook Chat, Facebook Check In, Facebook Messenger. These findings are almost always interesting if you happen to find them in the right location.
For instance, what would occur if the Malicious Stored XSS Payload ran on the victim every time they checked in? You could also inject the Payload into the Facebook Chat Screen, which could be really interesting.
There are essentially two different ways to exploit Stored XSS issues.
1.
Let the victim visit our stored XSS Payload (Facebook Check-In, Facebook Messenger, Facebook Chat) on their own.
2.
Exploit it with the URL plus the Stored XSS data.
I wanted to locate an interesting spot within Facebook that would run the data on the victim each time they visited one of my places. I could also just run it through Facebook Chat.
This post will talk a lot about Stored XSS in regard to Facebook Chat, Check-In, Facebook Messenger (Windows Version).
The vulnerabilities mentioned here has been confirmed patched by the Facebook Security Team
Bug 1,
Stored XSS In Facebook Chat
When a user starts a new message within Facebook that has a link inside, a preview GUI shows up for that post. The GUI is used for presenting the link post. For this action, Facebook added extra parameters for the “post message” request.
I found an interesting parameter that looked like this:
attachment[params][title],attachment[params][urlInfo][final]
I noticed that Facebook does not verify whether or not the attachment[params][urlinfo[final] parameter is a legitimate link (http, https). So, it’s relatively easy for an attacker to alter those parameters to make them a malicious request.
For instance:
attachment[params][title]=PoC Click Me&attachment[params][urlInfo][final]=javascript:alert(6)
Facebook will later take those parameters and insert them into a “href” tag.
<a href=”javascript:alert(6)”>PoC Click Me</a>
Each time the victim clicks on this malicious message in Facebook Chat, the Stored XSS will begin to run on their client.
PoC Video:
Bug 2
Stored XSS In Facebook Check In
The other major Stored XSS that I located is in the Facebook Check-In Screen. This is a cool one because the XSS runs every time they visit the places that the attacker has been.
To make use of the Stored XSS in Facebook Check-In, the attackers needs to first construct a new location within Facebook Pages (https://www.facebook.com/pages/create/).
Then, the attacker must change the settings in this new location. For instance, they can alter the address info on the place settings to something like:
<img src=”a.jpg”onerror=javascript:alert(6)>
When the victim later decides to go to the place the attacker has been, a Stored XSS will run client-side.
Bug 3
Stored XSS In Facebook Messenger (Windows)
I also noticed that an attacker is capable of injecting a Stored XSS Payload in Facebook Messenger for Windows. Any time the victim logs into their account in the Messenger, The Stored XSS will be run on his account.
But, let’s stay focused on the issue at hand. In Facebook Messenger, I noticed that Facebook does not filter the page name. Facebook won’t permit you to make a name on Facebook with a Malicious Payload.
For instance:
Page Name:<xxxx>
For this to work, we need a user with a malicious name to be able to send a message to the victim.,
For example:
page name:<img src=”a.jpg”onerror=javascript:alert(6)>
So, how do we do this?
Facebook has an option to create a new page, correct?
In addition, pages are allowed to send messages directly to the users in Facebook.
So, if we change the name of our page to a JavaScript payload,
and then send a message to the victim from that page,
what would happen?
In this case, every time the victim logs into Facebook Messenger, a Stored XSS Payload would be run on their account.
PoC Video:
No comments:
Post a Comment