Archive for the Clickjacking Category

If you can see my Google Talk Badge on the right, either you’re browsing with anything else than IE8/Chrome/Safari/Firefox+NoScript, or the issue we’re talking about has already been fixed by Google. Edit 7 Dec 2009: the issue has been fixed, so I’ve removed my badge to prevent a spam flood.

Otherwise, you’re getting an error page (hard to read, since it’s embedded in a tiny frame) — or a blank one if you’re on Chrome — because Google is sending down a X-Frame-Options HTTP header with value

SAMEORIGIN

, allowing only pages served from www.google.com to embed this badge.

Now, Google playing the early adopter of bleeding edge security technologies like

X-Frame-Options

or STS, both in its browser and in its web properties, is really great because it speeds up their acceptance hugely, making the whole web safer. But if the service you’re offering is based on cross-site frames, you’d better keep them enabled ;-)

On a side note, users can easily disable NoScript’s implementation of

X-Frame-Options

, if needed, via about:config preferences: either globally (noscript.frameOptions.enabled) or per-embedding-site (noscript.frameOptions.parentWhitelist). Don’t worry, ClearClick will still be watching your back…

Something HotA rather funny (depending on your boss’ and wifey’s sense of humor) Clickjacking-based worm has been spreading on Facebook for the past few days.

Like mom said, you shouldn’t trust a nasty bikini miss and start clicking random buttons around… or just do what you want, who cares?
We’re all adult and NoScripters, aren’t we?

The latest epiphany of the vicious Clickjacking poltergeist that Twitter apparently can’t exorcise has a tiny face :)

Thanks to IE8’s touted Clickjacking protection which will work on those pages whose authors decide to adopt the new proprietary X-FRAME-OPTIONS header (now cross-browser), the buzz about this topic has been raising again. Unluckily, Clickjacking (or more precisely, talking about IE8’s mitigations, “frame-based UI Redressing”) is not well understood enough yet for the “technical” press to spare us some frankly embarrassing articles:

And so on…
Even Heise Security fell in this trap, sigh. The mood of most of these “reports” is, more or less,

Look ma, there’s this Clickjacking PoC which works in Chrome and Firefox, but is defeated in IE8, which has Clickjacking ProtectionTM. Did you see? IE is the most secure browser of the pack, OMGROTFLMAO!!!

Now, I know the ones to really blame and bash here are this so called “security firm” looking for (and finding) free advertisement by exploiting the security buzzword of the day, and the “security researcher” Aditya K. Sood. But why did nobody of these journalists and bloggers try to verify Secniche’s claims (and orthography)?

Clickjacking is a malicious software form that can seemingly take control of the links that an Internet browser displays for various Web pages. Once that takes place, and once a user tries to lick (sic!) on that link, the user is taken to a site that is unintended. In some cases, the user may be able to recognize this immediately; in other cases, the user may be totally unaware of what took place.Once an infected ad has been loaded into your browser, your clipboard (where you copy and paste text) becomes overwritten with a URL.

A vulnerability across a variety of browsers and platforms, a clickjacking takes the form of embedded code or script that can execute without the user’s knowledge, such as clicking on a button that appears to perform another functionThe exploit may also take over your browser and visit links without you knowing.

A clickjacked page tricks a user into performing undesired actions by clicking on a concealed link. On a clickjacked page, the attackers show a set of dummy buttons, then load another page over it in a transparent layer. The user thinks he is clicking the visible buttons, while he/she is actually performing actions on the hidden page.

The hidden page may be an authentic page, and therefore the attackers can trick users into performing actions which the users never intended to do and there is no way of tracing such actions later, as the user was genuinely authenticated on the other page.

Well, by these standards (and grammar and syntax), hereby I disclose my sensational “Clickjacking PoC” which works everywhere, even against IE8 RC1:

Clickjack The Target (http://www.yahoo.com) : (http://evil.hackademix.net)

Even better, mine is just 188 characters long, i.e. 1/3 of the one by Secniche:

<a href="http://yahoo.com"
onclick="location='http://evil.hackademix.net/images/stallowned.jpg';return false"
>Clickjack The Target (http://www.yahoo.com) : (http://evil.hackademix.net)</a>

Unfortunately, like I told Heise guys (who honestly rectified their article):

that’s not Clickjacking by any stretch of imagination, and hardly malicious: you just get on a “surprise” destination, but nothing more since it can’t do any of the cross-site evils (e.g. bypassing CSRF protection) of the real thing.

Or, quoting Michał Zalewski’s answer to Mr. Sood on BugTraq:

1) It is by now well-understood that because of the inherent and broadly depended on properties of HTML, every sufficiently featured browser is and likely will remain susceptible to the behavior known as clickjacking. A more thorough analysis, also covering Chrome, is provided here:

http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_(UI_redressing)

2) To my best knowledge, the proof of concept provided in your post, where a same-origin <div> follows a mouse pointer, is not a valid demonstration of the issue at hand.

Nor is mine, of course: LickJacking, maybe ;)

Talking about rectifications, Security Watch’s apology of Microsoft’s take on Clickjacking protection, while defending X-FRAME-OPTIONS against the general skepticism from security experts, emphatically warned twice that “NoScript won’t protect you”. Larry Seltzer’s premise, “JavaScript is not required for the attack” was obviously correct, but unfortunately for him (and fortunately for Firefox users), NoScript doesn’t rely on script blocking to defeat the attack. He had apparently never heard about ClearClick, the specific anti-Clickjacking protection provided by NoScript, which is extremely effective even if JavaScript is enabled (or the attack is scriptless). Ironically, ClearClick is also the only available implementation of Michał Zalewski’s “favorite solution”, which his article even tries to explain.

However, as soon as I managed to tell him about his mistake (after working around the unbelievable suckiness of PCMag’s spam filters, which coughed on any sentence of medium complexity and even on the word “google”), Larry demonstrated solid deontology. He honestly admitted to have been misled by an ancient post by RSnake, which actually reported that older NoScript versions could be circumvented by some Clickjacking setups, while more recent (ClearClick enabled) versions are effectively protected. Larry, I did appreciate that, and I’m sorry I couldn’t post not even a simple “thanks” as a comment on your Security Watch blog (danx? th3nx? 10x?)

As I promised in my previous posts about so called IE8’s “Clickjacking protection”, some hours ago I released the NoScript 1.8.9.9 development build, featuring experimental but complete compatibility with the X-FRAME-OPTIONS header support introduced by IE8 and unveiled yesterday by Eric Lawrence on the IE Blog.

As I said previously,

this is just a cross-browser compatibility effort: neither Firefox nor NoScript really need this feature. Traditional JavaScript-based frame busting works fine in Firefox, giving it the same degree of (modest) “protection” as IE8. NoScript users, on the other hand, are already fully protected, because ClearClick is the one and only countermeasure which works against any type of Clickjacking (frame or embed based), no matter if web sites cooperate or not.

However I also said this is nice to have. I had already imagined a functionally similar declarative solution, the SUB pseudo-method of ABE rules, and HTTP-based restrictions can actually be easier to deploy in some scenarios (e.g. using a Web Application Firewall).

More important, not every IT manager will have a chance of reading the reasons I exposed so far, explaining why IE8 has no more “Clickjacking protection” than its competitors. Our typical decision maker will just read a bullet list including “Clickjacking protection”, will find that no other browser dares such a claim and will base his choice (also) on that misleading comparison.

So let’s add this bullet, even if it does nothing against Clickjacking that “alternative browsers” couldn’t already do with traditional frame busting.

The following screenshot shows the original IE8 implementation as can be tested on my demo page:

X-IFRAME-OPTIONS demo in IE8 screenshot


And this is X-IFRAME-OPTIONS in action on Firefox (kindly provided by NoScript for now, but already in the works as a built-in):

X-IFRAME-OPTIONS demo in Firefox screenshot


But now that we’ve got “bullet parity”, let’s put the marketspeak aside and keep enjoying the only Clickjacking protection that really works “out of the box”: your friendly neighborhood ClearClick :)

Bad Behavior has blocked 7231 access attempts in the last 7 days.