InformAction Forums

@Giorgio:
Tom brought the following post to our attention here in the SPYWARE BUNDLE! topic: http://forums.informaction.com/viewtopi ... 699#p14699

Popup & Focus URL Hijacking ha.ckers.org web application security lab

I ran the demo in my sandboxed test profile. I'm amazed to discover that the resulting page has https://addons.mozilla.org/en-US/firefox/addon/722 in the location bar, while having content served from a different site linked in the notification bar (the one with the Allow button). I thought Firefox was supposed to prevent a site from rewriting the location bar. Is Mozilla aware of this vulnerability?

(Yeah, I realize I had to get there by clicking on a malicious link and overlook the ha.ckers.org in the actual download links, but the location bar points to a trusted site. That's where most users are trained to look.)

You would have to allow scripting not only from AMO, but also from the (evil) host site, e. g., ha.ckers.org or badsite.com, which is something of a mitigator -- all I got was the usual blank page with three JS links and a placeholder. But if you unknowingly allow an evil site, it works. So I should have brought the point up here as well. Thanks for doing so.

I filed a bug. Bug 537119 – Changing the location of the opened window does not change the location bar properly

Wow.
I just looked at the demo in a fresh Firefox 3.5.6, and sure enough - it tried installing "NoScript" on my computer. Of course, the "Do you want to allow ha.ckers.org to install software on your computer" bar prevented an actual installation, but most users probably wouldn't give it a second thought, especially for an addon as well-known and trusted as NoScript.

The mechanics of the attack are incredibly simple, too. (The demo's JavaScript is all inline, so I had no trouble seeing what was being done)
The attack tells a site, such as addons.mozilla.org, to load. Then it waits 2 seconds and redirects the window via the Window.Location property; apparently Firefox fails to update the Address Bar to match the new site. Not sure if this is a bug or by design, but either way it's a bad deal...

I just realized that the first-time d/l of NS (as opposed to updates) is a "perfect" target for exploitation - because by definition, these users don't have the very tool that would stop the exploit: NoScript. I'll add that to RSnake's blog comments. This may become widespread, given that any black-hat worth his salt reads RSnake's blog.

Looking forward to Alan's updates on his bug report -- which was very well-written, btw, with links to RSnake, and already reproduced by several other Moz-ers.

Edit: Comment above has been posted to RSnake's blog.

Oops. I screwed up and accidentally deleted computerfreaker's post here.

Here's computerfreaker's report about this in the MozillaZine forum. It's similar to the one I accidentally deleted. Looks like Philip fixed the problem right away.

JSView 2.0.5-mod for SeaMonkey 2.0+ and Firefox 3.5+ • mozillaZine Forums

Philip Chee wrote:

computerfreaker wrote:Bug #2: Opening an embedded script from Tools -> Page Info -> Scripts doesn't actually open the embedded script - it opens the source for hxxp://www.undefined.com (link protocol changed in case the site's malicious; it doesn't appear to be, but I don't know for sure) instead. It looks like JSView tries to set an object to a certain JS file on the server; since the JS file isn't there, the object becomes undefined. Then, JSView tries opening the URL specified by the object; since the object is undefined, JSView opens the source for hxxp://www.undefined.com instead.

Sigh. It was a braino on my part. I thought I'd simplify some needlessly convoluted code. Unfortunately there was a subtle reason why Ron did it this way, so I broke embedded scripts.

Updated the XPI yet again:
http://downloads.mozdev.org/xsidebar/mo ... .5-mod.xpi

Phil

Alan Baxter wrote:Oops. I screwed up and accidentally deleted computerfreaker's post here.

No problem, I'll just rewrite it.


I found an even weirder example of this "hijacking" right here. It has nothing to do with InformAction, btw, and can (and does) happen on any site.

* Go to http://forums.informaction.com/viewtopi ... =18&t=3638, the topic where the JSView mod is being discussed.
* Right-click the jsview-2.0.5-mod.xpi link and hit "Open in new tab"
* As expected, Firefox blocks the installation. However, it says that it prevented an installation from forums.informaction.com, not mozdev.org!
* Allow the installation. Firefox installs the JSView mod from become.com.

At this point, we have 3 different links: InformAction, which links to the mod; mozdev.org, which seems to be hosting the mod; and become.com, which is where the mod is actually hosted.


This is a bit scary; at first, I couldn't think of a good attack scenario but this one just occurred to me.
* Attacker at badsite.com creates a malware Fx addon
* Attacker goes to some well-known site (say, goodsite.com) and posts, saying "hey, look at this great addon and what it can do!"; he links directly to the xpi
* Unsuspecting visitor clicks the link and is prompted to allow the installation from goodsite.com
* Unsuspecting visitor clicks "Allow"
* Malware addon is downloaded from badsite.com
* Congratulations, unsuspecting visitor, your PC is compromised.


Still running Fx 3.5.7, if that makes a difference; I haven't tried 3.6 yet to see if the problem's been resolved. Any 3.6 users want to comment?

Update: I just updated to Fx 3.6 and tried it again - it still asks for a installation confirmation for the site the link was on. This isn't InformAction-specific, either, as I received a similar prompt on the MozillaZine forums - "Allow installation from forums.mozillazine.org" instead of the true host.
There could be some serious repercussions over this...

It may be caused by the same bug we discussed previously in this topic. Bug 537119 – navigating an opened window to an XPI (using e.g. w.document.location='foo.xpi') doesn't clear out location bar or page contents. I've added the scenario you discovered in comment 10.

Alan Baxter wrote:It may be caused by the same bug we discussed previously in this topic. Bug 537119 – navigating an opened window to an XPI (using e.g. w.document.location='foo.xpi') doesn't clear out location bar or page contents. I've added the scenario you discovered in comment 10.

Thanks for commenting on that Bugzilla report; I'm not a Bugzilla member so I couldn't do it. (Don't want to register there, either)

From the old (this comment is from 2004) Bugzilla thread Gavin pointed you to,

The whitelist is intended to cover the sites *initiating* the install request, not hosting the .xpi itself. The confirmation dialog shows the source of the .xpi at which point the user could decide if they trust that server.

Is that truly such a good idea, do you think? I can't imagine why anyone would want to know the site *initiating* the install request, but everyone wants to know what site the xpi is coming from... Sure, the "Confirm install" box shows where the xpi is coming from, but I seriously question how many people actually read that dialog. After all, they clicked on the xpi link, so they know where it's coming from, right? Just what an attacker wants... and yet another computer joins the millions of zombie machines out there.

I agree with you completely, but I'm not going to beat my head against a wall trying to get Mozilla to agree. I think the Mozilla stance is that you can safely install extensions only from addons.mozilla.org, not from links posted by TrustMe-Really at "myfavoritetrustedtechboard.com".

I have gotten some of my extensions from other sites, including the JSView 2.0.5 mod, which apparently is actually hosted on opensource.become.com. I downloaded it before installing and never had an opportunity to see opensource.become.com. In this case I trusted Philip.

Alan Baxter wrote:I agree with you completely, but I'm not going to beat my head against a wall trying to get Mozilla to agree. I think the Mozilla stance is that you can safely install extensions only from addons.mozilla.org, not from links posted by TrustMe-Really at "myfavoritetrustedtechboard.com".

meh.
Mozilla, IMHO, just wants people to use AMO so they can show off big download numbers...

Alan Baxter wrote:I have gotten some of my extensions from other sites, including the JSView 2.0.5 mod, which apparently is actually hosted on opensource.become.com.

The JSView mod was only the 2nd addon I have gotten outside of AMO; the first was NoScript.

Alan Baxter wrote:I downloaded it before installing and never had an opportunity to see opensource.become.com. In this case I trusted Philip.

yep, I trusted him too.
However, there's a lot of people who click any link that says "Click here!", any link that says "Download me", or any link leading to "free stuff" - "free" exploits, perhaps.
I swear some people are brainless when it comes to computers...

I've tried, and the popup says:
Firefox prevented this site (mozdev.mirror.digionline.de) from asking you to install software on your computer.

The server (mozdev.mirror) changes if I retry, but firefox doesn't show forums.informaction.com as download link.

I have Request Policy also

anthoy wrote:I've tried, and the popup says:
Firefox prevented this site (mozdev.mirror.digionline.de) from asking you to install software on your computer.

The server (mozdev.mirror) changes if I retry, but firefox doesn't show forums.informaction.com as download link.

I have Request Policy also

If you disable RequestPolicy, does that change?