Hack In Paris talk and future events

Videos of recent Hack In Paris 2012 conference have just been published, among those there is a recording of my talk: "HTML5 - something wicked this way comes":

With accompanying slides:

Html5: Something wicked this way comes (Hack in Paris) from Krzysztof Kotowicz

Plans for next few months:

• BruCON (24-25.09, Ghent, Belgium) - Kyle 'Kos' Osborn & Krzysztof Kotowicz - Advanced Chrome Extension Exploitation
• Security BSides (12-14.10, Warsaw, Poland) - I’m in your browser, pwning your stuff: Atakowanie poprzez rozszerzenia Google Chrome
• Secure 2012 (22-24.10, Warsaw, Poland) - Atakowanie przy użyciu HTML5 w praktyce

And a few neat exploits in the queue, waiting to be released ;)

How Facebook lacked X-Frame-Options and what I did with it

In September 2011 I've discovered a vulnerability that allows attacker to partially take control over victim's Facebook account. Vulnerability allowed, among other things, to send status updates on behalf of user and send friend requests to attackers' controlled Facebook account. The vulnerability has been responsibly disclosed as part of Facebook Security Bug Bounty program and is now fixed.

XSS ChEF - Chrome extension exploitation framework

Recently I've been busy with my new little project. What started out as a proof of concept suddenly became good enough to demonstrate it with Kyle Osborn at BlackHat, so I decided I might just present it here too ;)

CodeIgniter <= 2.1.1 xss_clean() Cross Site Scripting filter bypass

This is a security advisory for popular PHP framework - CodeIgniter. I've found several bypasses in xss sanitization functions in the framework. These were responsibly disclosed to the vendor and are now fixed in version 2.1.2. (CVE-2012-1915).

Fun with data: URLs

Data URLs, especially in their base64 encoding can often be used for anti XSS filter bypasses. This gets even more important in Firefox and Opera, where newly opened documents retain access to opening page. So attacker can trigger XSS with only this semi-innocent-link:

<a target=_blank href="data:text/html,<script>alert(opener.document.body.innerHTML)</script>">clickme in Opera/FF</a>

or even use the base64 encoding of the URL:

data:text/html;base64,PHNjcmlwdD5hbGVydChvcGVuZXIuZG9jdW1lbnQuYm9keS5pbm5lckhUTUwrMTApPC9zY3JpcHQ+

Chrome will block the access to originating page, so that attacker has limited options:

But what if particular XSS filter knows about data: URIs and tries to reject them? We bypass, of course :) I've been fuzzing data: URIs syntax recently and I just thought you might find below examples interesting:

data:text/html;base64wakemeupbeforeyougogo,[content] // FF, Safari
data:text/html:;base64,[content]
data:text/html:[plenty-of-whitespace];base64,[content]
data:text/html;base64,,[content] // Opera

Here are full fuzz results for vector:
data:text,html;<before>base64<after>,[base64content]

Browser	Before (ASCII)	After (ASCII)
Firefox 11	9,10,13,59	anything
Safari 5.1	9,10,13,59	anything
Chrome 18	9,10,13,32,59	9,10,13,32,59
Opera 11.6	9,10,13,32,59	9,10,13,32,44,59

Not a ground-breaking result, but it may come in handy one day for you, like it did for me.

Chrome addons hacking: Bye Bye AdBlock filters!

Continuing the Chrome extension hacking (see part 1 and 2), this time I'd like to draw you attention to the oh-so-popular AdBlock extension. It has over a million users, is being actively maintained and is a piece of a great software (heck, even I use it!). However - due to how Chrome extensions work in general it is still relatively easy to bypass it and display some ads. Let me describe two distinct vulnerabilities I've discovered. They are both exploitable in the newest 2.5.22 version.

tl;dr: Chrome AdBlock 2.5.22 bypasses, demo here and here, but I'd advise you to read on.

Chrome addons hacking: want XSS on google.com?

For a few days now I'm checking various Chrome extensions code looking for vulnerabilities (see also the first post of the series). There are many. Most of them due to lazy programming (ignoring even the Google docs on the subject), some are more subtle, coming from poor design decisions.

As for the risk impact though, there are catastrophic vulnerabilities. This is just a sample of what code is committed to Chrome Web Store and can be downloaded as a Google Chrome extension.

How would you like an XSS on google.com?

Chrome extensions can alter the contents of a webpage you're navigating (if they have the permission for the URL). In web security, what is the worst thing you might do when altering HTML document on-the-fly? Of course, XSS. Even if the page itself is totally safe from XSS, an addon might introduce it (it's similar to just entering javascript:code()in address bar) and the page cannot possibly defend from it (more or less).

Google documentation about Chrome extensions warns about this exact threat. But, as it turns out, seeing is believing, so there you go. Let me tell you about some minor extension (196 users as of now, which is the only reason why I'm 0daying now) that allowed me to XSS Google.