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.

Cross domain content extraction with fake captcha

Content extraction is one of the recently documented UI redressing vectors. It exploits Firefox vulnerability that allows to display any URL HTML source in an iframe like this:

<iframe src="view-source:http://any-page-you.like/cookies-included">

With social engineering attacker tricks user into selecting (usually invisible) page source and dragging it to attackers' controlled textarea. A simple demo is here:

Drag & drop other page source (cross-domain)

Once attacker gets the page source dropped into his textarea, he may begin to extract contents (like session IDs, user names, anti csrf tokens etc.) and launch further attacks.

However, this way of using the vector requires significant effort from a user and is pretty difficult to exploit in real world situation (there's some clicking and dragging involved). Also, it will stop working once Mozilla disallows cross origin drag & dropping.

I've found a neat way to do cross-origin content extraction that might be more suitable for some classes of websites. Ladies and gentleman, let me present Fake Captcha:

XSS hackme challenge solution (part 2)

After revealing the first part of the solution for the XSS hackme challenge we'll discuss the second, last part. This time we'll talk about a IE-only vulnerability that allowed you to inject and run arbitrary Javascript code (XSS), but to properly exploit it we'll need:

• a local web server (we'll need to host some pages)
  
• Internet Explorer browser (6,7,8 will do)

SPOILERS ahead!

5 ways to prevent clickjacking on your website (and why they suck)

Clickjacking attack is a very nasty attack. The most common form of it is when an attacker creates a webpage and tricks the visitor to click somewhere (on a link, button, image). Attacker in the code of his website includes a victim website (like Facebook, your webmail, amazon) that is cleverly hidden from the user and placed so that a user actually clicks on a victim website. Citing the example from OWASP page on clickjacking:

For example, imagine an attacker who builds a web site that has a button on it that says "click here for a free iPod". However, on top of that web page, the attacker has loaded an iframe with your mail account, and lined up exactly the "delete all messages" button directly on top of the "free iPod" button. The victim tries to click on the "free iPod" button but instead actually clicked on the invisible "delete all messages" button. In essence, the attacker has "hijacked" the user's click, hence the name "Clickjacking".

The problem with clickjacking attack is that it is extremely difficult to prevent. Unlike other popular vulnerabilities like CSRF, XSS, SQL injection, this one is based on a functionality that is widely used in the web nowadays - frames (I'm skipping the case of plugin-based-clickjacking for clarity here). Frames allow you to nest one webpage or widget in another page - this is now used for login pages, commenting, previewing content in CMSes, for JavaScript interactions and a million other things.

Browsers nowadays use same origin policy to protect your data if you're framing or being framed from another domain (this prevents JavaScripts from talking to each other and accesing documents across the domain boundary). But JavaScript is not required for a clickjacking attack - CSS is enough. In the simplest form (e.g. used in recent Facebook users attack), you're just using a small <iframe>, and position it absolutely. The rest is just social engineering.

Our users have a few options to protect themselves. So maybe 1% of them will be "protected". But what can we - web developers do to prevent the clickjacking on our sites? Sadly, not much, but here's the list:

New Facebook clickjacking attack in the wild - fb.59.to

There's a malicious website set up at http://fb.59.to that tries to trick users into a clickjacking attack that shares the link on victims' Facebook accounts.


Some Facebook users today saw a comment looking like this (new pix!):

Clicking on the comment that links to

http://www.facebook.com/l.php?u=http%253A%252F%252Ffb.59.to%252F%253F4ff11a526ae73e9f170bbe6702ebb93c&h=..somehash...&ref=nf

redirects users to http://fb.59.to web page.

On this page they are given a fake Turing test that tricks them into clicking a "blue button" which is their clickjacked Facebook page positioned at adding a new comment ("Share" button). The whole web page looks like this (clickjacked area is marked green):

In page source we can see that there is a IFRAME element:

<iframe frameborder=0 scrolling=no height=25 width=100
src="2.php?u=http://fb.59.to/?...somehash...."
></iframe><span style=background-color:yellow;><font 
style=font-size:13 ; color=white>

The target URL (2.php) has another IFRAME which in turn has yet another one with the target page being

<div style="left:-90px;top:-386px;position:absolute;"
<iframe height=400 width=250  src="http://www.facebook.com/sharer.php?u=http://fb.59.to/?hash" 
frameborder=0  scrolling=no> </iframe>
</div> 

Clicking on the button shares the malicious link on Facebook.

The page has a meta-redirect set up to a Youtube movie launching  in 12 seconds so a users might get the impression that the movie launched because they successfully passed the Turing test.

Multiple iframes are probably set up to trick clickjacking protections within browsers. A quick look tells that currently Firefox and Chrome are vulnerable to the attack, IE and Opera being safe, although that requires a bit more time to investigate.

Update: The attack does not work in IE and Opera only because of incorrect HTML used in one of the pages in this malicious site. Doing a simple fix in HTML makes both mentioned browsers also vulnerable to the attack.

Thanks go to Grzegorz Ciborowski and Pawel Czernikowski for detecting the attack.