Alarm Raised For "Clickjacking" Browser Exploit 308
Shipment Date writes "ZDNet's Zero Day blog has some new information on what looks like a scary new browser exploit/threat affecting all the major desktop platforms — Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, Opera and Adobe Flash. The threat, called Clickjacking, was to be discussed at the OWASP conference but was nixed at the last minute at hte request of affected vendors. From the article: 'In a nutshell, it's when you visit a malicious website and the attacker is able to take control of the links that your browser visits. The problem affects all of the different browsers except something like lynx. The issue has nothing to do with JavaScript so turning JavaScript off in your browser will not help you.'"
FF 3.0.2 safe? (Score:2, Informative)
Summary wrong (Score:5, Informative)
The issue has nothing to do with JavaScript so turning JavaScript off in your browser will not help you.'
The quote from the article says you can protect yourself by disabling scripting:
In the meantime, the only fix is to disable browser scripting and plugins. We realize this doesnâ(TM)t give people much technical detail to go on, but itâ(TM)s the best we can do right now.
Re:Summary wrong (Score:5, Informative)
The first quote is also from the article, so it's not the summary's fault. The article is vague and self-contradictory, so I'm calling bullshit until and unless further details are given.
Re:Bullshit? (Score:1, Informative)
Adobe was mentioned in TFA, no specific details were given but I'd guess that flash is implicated.
Re:FF 3.0.2 safe? (Score:1, Informative)
Sounds like this one:
http://www.mozilla.org/security/announce/2008/mfsa2008-40.html [mozilla.org]
Re:Summary wrong (Score:5, Informative)
The zdnet article is pretty vague, but I think it refers to the problem detailed in this message from Michal Zalewski [whatwg.org]:
"A malicious page in domain A may create an IFRAME pointing to an application in domain B, to which the user is currently authenticated with cookies. The top-level page may then cover portions of the IFRAME with other visual elements to seamlessly hide everything but a single UI button in domain B, such as 'delete all items', 'click to add Bob as a friend', etc. It may then provide own, misleading UI that implies that the button serves a different purpose and is a part of site A, inviting the user to click it."
Disabling JavaScript won't prevent the attack. It will break some mitigations, though!
Re:Summary wrong (Score:5, Informative)
the problem is actually in dhtml, but javascript makes the exploit 'much easier'
hence, the attack sites will all be using javascript, because it's easier than writing it entirely in dhtml just to score and extra 1 click from the guy who disabled javascript because he doesn't trust it.
BTW: in theory even sites like slashdot can be infected because the attack applies to all CSS coded sites. nice.
oh, BTW, is you have noscript installed, this vulnerability can only force clicks within the same domain, since cross site code is automatically disabled.. AFAIK the only way to disable CSS is to use obsolete browses like lynx.
Re:Turn to Lynx? (Score:4, Informative)
Lynx and Links do not support IFrames, so they are not vulnerable. In fact, any browser not capable of advance CSS and/or IFrames is safe. Unfortunately, that's not very many browsers.
Re:Summary wrong (Score:4, Informative)
I thought "DHTML" was just a term for manipulating the DOM on the fly using JavaScript. How do you do DHTML without JavaScript?
Re:Information (Score:5, Informative)
It's about using IFRAMES + CSS to make confusing visual elements that cause users to perform actions they didn't think they were performing. Feel better? ;-)
Re:Summary wrong (Score:5, Informative)
+1 for "vague and self-contradictory."
From TFA: "The issue has nothing to do with JavaScript so turning JavaScript off in your browser will not help you." and then "The exploit requires DHTML." As far as I know, DHTML requires a client-side scripting language--the most popular of which (only?) is JavaScript.
Re:OWASP (Score:1, Informative)
So, after much deliberation we opted to pull our speech voluntarily, due to the extremely neutered information weâ(TM)d have to be sharing. Weâ(TM)d much rather share the full breadth of what we found when it can be discussed more openly as to not diminish the danger of the flaw by only talking about small parts of the issue. There will still be holes in many websites due to this problem even after the short term patches are available, but weâ(TM)d rather a few of the more critical problems get patched before we go public.
However, I must stress, this is not an evil âoethe man is trying to keep us hackers downâ situation, a la Michael Lynn vs. Cisco, or Chris Paget vs. HID, or MIT vs. MBTA and so on. We proactively decided it was better to pull the speech ourselves for the time being and for anyone who was looking forward to the speech all I can say is I hope to make it up to you once the vendors are in a better spot. It wasnâ(TM)t an easy decision but it really feels like the best option we have given the current situation. If youâ(TM)re desperate for a way to patch your browser from the issue disable scripting and plugins for the time being. More to come.
Taken from http://ha.ckers.org/blog/20080915/clickjacking/ [ckers.org]
Re:Hurray for us lynx users! (Score:5, Informative)
Hmm, I'm able to use lynx to log into Gmail. Granted, I had to accept a million cookies and other things along the way.
Lynx Version 2.8.6rel.4 (15 Nov 2006)
libwww-FM 2.14, SSL-MM 1.4.1, GNUTLS 1.6.2, ncurses 5.6.20080308(wide)
Built on linux-gnu May 2 2007 08:54:50
Re:OWASP (Score:2, Informative)
So, after much deliberation we opted to pull our speech voluntarily, due to the extremely neutered information we'd have to be sharing. We'd much rather share the full breadth of what we found when it can be discussed more openly as to not diminish the danger of the flaw by only talking about small parts of the issue.
-from ha.ckers.org
Re:Summary wrong (Score:2, Informative)
My take (Score:5, Informative)
From google cache:
Clickjacking
Thereâ(TM)s been a bit of drama over the last week or so around the upcoming world OWASP conference in New York. Itâ(TM)s surrounding a talk that Jeremiah and I were planning on doing the first day of the conference. Jeremiah and I have been working on some interesting browser security issues which also effect a lot of downstream people/websites/technologies as well. Sounds like a good talk right? We thought so too!
Alas, it turns out that some of the issues we found werenâ(TM)t just a little bad - they were a lot bad. So bad, in fact, that we felt compelled to do some responsible disclosure. One issue lead into another issue into another and poof - we have at least two and probably more incoming vendor patches at a yet to-be-determined date. And weâ(TM)ve only worked with a few vendors. So⦠yah. Itâ(TM)s pretty bad.
As you may have guessed the first is a browser company, Microsoft (to be expected since itâ(TM)s a browser issue to begin with). The second is Adobe - who have been working closely with us on this one since we first told them about the problem. We have been working on proof of concept code since before Blackhat and finally got our ducks in a row with real working exploit code a few weeks ago. And that is pretty much when the problems started. None of the issues we found relating to the browser were particularly easy to fix, it turns out.
The related issues we found that affect websites (instead of browsers) is thankfully slightly easier to deal with on a one off basis, but that too is going to be a problem. There are a lot of much easier hacks out there against websites for sure, but what weâ(TM)ve been working on breaks some previously good security measures. The correct solve will not be patching every web-site on earth. Instead it will likely end up being a browser patch against every major browser. The idea of every webmaster in the world patching their own sites is a non-starter. Although Iâ(TM)m sure lots of people are going to run out and patch their sites rather than wait for the normal browser patch and release cycle for all browsers everywhere. Weâ(TM)ve discussed the high level concern with both Microsoft and Mozilla and they concur independently that this is a tough problem with no easy solve in sight at the moment.
So, after much deliberation we opted to pull our speech voluntarily, due to the extremely neutered information weâ(TM)d have to be sharing. Weâ(TM)d much rather share the full breadth of what we found when it can be discussed more openly as to not diminish the danger of the flaw by only talking about small parts of the issue. There will still be holes in many websites due to this problem even after the short term patches are available, but weâ(TM)d rather a few of the more critical problems get patched before we go public.
However, I must stress, this is not an evil âoethe man is trying to keep us hackers downâ situation, a la Michael Lynn vs. Cisco, or Chris Paget vs. HID, or MIT vs. MBTA and so on. We proactively decided it was better to pull the speech ourselves for the time being and for anyone who was looking forward to the speech all I can say is I hope to make it up to you once the vendors are in a better spot. It wasnâ(TM)t an easy decision but it really feels like the best option we have given the current situation. If youâ(TM)re desperate for a way to patch your browser from the issue disable scripting and plugins for the time being. More to come.
This entry was posted on Monday, September 15th, 2008 at 5:36 pm and is filed under Webappsec. You can leave a response as well.
And from the Adobe report:
Thanks to Jeremiah Grossman and Robert "RSnake" Hansen
Robert âoeRSnakeâ Hansen and Jeremiah Grossman recently shared with us some information they were planning to include in an upcoming presentation at the OWASP NYC AppSec confer
The devil is in the details (Score:5, Informative)
In its most primitive form, it basically involves taking an iframe, figuring out where the link part/form part is, and then tricking the user into clicking it.
This seems very clunky and hacky, but I suspect that the speakers at the OWASP talk have gotten this technique to work well enough so that it is both transparent and highly effective. Can you think of a website that needs you to click, say, a play button in order to view content? That click may be hijacked through an invisible iframe to execute an action on another website.
The good folks at Google recently raised this topic on the WHATWG mailing list, you can read more about it here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016284.html [whatwg.org]
Re:Hurray for us lynx users! (Score:4, Informative)
Re:Summary wrong (Score:3, Informative)
What you do is you see an unknown charge on your credit card, call the company, cancel the card, and get a new one. Total cost to you: 15 minutes and zero dollars.
Honestly, why are people so afraid of having their credit card numbers stolen? Unless you're utterly negligent and don't report fraudulent purchases, you have no liability!
Re:Summary wrong (Score:3, Informative)
Actually under certain circumstances you could be liable for up to $50, but yeah usually it's not a big deal.
Re:Summary wrong (Score:3, Informative)
I'm pretty sure that's only if your actual signature is on a receipt somewhere, which is fairly difficult to arrange when your number gets stolen over the internet.
Comment removed (Score:3, Informative)
Re:One of these things is not like the other. (Score:1, Informative)
I followed TFA and sure enough, after loading the demo ( http://raffon.net/research/flash/cb/test.html ), I found http://www.evil.com in my clipboard.
Woohoo! Give it a try, it's fun!
Re:Hurray for us lynx users! (Score:5, Informative)
I didn't RTFA, so I don't know how appropriate this term is.
Don't worry, you didn't miss anything. The article basically says, "OMG WE ARE ALL SO PWNED!!111. But we're not going to tell you why."
Re:Bullshit? (Score:3, Informative)
I too was initially tempted to call bullshit but it seems that (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016284.html) it's the real deal. Worrying but not something over which to lose too much sleep, yet!, since finding the exploit is the problem.