BLADE: New Tool for Stopping Stealthy Downloads

Researchers at SRI International and Georgia Tech are preparing to release a free tool to stop "drive-by" downloads:
http://djtechnocrat.blogspot.com/2010/02/blade-new-tool-for-stopping-stealthy.html

 

Sounds good, and for most users out there it could a real blessing, and long overdue. Look forward to testing it when it's released. Thanks for the heads up as i know lots of people who could use it

Wonder what Rmus would have to say ?

 

Hmmm..... drive-bys.

I always thought that with Windows Vista and & and IE 7 and 8, esp with updated OS, drive-bys are almost an old story. Am I true?

 

No, because we still have zero-day exploit and exploit against application like PDF reader's, flash, java, etc. People who don't read security forums will still suffer from these attack.

/Jesper

 

I looked through the article but did not notice an official web address for the BLADE tool. Does anyone know the web address of BLADE?

Thanks in Advance.

 

Blade-defender.org. Sounds very interesting and looking forward to it's release. Rogue av programs (which are almost always drive-by) are the number one problem I have with protecting my clients these days, almost daily I get a call about one of them.

 

Not sure if that's supposed to be a recommendation

 

Hi aigle,

I would say yes! But unfortunately, something's not working right, since these types of attacks are still occuring - Google is the latest, most sensational.

It's even more puzzling, since drive-by protection has been available for at least 9-1/2 years. Here is a partial lineup from the early years:

• 2001
  Windows XP Pro: Software Restriction Policies
  
  
• 2003
  Abtrusion detector
  
  
• 2004
  DiamondCS ProcessGuard
  
  
• 2005
  Faronics FreezeX - later becomes Anti-Executable

So now, we have another entry into the Drive-by prevention market: BLADE. The rationale for the product is explained here:

Stopping Stealthy Downloads
http://www.technologyreview.com/computing/24632/page1/

Someone asked me a few days ago about the distinction, so in case others might not be sure about this, here is an example.

By default, Browsers have the download option for EXE files set to Prompt, so that an executable file can't run/install accidently if someone clicks on a direct download link, as I did here:

​

However, a vulnerability can be exploited to bypass the download prompt, resulting in being infected with malware.

It became evident to me after Process Guard was released that this type of exploit should be the easiest of all types to prevent. So, I asked fcukdat (Ade Gill, now Malwarebytes Researcher) who uses ProcessGuard, and SpikeyB who uses Software Restriction Policies (SRP) to test such an exploit. Here it is - an old Internet Explorer 6 vulnerability:

​

• The first line calls the download: it is an executable disguised as an HTM file
  
• The 2nd line is the CLSID (identification #)for the ActiveX component used to bypass the download prompt
  
• The 3rd line establishes a new filename for the malware executable: svchost.exe
  
• The 4th line sets the path for the executable: the TMP folder
  
• The 5th line executes svchost.exe from the TMP folder

sans.org explained how the CLSID identified the exploit:

http://isc.sans.org/diary.html?storyid=3324

That was in 2007, a year after the vulnerability had been patched. Today it is still included in cybercriminals' "toolkits."

By the way, it shouldn't be lost on those who keep up with such stuff that one of the exploits that targeted Google was an Internet Explorer 6 zero-day (unpatched) exploit.

Back to the other one: This was a live URL at the time, and when SpikeyB went to it, the exploit code worked and svchost.exe attempted to execute, but his SRP prevented it from running:

​

Likewise, with ProcessGuard:

​

It looks like we can assume that BLADE would also have stopped this exploit. From the BLADE web site:

It hasn't been released yet, so we don't know how it works.

By the way, in addition to ProcessGuard and SRP, I tested Anti-Executable, and aigle tested the following, all of which successfully stopped the above exploit"

• threatfire
  
• Online Armor
  
• neoavaguard
  
• geswall
  
• comodo
  
• safespace

Since that time, many other products have incorporated some type of Execution Protection. With this in mind, why, do you suppose, these drive-by exploits continue to be successful, especially against organizations? Wouldn't you think that they would be aware of this type of protection?

----
rich

 

I was referring to operating system,s own ability to stop these drive bys as I suppose such vulnerabilities to be rare with Win vita and WIn 7 and latest IE).

 

http://www.bothunter.net/

 

For sure. And my point about "something not working right" pertains to the people running the organizations.

For example:

1) Many including Google still use IE6.

2) Those organizations which have been successfully targeted do not have a policy whereby the workstations are locked down to permit only company-approved software to be installed. Thus, they are prone to the sneak attack.

If such a policy were strictly enforced, it would eliminate the Drive-by attack, no matter the OS/browser.

Regarding vulnerabilities being rare with Win Vista/7, you can say the same thing about WinXP, if SRP is properly configured.

If a Win Vista/7 user disables UAC or doesn't configure AppLocker correctly, or runs as Administrator, then that user would be just as vulnerable as someone using WinXP, don't you think? This assumes no other protection in place.

Regarding IE8 - how would you configure it to not be vulnerable to PDF exploits, which are not browser-specific? Is it as easy in IE8 as is in Opera and Firefox to disable the PDF Plugin, for example?

thanks,

-rich

 

You are right about browser plugins. I was just referring to browser drive-by downloads mainly.

 

Understood. I mentioned them because the articles about BLADE emphasize that they are equally expoited along with browser exploits:

Stopping Stealthy Downloads
http://www.technologyreview.com/computing/24632/page1/

Also from an article posted by MrBrian in another thread:

Report: Malicious PDF files comprised 80 percent of all exploits for 2009
http://blogs.zdnet.com/security/?p=5473

Ironically, the security built into the Operating Systems (SRP, UAC, AppLocker), while not preventing the exploit code in the PDF file from retrieving a malicious executable file, do block that file from installing, or limit the damage done by that file, depending on how the OS security is configured.

----
rich

 

ASLR is a feature not found in XP and blocks some types of attacks since it makes it more difficult for malware to predict target addresses in memory. On 64-bit Vista/Win7 systems Patchguard and KMCS also contribute to raising the bar higher for malware (although they can be hurdled with greater effort). If it's more difficult to write malware for Vista/Win7, wouldn't that make them at least a little less vulnerable than XP?

I understand your point that there is often a trade-off between security and convenience for organizations, and these trade-offs have consequences.

 

Your implication is that the malware does execute, but can't do what it wants to.

But since the thread is talking about drive-by downloads, the malware is blocked from executing with SRP on WinXP PRO. Therefore, isn't WinXP PRO just as robust against the drive-by download as the later versions of the OS.

Again, regarding Drive-by downloads, shouldn't they be equal?

They certainly do! It's a big headache for organizations, because over the years, employees have come to expect much freedom in how they use their work computer, as if it were their personal computer!

Another big problem is that many employees travel with a company laptop computer. Do they need Administrative rights for that computer while on the road?

----
rich

 

If SRP could protect a system 100%. But there are some ways that malware can compromise a system that SRP cannot protect against, even given the specific context assumed here. Or am I missing something?

 

I'm not sure what ways you are referring to -- any examples?

Using the criteria set forth in the BLADE evaluation tests: their URLs all had exploit code that attempted to download a binary executable file.

While I cannot guarantee SRP as protecting 100%, in the cases of a binary executable payload, each drive-by exploit that I had someone test some years ago was effectively prevented from executing the payload.

As I indicated earlier, many proven solutions already exist against this type of exploit, so BLADE will be joining a select group!

Does anyone think it will make a dent in the cybercriminals' sucessful use of the drive-by download?

Microsoft literally begged and cajoled people to install the patch for the vulnerability that eventually Conficker exploited.

Microsoft NHS Resource Centre
Posted on 06 February 2009
http://www.microsoft.com/uk/nhs/content/articles/sidewinder-does-some-patch-work.aspx

Most of these 9 million are not likely to be interested, or even know about, the types of security solutions that are being discussed here! Many of these 9 million, by some estimates, were workstations in networks: once installed in a workstation, an exploit quickly spreads throughout the network.

To help home users -- if those who know about preventative measures that are being discussed here can get the word out, think how many fewer victims of drive-by exploits there would be!

New products are nice -- we had AppGuard a while back. Enthusiasm seems to have died down. Will the same thing be true of BLADE? Will it make any difference?

Only if the word reaches beyond the core niche of followers that usually springs up on security forums.

More action, less talk is needed. People have been talking about drive-by exploits for 10+ years, arguing over which is the best solution. Talk becomes an exercise in futility, an end unto itself for techie geeks.

The successful drive-by (remote code execution) exploits used by cybercriminals 10 years ago and today to deliver malware payloads are not complicated by any means: the standard browser exploits against IE; exploits against Plugins; USB drives planted in parking lots.

It's true that the targeting techniques are much more sophisticated, a la Aurora and the like against industries and organizations, but the delivery methods are not, and are easily prevented by simple security solutions . I quote from another thread on the TDL3 rootkit, where I commented on a blog by Marco (EraserHW , Prevx Moderator):

to which he responded,

What more needs to be said?


----
rich

 

Unless I'm mistaken, this example from MrBrian shows a simple theoretical way to potentially compromise a system even w/SRP.

Couldn't ASLR, for example, provide some added protection from this type of attack not available in XP?

 

I remember that discussion, and yes, that is a theoretical way to do that. It would require the cybercriminals to specifically target users with WinXP PRO.

Regarding the Russinovich article, note what has to happen for SRP to be compromised:

This supports my reminder in previous posts that the OS and Browsers must be properly configured for maximum security.

I'm not familiar with ASLR. Search for articles, especially Microsoft Technet.

----
rich

 

BLADE: A look at their tests

Nothing seems to cause people to break out in perspiration more than thinking of the possibility of being the victim of a drive-by download attack and infected by a trojan. Yet, they really are the easiest of exploits to prevent, as the soon-to-be-released BLADE product wants to demonstrate.

The parent company, SRI International, has compiled an impressive malware domain data base consisting of web sites with drive-by attacks using the latest and greatest exploits.

Their latest statistics:

One point that really stands out is the wide-spread use of the "exploit kit," aka "exploit pack," "tool kit," which is a collection of various exploits targeting different vulnerabilities. The cybercriminals hope to find a least one vulnerability on the potential victim's computer once ensnared on the malicious web site.

These exploit packs have been analyzed on the web by many security organizations, and I took a look at those found in the BLADE tests to get an idea of what today's victims of drive-by attacks are encountering.

But first: How does a potential victim get to one of these malicious web sites? The following describes the Google poisoning technique, now referred to as Search Engine Optimization (SEO).

Malware Intelligence Blog
http://malwareint.blogspot.com/2009/07/malware-propagation-through-blogging.html

This type of redirection usually involves landing on a site where javascript code initiates the attack.

Similar to SEO would be legitimate sites compromised with i-frame code injection which redirects the potential victim to the cybercriminal's site with drive-by code embedded.

Another method would be tricking the user into clicking on a link, either in an email, IM message, or somewhere on the web - a blog, or social networking site.

It's obvious that configuring scripting "per site" prevents many of these exploits from even starting. This takes care of the rogue antivirus exploits, where javascript calls up the files that bring the fake scan. It also takes care of most Plugin exploits, where javascript is used on the redirected site.

The use of the exploit kits being so widespread, I looked at some of the descriptions. They are very revealing, not only for how they work, but also for the types of malware payloads involved, thus, making obvious the preventative measures one can employ. They serve to demystify the scary nature of these attacks, helping one to a rational approach to prevention.

Here is description of a typical exploit kit:

T-I framer Kit

Fragus exploit pack

Liberty Exploit Kit

Siberia Exploit Pack

Elenore Exploit Pack

Unique Sploit Pack

Phoenix Exploit's Kit.

While the exploit code for the various vulnerabilities is contained in these exploit packs, cybercriminals who use them provide their own malware executables. Here are some of the trojans harvested by BLADE:

Code:

TR/Vundo.Gen
Rootkit.Win32.Agent.bcte
Backdoor.Win32.Bredavi.boy
TR/PCK.Tdss.AA
TR/Dldr.Sinowal.A
TR/Spy.ZBot.aebe
TR/Fakealert.QF
TR/Banker.Banco.mtc
Trojan.Win32.Oficla
TR/Drop.Agent.wov
Trojan.Win32.FakeSpypro
TR/Hijacker.Gen
TR/Dldr.FraudLoad.wxpq
Worm/Bezopi.XE
Trojan-Dropper.Win32.Agent.bkqq	 
TR/Dldr.Fakeinit

You will note in these exploit packs the wide use of the IE6 exploit , MDAC, patched in 2006: MS06-014. See my post #8 above for how this works.

I checked a couple of the URLs BLADE harvested, and they are the standard drive-by stuff that can be easily blocked by many solutions. This, an unknown IE6 exploit, possibly MDAC:

​

Plugin exploits abound. If you aren't sure how these work, and how easily they are blocked from downloading/installing the executable payload, see here for an old one:

Code Execution in PDF Files - Drive-by Download
http://www.urs2.net/rsj/computing/tests/pdf/

Sans.org noted last month a PDF file that had the malware executable embedded inside the document, not requiring an additional download:

Sophisticated, targeted malicious PDF documents exploiting CVE-2009-4324
http://isc.sans.org/diary.html?storyid=7867

I've not found one, but a MSOffice document with embedded executable payload does the same thing. See here for a description from last year, and how easily this can be prevented:

Malicious RTF Document in Targeted Email Exploit
https://www.wilderssecurity.com/showthread.php?t=244726

Most of the exploit packs contain PDF exploits against only Adobe. While individual users may feel safer using an alternative PDF Reader, cybercriminals know that most organizations use Adobe products, hence, a huge exploitable market, since most organizations probably don't have any of the security measures in place that I wrote about. Rather, they rely on being patched, which, as we know, is not reliable, since Adobe often delays putting out an update.

All of this should help people interested in preventative security measures to better understand what is involved in these drive-by attacks, and thus take action appropriate to the individual situation.

Certainly, as aigle points out in Post #3, the latest OS combined with IE8 are a step forward in countering what is seen in these current exploit packs. More thorough testing will need to be done to get a better idea of their effectiveness. And, of course, we don't know what to expect in future exploit packs!


----
rich

 

Rmus

Plenty of food for thought there, thanks.

BLADE does look very impressive so far doesn't it

 

Thanks for the analysis Rich. I will definately be giving Blade a try when it comes out.

I think Fkucdat's saying of "If it can't execute, it can't infect." rings true. The trick is to prevent the execution. HIPS and anti-executables do work...if the user knows what they are doing with it. Problem is, the majority of users just fly around the internet with no knowledge and just an AV for protection thinking they are safe. As Rmus has shown time again in his excellent analysis' of these attacks, protection against them isn't that hard. Simple education provides a lot more protection than any AV or AM on the market.

Rmus....please do not stop educating us.

 

I'm glad you and others have found this useful.

Not to take anything away from those solutions, but in reality, using Opera with Javascript and Plugins disabled, I've never gotten any remote code execution exploit URL on the malware domain lists to trigger an exploit. Hence, HIPS or anti-executables never get to do anything! How about that!

These exploits target either IE6/7 or application plugins, which normally require javascript to work. From what I've read, IE8 can be configured to be pretty secure, but I've not tested it.

I would never suggest to do away with HIPS/anti-executables, but the reality is that proper configuration of the browser pretty much eliminates web-based remote code execution exploits. This is not popular with a lot of people, and the arguments are

1) configuring scripting per site (whitelisting) is annoying

2) plugins are useful; for example, people who read lots of PDFs on line like the feature whereby they can start reading the first pages in the browser window while the rest of the document is downloading.

When "features" become exploitable vehicles for cybercriminals, the user has to decide between security and ease of use.

Some will use HIPS/anti-executables as the protection and leave those features enabled.

So, there is more than one approach to securing against these types of exploits.

I think more security-minded people are becoming aware that if you dig beneath the surface of things, you find solutions that the mainstream media choose to ignore.

For example, I noticed that the "Man-in-the-browser" exploit is back in the news. Interesting title. Can't you just imagine a person climbing inside your browser! One description:

The only way? Pretty scary! But if you do some checking, you find,

So, where does this trojan horse program come from?

The BLADE database has a number of banking trojans listed as payloads from various drive-by attacks. None that I checked worked against Opera with Plugins disabled and Javascript configured per site, because that banking trojan payload was used in exploits against IE6 and Adobe Flash/PDF Reader. So, nothing triggered and Anti-executable didn't have to do anything. In a sense, I avoided the exploit altogether -- much more preferable!

(You know that Mrkvonic has preached avoidance for years)

So, with that attack method taken care of, that leaves the social engineering method, which tricks the victim into permitting installation of the trojan malware. But that's another topic...

----
rich

 

Rmus, thank you very much for providing all this in-depth analysis. It's heartening to know we've got people like you fighting the good fight with copious information like this. It's the greatest tool when it comes to staying safe!

As an ill-educated Opera user, though, I hope you won't mind my asking a question about "per-site" configuration of javascript and flash. If someone uses Opera on a whitelist basis for these features, theoretically they'll remain safe once redirected to a nasty domain that hosts the exploits and payload in question - The attack will simply have no teeth owing to the denial of javascript executuion. More and more these days, though, it seems like trusted websites are being compromised to serve up the nasties.

Let's say for a moment that a familiar website, one that a user has relied on and trusted for years, gets compromised to serve malware through a javascript exploit. Let's also say that proper function of this website requires javascript. This would put the user at risk, because javascript would be active for that particular domain... What would be the best defense in this case?

 

I totally agree with you Rmus. The problems is that the average user isn't going to disable flash, scripting, etc in the browser because that will lessen the surfing experience for them. That's where some kind of executable prevention for the exploits that the scripts introduce to the system is going to have to come into play.