Archive for the IE Category
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:
>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:
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 ;)
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 18.104.22.168 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,
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:
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):
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 :)
Yesterday I published a blind analysis of the so called “Clickjacking protection” included in IE8 RC1. “Blind” because, hype aside, there was no technical documentation available, even if the feature was targeted to web developers who — in order to protect their users — should modify the way their pages are served.
After a while, Microsoft’s David Ross sent me an email confirming that my wild guesses about IE8’s approach, its scope and its limitations were indeed correct. The only information obviously missing from my “prophetic” description was the real name of the “X-I-Do-Not-Want-To-Be-Framed-Across-Domains” HTTP header to be sent before the sensible pages, and today this little mystery has been finally unveiled by Eric Lawrence on the IE Blog:
Web developers can send a HTTP response header named X-FRAME-OPTIONS with HTML pages to restrict how the page may be framed. If the X-FRAME-OPTIONS value contains the token DENY, IE8 will prevent the page from rendering if it will be contained within a frame. If the value contains the token SAMEORIGIN, IE will block rendering only if the origin of the top level-browsing-context is different than the origin of the content containing the X-FRAME-OPTIONS directive. For instance, if http://shop.example.com/confirm.asp contains a DENY directive, that page will not render in a subframe, no matter where the parent frame is located. In contrast, if the X-FRAME-OPTIONS directive contains the SAMEORIGIN token, the page may be framed by any page from the exact http://shop.example.com origin.
However in my post I had also written that having such a scriptless alternative as a cross-browser option would be nice:
I do believe that a declarative approach to control subdocument requests is an excellent idea: otherwise I wouldn’t have included the SUB pseudo-method in ABE Rules Specification (pdf). Moreover, as soon as I’ve got some less blurry info (David Ross, I know you’re listening, why don’t you drop me a line?), I’ll be happy to immediately implement a compatible feature in NoScript and lobby Mozilla for inclusion in Firefox 3.1.
David kindly answered
I think this would be fantastic and it’s a great place to start building some bridges.
I agree, in facts I’ve filed an enhancement request for Firefox, and I’m already working to release a NoScript development build featuring X-FRAME-OPTIONS support: that’s relatively easy, since I can hook in the work I’m already doing for the ABE module. (Update 2009-29-01: I just released NoScript 22.214.171.124 development build, featuring full experimental X-FRAME-OPTIONS compatibility support).
Speaking of NoScript, I’ve got a small but important correction to the otherwise excellent article Robert McMillan wrote for PC World (IDG News) yesterday:
Because clickjacking requires scripting, the attack doesn’t work when NoScript is enabled.
This statement is wrong twice:
- NoScript does not need scripting to be disabled in order to protect its users against Clickjacking: its exclusive ClearClick anti-Clickjacking technology works independently from script blocking.
Microsoft released Internet Explorer 8 RC1 yesterday with the usual big fanfare, and one of its main marketing punchlines is its “exclusive” clickjacking protection:
Microsoft Adds Clickjacking Protection to IE8 RC1
One major security update to block Web attacks known as “clickjacking” that the company said makes IE8 the only Web browser to offer such protection.
The security feature that thwarts clickjacking in IE8 RC1 allows Web-site content owners to put a tag in a page header that will help detect and prevent clickjacking. If a site that uses the IE8 tag detects clickjacking, it will give Web users an error screen letting them know that the content host has chosen not to allow that content, and gives them the option to open the content in a new window that is protected from the attack.
Microsoft IE8 Hits RC1 Milestone, Stops Clickjacking
RC1 also includes protection against “Clickjacking,” a ploy to get users to click on account buttons while covering the actual site being clicked on using a frame – the first browser available to counter this type of threat, Pratt said.
Microsoft Goes After Clickjacking in IE8
While offering few technical details of its methods for stopping clickjacking, Microsoft appears to have not only tried to address the browser-based issues, but also sought out the help of Web site owners to make IE8 less vulnerable to the attacks.
Now, it will remain to be seen whether or not the features offered in the IE8 RC browser have an effect in preventing clickjacking attacks, but you have to give the guys in Redmond credit.
Hype aside, forgiving Microsoft’s habit of forgetting precursors of their “first and unique” technologies, what can we infer from the “few technical details”?
At this moment, Tue Jan 27 2009 15:20:49 GMT+0100, searching for Clickjacking on the Microsoft Developer Network I can find just 1 result, i.e. the Internet Explorer 8 Release Candidate Now Available IEBlog’s post, and it doesn’t give away any more juice:
We’ve worked closely with people in the security community to enable consumer-ready clickjacking protection. Sites can now protect themselves and their users from clickjacking attacks “out of the box,” without impacting compatibility or requiring browser add-ons.
Putting all these pieces together, IE8’s clickjacking countermeasure seems to be a “tag” (or a HTTP header, or both) which “web content owners” must attach to the page(s) of theirs to be protected.
So it’s not about users protecting themselves: “Sites can now protect themselves and their users”.
To sum up, there’s always been a well known and accepted server-side protection option which works everywhere except in IE. As far as we know, the newly proposed anti-Clickjacking tag or header (much like the “X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes” suggested as fix #1 in Michal Zalewski’s famous “UI Redressing” post and to ABE’s SUBdocument rules) offers an alternate option which, currently, works only in IE8 RC1. Funny how Microsoft can turn a weakness unique to their browser in yet another non-standardized feature to embrace and extend HTTP overnight! :)
Furthermore, the press choose the “Clickjacking” buzzword over the proper “UI Redressing” definition, probably to amplify its hype effect. But historically, the term “Clickjacking” has been invented to designate a Flash-based (or more in general embedding-based), not necessarily cross-domain attack. Does this “anti-Clickjacking” feature actually work against the “original” Clickjacking concept?
Nothing suggests it does yet, but we’ll see… 2009-01-28 Update: now we for sure know IE8 RC1 offers no protection against plugin-based Clickjacking, as expected.
However, I do believe that a declarative approach to control subdocument requests is an excellent idea: otherwise I wouldn’t have included the SUB pseudo-method in ABE Rules Specification (pdf). Moreover, as soon as I’ve got some less blurry info (David Ross, I know you’re listening, why don’t you drop me a line?), I’ll be happy to immediately implement a compatible feature in NoScript and lobby Mozilla for inclusion in Firefox 3.1.
That said, the bad news for IE enthusiasts is that they’ve got no magic “out of the box” protection, despite the press releases I quoted. True, it doesn’t require any “browser add-on” (don’t you love how they managed again to avoid mentioning NoScript?), but it comes with an even more strict requirement: all the sites to be protected must already have adopted a new proprietary hack, i.e. something no end-user can verify, let alone enforce (so long for the “consumer-ready” label).
We’ve been preaching about XSS holes and other web programming errors for years, but developers still fall in the same pitfalls over and over again: if the guys in Redmond really believed that web security could be fixed server-side by just educating web authors, why did they eventually bother adopting those client-side anti-XSS filters which NoScript pioneered?
Microsoft’s David Ross sent me an email confirming that my “preemptive” analysis about IE8’s approach, intents and limitations was correct. A blog post by Eric Lawrence is on its way, explaining the technical details as an an “authoritative” source, but I guess the only information still missing is the real name of the header :)
About my stated intention of implementing a compatible feature in NoScript and lobbying Mozilla to do the same, he wrote
I think this would be fantastic and it’s a great place to start building some bridges.
I think so too.
Update 2 (2009-01-28)
Mistery unveiled: the header is “X-FRAME-OPTIONS: DENY” (I still prefer “X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes”, but whatever). Now that I’ve got “less blurry details”, NoScript’s compatibility feature is on its way, and I hope Firefox’s is too.
Posted by: Giorgio in IE, Mozilla, Security, NoScript
Yesterday and today we’ve got a blizzard of web browser security updates:
Microsoft zealots are taking this as an argument to argue that all browsers are equally insecure, and therefore there’s no reason to switch (from IE) for security purposes (an advice which, on the other hand, starts spreading even on mainstream media).
This is quite a debatable statement, if you think about it.
IE’s vulnerability, being a zero day, is actively exploited in the wild by thousands of compromised web sites and puts several millions of users worldwide at risk, while both Firefox’s and Opera’s are still embargoed.
Firefox will be automatically updated for its users before bad guys can analyze and exploit the patched vulnerabilities. That’s effective patching. Opera is in a slightly worse shape, since its update mechanism is not fully automated (it requires user to manually download and install the new version). Microsoft already failed this time, because the vulnerability has been already known and exploited for more than one week.
Right, zero day situations can happen to any software product, and Opera and Firefox might face a similar shitstorm tomorrow. But, even so, there are some interesting differences:
- Patching policies: Microsoft implements a predictable monthly patching cycle. This is probably good for corporate IT departments, which can carefully plan the so called “black Tuesday” to minimize their troubles, but it’s also good for evildoers and security attention-bitches, who can carefully plan their exploits or disclosures to maximize their impact. Zero day critical vulnerabilities in three different Microsoft products have been disclosed immediately after last “black Tuesday”: is this really a coincidence?
Firefox and Opera, on the other hand, issue security updates whenever they’re ready and tested.
- Agility: as everybody knows, Internet Explorer is tightly coupled with the underlying Windows OS platform, and this makes both mitigation and fixing more difficult. In this case, for instance, the suggested work-around required not just hardening the browser itself by blocking scripts and plugins, but also disabling a system-wide data access component (OLEDB): this affected not just surfing the web, with many sites inaccessible or malfunctioning, but also most Windows applications relying upon databases.
To summarize: all the browsers can have vulnerabilities and equally need timely patching, but not all the users are equally vulnerable.