The online version of Technology Review today carries a story I wrote about a government funded research group that is preparing to release a new free tool designed to block “drive-by downloads,” attacks in which the mere act of visiting a hacked or malicious Web site results in the installation of an unwanted program, usually without the visitor’s consent or knowledge.
The story delves into greater detail about the as yet unreleased software, called “BLADE,” (short for Block All Drive-By Download Exploits). That piece, which explores some of the unique approaches and limitations of this tool, is available at this link here.
As I note in the story, nearly all of the sites that foist these drive-by attacks have been retrofitted with what are known as “exploit packs,” or software kits designed to probe the visitor’s browser for known security vulnerabilities. Last month, I shared with readers a peek inside the Web administration panel for the Eleonore exploit pack — one of the most popular at the moment.
The BLADE research group has been running their virtual test machines through sites infected with Eleonore and a variety of other exploit packs, and their findings reinforce the point I was trying to make with that blog post: That attackers increasingly care less about the browser you’re using; rather, their attacks tend to focus on the outdated plugins you may have installed.
Phil Porras, program director for SRI International — one of the research groups involved in the project — says that so far none of the exploit sites have been able to get past BLADE, which acts as a kind of sandbox for the browser that prevents bad stuff from being written to the hard drive. Yet, because the tool allows the exploit but blocks the installation of the malicious payload, the group has been able to collect a great deal of interesting stats about the attacks, such as which browsers were most often attacked, which browser plugins were most-targeted, and so on.
The following graphs were taken from the latest version of BLADE’s evaluation lab, which is constantly updated with results from new exploit sites. The charts below show the breakdown from 5,154 drive-by download infections blocked by BLADE.
Here are the vulnerable applications that were most targeted in the drive-by attacks the BLADE group saw:
We can see the BLADE team found that the Eleonore exploit kit was among the most used to infect sites:
Researchers also found lackluster detection of the exploits by the industry’s top anti-virus products (Porras said the data below is an average of the detection rates for each malicious binary delivered by the exploit sites):
I’ll be sure to let readers know when this tool is publicly available for download.
I’ll be interested to see how the tool alerts on what is being downloaded. Not to rain on what appears to be a very good idea, but I would think that it would be defeated through social engineering if it incorporated any information from the download (like a filename) into the alert.
What I find particularly noteworthy is the frequency of AV detection failures. I expect that the problem is that AV tools need to wait until the browser has completed the download to scan it. By the time that has happened, it has probably already exploited the system. Being able to sandbox any downloads would be great if then the sandbox interfaced with the AV tools to help determine risk to the system.
Lastly, Brian, why is “robert hansen” tagged in this one? I didn’t see anything about domestic spying in this posting, so am I missing something?
If you’re interested, I’d encourage you to read the MIT Technology Review article I linked to in the second paragraph of this piece. It explains that this BLADE tool is in no way designed to block social engineering attacks. It also doesn’t do anything to block in-memory-only attacks.
Yeah, I caught that in the article (sorry to rib on the Hansen tag…it’s really an unfortunately surname for a security guy!).
To clarify my point, users are already inundated with pop-ups that tell them that some program is trying to do something that may or may not be bad, and they’ve gotten used to simply clicking “OK” to move forward.
I know that I’ll probably regret saying this, but it seems that the most effective way for this type of function would be to just run in the browser background (like a pop-up blocker), perhaps accompanied by a little note to say that something was blocked that doesn’t appear to be necessary.
RE: Hansen, I had originally started writing the story that appeared in the MIT Technology Review article as a blog post for Krebsonsecurity. Then, I considered that they might be interested, pitched it, and they were. I will remove that tag from this post. He’s quoted in the TR story.
I should congratulate you on getting the article accepted. As an alum Tech Review subscriber, I’m pleased to know that TR continues to attract quality contributors.
Any chance on putting together a current list of articles that you’ve published? I know that you have your pre-2010 articles listed, but I know that many of us would like to see your newer stuff too.
Great Idea, Can’t wait to try it out.
Thanks for keeping us infromed.
Brian, am I correct in understanding that these particular vulnerabilities are limited to boxes running Windows ? Or have similar «drive-by downloads» targeting other OS, e g, Linux, Mac, etc, been seen by the BLADE-project team ?…
I’m not aware of drive-by attacks designed to run on other OSes aside from Windows. That doesn’t mean they don’t exist: just saying I haven’t see or heard of any.
Thanks for the clarification, Brian !…
There are no Mac-based drive by attacks. Period. There have been numerous attempts to corrupt Macs but they’ve relied on social engineering and not worked on system weaknesses.
The MOAB crew found some configuration errors on Mac OS X for January 2007 but these weren’t system weaknesses. And it was difficult to see how such holes could be propagated anyway.
We wrote an article series on how one could conceivably create a malware outbreak for the Mac but such an outbreak could not by default harm the system itself.
Apple use a rather annoying quarantine system today. It’s based on the tenet that anything downloaded off the net is suspicious. Files get marked with a special extended attribute so you get an ‘are you sure’ prompt the first time you access them. It’s not foolproof but it helps. Not that there are many funky files coming a Mac user’s way but still and all.
Targeting Macs ‘en masse’ as with targeting BSD or Linux boxes ‘en masse’ is just too difficult. You can footprint a single organisation and find a way in to a single network but it’s hard to find something that can be automated to work everywhere.
Apple have had two really good configuration holes over the years. Opener and Oompa Loompa. (The system login items hole was a variant on the Opener hole.) The latter was cute code but not really that harmful; the author of the former called the hole in the OS not so much a hole as a crater; and it took Apple several years to plug it. But after that things have been basically smooth sailing as the basic Unix security model holds – it’s just when they get frisky about adding ‘features’ and ‘doodads’ that marketing invariably don’t want to wait to test properly that things can go bad.
So the short answer should be ‘no’. 😉
Couldn’t help but notice that the only browsers listed were IE and Firefox. Does this mean that some browsers like Google Chrome and Apple’s Safari aren’t subject to these exploits?
Or more likely – the sandbox didn’t test these browsers?
I don’t think the Blade group looked at or tested the other browsers. I hate to keep referring people back to the links in the post above, but if you check out the blog post I wrote about the Eleonore exploit kit, and see the breakdowns among browsers listed there, that suggests at least some of these exploit kits are hitting Opera and Safari, among others.
What happens with the browser isn’t that important. You’re basing all your hopes on a 100% bug-free application of a type that by its very nature is always going to be crash prone. (Random data gets tossed at it all the time.) Your concern should be what happens if someone discovers YABB (yet another browser bug). What can they in such case do? If they can’t break into the local machine and accomplish anything there, or if the damage is strictly contained/quarantined, then you have fewer worries. It’s a lot easier and it’s a lot more important to secure the local system first.
We’re going to need this, because something is suddenly blowing past Vista’s “security.”
I’ve seen about a dozen infested Vista machines in the last three years. Today, I had three.
What would be the difference (if any) with for example http://www.sandboxie.com? Sandboxie is more or less a mature sandbox product that work not only for browsers but 4 other apps. Thanks as always.
Indeed, this is very usefull. I hope the BLADE developers will not just stop malware (drive-by-downloads) but catch them (in a quarantined container) so that IT security can analyzed and send them to AV solution for analysis.
Sorry but i’ve missed the point, how exactly does this work? Does it block the files and website at the URL level? If so how does it do it, referencing an online database?
Have you read the MIT Technology Review article that this blog post is about? If not, start there. If you still don’t get it, come back here.
From the article and the last line it looks like this tool detects and removes malware written to the hard drive. So that means it’s based on definition files and heuristics, similar to AV. Is this correct? Please confirm.
From the article and the last line it looks like this tool detects and removes malware written to the hard drive. So that means it’s based on definition files and heuristics, similar to AV. Is this correct?
That’s incorrect, Vincent. The whole point of BLADE is to block exploits so that malware cannot be written to the hard drive. It does nothing to remove malware.
As I mentioned to several folks who asked questions, please consider reading the MIT Tech Review article linked to at the top of this story for more on the technical details of how this works.
Have you looked into the growing problem of ad networks distributing drive by attacks into trusted web sites? This seems to be happening more and more often. The latest published example:
Interesting stats that Firefox 3 has almost as high an infection rate as IE8 (my browser of choice). I’ve long contemplated switching to Firefox (with no script) as my main browser. But, these stats lead me to think there may not be a real benefit to switching. I also wonder if there is a false sense of security by some that choose to use Firefox. They may not be using a defense in depth strategy to begin with which puts them at high risk regardless of browser.
Although one could argue using Firefox with no script adds another layer of defense, I feel comfortable using IE8 with a blocking hosts file as it works at the OS level blocking a plethora of known malicious websites. So it works regardless of what application I’m using to access the Internet.
Part of my struggle in deciding too is my very strict rule of limiting what software is installed. I don’t like the idea of having two browsers to have to maintain with their related plug-ins and such.
What do you say gets infected in Firefox? Are you talking about the browser thwarting attacks? Why does that matter at all?
The stats of applications targeted also confirm why many escew the likes of Java and Adobe Reader. Personally, I refuse to install either on any of my systems while using Foxit Reader as an alternative PDF reader.
It should also be pointed out how the AV detection stats drive home the fact that AV is NOT going to prevent most malware these days and should NOT be considered a primary or (gasp) only defense. To do so is foolhardy. And why many people still fall victim to malware. That and running as a full admin!
Admin can be dangerous on any system because admin accounts can achieve further privilege escalation. But that’s not quite the same thing as admin on Windows. Admin on Windows essentially becomes the equivalent of root on any other system. Nobody on Unix runs online as root. OK there was that flaky uni in New England that did it but they’re the exception (and they got slapped good and proper).
SRI – good people. PG Neumann’s got quite the pedigree.
BLADE might be released as a ‘free tool’ but the white paper describing how it works is anything but free – they want $25 for an electronic download.
‘BLADE’s approach is to intercept and impose ‘execution prevention’ of all downloaded content that has not been directly consented to by user-to-browser interaction.’
Yep yep yep! That’s essentially the Apple quarantine idea taken down to kernel level – that seems to be a Good Idea™.
For the past year, I have seen various industry analyses report the lack of effectiveness of AV products detecting zero-day exploits and new threats generally stating a miss rate of between 30 and 60%.
Every AV provider I deal with states their product has an effectiveness of between 99 -100%.
Is there any information out there that enables me to rank AV products on their ability to deal with zero day exploits and “new” threats
Joe, you may, as I do, find ShadowServer’s (http://preview.tinyurl.com/yetkdb4 ) statistics of use in dealing with those exaggerated claims. I tend to concentrate on the Virus Monthly Stats rather than with the daily counterparts, in order to average out fluctuations….
I recommend that you try out Sandboxie. Great for malware analysis
There are some tests of AV effectiveness against various sorts of not-strictly-virus malware. For example, av-comparitives does look at things like effectiveness against trojans in their main AV reports: http://www.av-comparatives.org/comparativesreviews/main-tests
Executive summary: no tested product managed to catch 60% of trojans.
Obviously, we need to move beyond pattern-matching alone, and use more heuristic (and other) methods of detection and prevention. How interesting BLADE might be as an additional security layer will depend on the (still unavailable) details, e.g., source code and binary licensing terms.