Finally Mozilla will work to d(r)efine their definition

Today I got mail form Mozilla:
We will work with RSnake and Jeremiah to refine our definition of Clickjacking. Thank-you. - -Dan Veditz Mozilla Security Team
- -Dan Veditz
Mozilla Security Team

This was regarding my last mail to Mozilla in which I had sent an Advisory to Mozilla about the Clickjacking. But as always there was again slight differences between mine and their definition of Clickjacking.Then I verified the case with none other than RSnake and Jeremiah, who replied me:
RSnake’s Response:
-----Original Message-----From: RSnake [mailto:h@ckers.org] Sent: Wednesday, February 18, 2009 4:18 AMTo: Nilesh Kumar (India)Subject: Re: Clickjacking
Answers inline.
Nilesh Kumar (India) wrote:> Hi RSnake!> Thanks for quick response. I want your kind help regarding it a bit> more.>> I agree with your theory. But I want your comments regarding all the> three specific cases I have described.>> Case 1. Used a frame to load a website in background and overlapped an> invisible div tag exactly over the button to be clicked. So user can see> the legitimate button in the background and clicks it whereas he> actually clicks invisible div tag over it and get redirected to another> malicious site.>>
Yes, this is one form of clickjacking.
And this is what Jeremiah says via LinkedIn mail:

On 02/18/09 7:51 AM, Jeremiah Grossman wrote:--------------------Case 1 most closely resembles Clickjacking. The following white paper will have more details and diagrams.
http://www.sectheory.com/clickjacking.htm
I forwarded the responses to Mozilla and finally they are again verifying their facts.Thanks to RSnake and Jeremiah for their encouraging words!

MIME Sniffing in IE

Today I was going through an interesting article. It was about executing XSS through uploading an image hiding script in it. This is not new and has been out there for quite some time. But IE handles it less responsibly whereas FF and Opera simply prints the URL and broken image respectively instead of executing the script.
For example, in Google Page Creator , there is an upload section which can be used to upload image file or say files with only .jpg,.bmp,.png extensions. But hiding a script inside an image file with valid extension (.jpg) gets uploaded successfully and gets executed....but only in IE not otherwise. This might me an expected behavior of Google pages but the point is the way IE handles it.
Few months ago before publishing of this article, I and my colleague Chintan had found it and discussed about it. That gave a strike to my mind today while reading the article on Owasp, that this we are already familiar with.
Anyways the article could be read on http://www.rorsecurity.info/journal/2009/2/11/mime-sniffing-in-ie-enables-xss-attacks.html

Hi ClearClick! Good bye Clickjacking?

Javascript is not necessarily needed to execute Clickjacking.JavaScript might make the attacker’s life easier, but it’s not inevitable to make the attack. Alternatively the attacker can use frame tags to load any site of their choice in the background and using another div tag redirect the user to any other site of choice. No role of Javascript here. Mitigation? Don't load frame in your browser in any case. all it takes is including this piece of javascript in your page:


This works in most browsers, with Internet Explorer being a notable exception.
IE8 comes with another new technique.The fix is actually very simple: it lets website owners include an extra tag in their pages that tells Internet Explorer the page is not supposed to be included in a frame. It’s called X-FRAME-OPTIONS;
a value of DENY means the page should never be opened in a frame, and
SAMEORIGIN only allows it to be framed within pages from the same site.
Any other use will show a warning, and a link that opens the page in a
new screen.
There are efforts to make Firefox too compatible to it .

But for the time being, Firefox users can use the a plug in ClearClick by NoScript.
Default protections that NoScript has provided for a long time, i.e. JavaScript and plugin blocking can prevent most clickjacking attacks. In older version, though, to be 100% protected against Clickjacking you needed to enable the Forbid IFRAME and possibly Apply these restrictions to trusted sites as well NoScript options.
Fortunately, since version 1.8.2, NoScript provides a new default kind of protection called ClearClick, which defeats clickjacking no matter if you block frames or not . Even better, ClearClick can protect you from Clickjacking / UI-redressing attack independently from JavaScript and plugins blocking: you can even Allow scripts globally (which is not recommended anyway), and your ClearClick still works.

Clickjacking hides or displaces or partially covers something you wouldn't want to click, if you could see it in its original context. ClearClick does the opposite: whenever you click a plugin object or a framed page, it takes a screenshot of it alone and opaque (i.e. an image of it with no transparencies and no overlaying objects), then compares it with a screenshot of the parent page as you can see it. If the two images differ, a clickjacking attack is probably happening and NoScript raises a "ClearClick warning",

More mist around Clickjacking :)

The more I read, the more theories I get on the topic. Everybody has his own theories about Clickjacking.There's no consensus on the issue. Clickjacking for one is URL rewriting for another,simple hyperlink jump for another. Even there are contradiction by the people on Aditya's PoC on clickjacking in Chrome browser. Even on Hackademix.net Giorgio Maone has took the PoC lilghtly. That again increased the mist around the issue.
Then what is the real clickjacking? In facts, with "Clickjacking" we designate a class of attacks (also known as "UI Redressing") which consist in hiding or disguising an user interface element from a site you trust in a way which leads you to click it without knowledge of what you're exactly doing.
That's what Aditya showed in his PoC. When you click the link you are redirected to another site of attackes' choice without knowledge of users. When hovering the mouse over link it shows the intended name of the site, there's no way of doubt but clicking it once takes user to another site.
Google accepted it,others not accepting it.
Mozilla assumes it as URL rewriting via onClick event handler. I wrote back to Mozilla:

Dear Mozilla Team,

Thanks for the quick response.

Regarding the first example (click.html) I have sent , the exploit is not the issue but the browser executes the exploit is the real issue.Google has accepted the exploit being executed in their chrome browser as vulnerable to clickjacking ( you might have gone through several articles regarding it).

I used the same exploit to test with your latest Firefox 3.1 beta 2, I found that it’s executing successfully. I used same exploit with Opera 9.63 and was executing in that browser.
That’s why I brought it in your notice.
Anyways everyone has his own theory. I am not claiming myself to be expert on the issue but as Mozilla said to me:

"Clickjacking is when a user clicks on what they think is a button on a random site (i.e. attacker's site in the URL bar) but they are actually clicking buttons on another site like their bank without realizing it."


And in my second example I did same thing. I used iframe to load Google.com and exactly over the search button using div tag I loaded a blank invisible transparent frame. Clicking on 'search' button user is actually clicking on the 'invisible frame' and gets redirected to another malicious site. That confirms Mozilla's aforementioned definition above. This is an example of Graphic Overlaying Clickjacking. There's no need of using Javascript to execute it. So even 'NoScript' Plugin won't mitigate it. Only thing that can prevent it is Frame Busitng codes that will prevent loading any frame in the web page at all!

But again I am getting different theories from different vendors about clickjacking. So I will now just sit back and wait for the final concluding clickjacking definition and then only go for further research.

Clickjacking in Mozilla Firefox 3.1(b2)

I discovered that the latest Mozilla Firefox 3.1 which is in beta phase is susceptible to Clickjacking Attack. I conducted the test using two mechanisms,first was using iframe tag in background and div tag,
second was using mouse event handling function.
In the first kind of attack, attacker can load any website in background and places a button exact above any button on website in background. Now social engineering comes into scene.Clicking the button created by the attacker actually fires the button exactly beneath it which user can't see. Thus user is performing two actions at a time.
In the second kind of attack a link is provided to user directing to any well known website,even address bar of the browser will show the link of the well known website, but clicking it will lead user to any malicious site crafted by attacker. So the user will be clicking on attackers' link rather than his known link.
I contacted Mozilla with the issue in their latest product showed how it happens. I also pointed them in support of my claim that the attacks are not possible in updated Opera 9.63. Since the product is in beta phase their efforts are to make the thing safe.
Mozilla says:

Hello Nilesh,

Thank you for contacting us with this information. We are currently tracking it regarding clickjacking and we are investigating various strategies for mitigating this type of attack. Should any questions arise regarding the material you provided, we will certainly contact you.

Best regards,

Brandon Sterne

Mozilla Security Group

Good afternoon from Google's Security Team

At last Google responded to my two queries today. I have been receiving a lot of mails from them but this one is substantial.
First was in response with the issue I once arose with Yahoo also and second one was in response with my advisory written to Google. They say that once Hackers.org has also posted something like this in their blog. Some where they nearly accepts the things and some where underestimate as n non security issue. But I think..Security or Non security issue the implementation is wrong.Anyways I am happy they have given some reasonable answer.

Hi Nilesh,

Hope all is well with you. Chris here from Google's Security Team. A colleague of mine pointed out you have reported various security issues to us recently. Thank you very much for taking the time to do that, and I wanted to let you know where they stand.

1) Logout XSRF.
We will continue to track this, but as a low priority.
Unfortunately, logout XSRF is kind of endemic to the way the web works. For example, there's an attack you could term "cookie stuffing" whereby bombarding the victim's browser will knock out cookies for authenticated sites and effectively log the user out. There are other attacks that make it of questionable benefit to address this on Google's end.

2) Images redirector
Your report appears to be similar to a 2008 public discussed thread that we are tracking:
http://ha.ckers.org/blog/20080716/redirection-report/
The simple version is clearly framed as an external-to-Google result, but the powerful twist is having a child iframe use Javascript to change the location of the top frame. This situation needs new iframe option support in the major browsers, which we're starting to see a move towards.
We always monitor for redirector abuse and will act if we see any prior to the browser makers fixing up their model in this area.

Good mindset though, we appreciate it!

Cheers,
Chris, Google Security Team