CSIS study lists the major programs and vulnerabilities targeted by web exploit kits

From http://www.csis.dk/en/csis/news/3321 (via):

 

So basically, use Windows 7, browse with either Chrome, Opera or Safari, and get rid of Java

 

Then I just need to upgrade my OS and get rid of Java and I am good to go, fantastic

 

Well get to it

 

I thought this was about the Canadian Security Intelligence Service.

 

Soon, not yet

 

Hehe OK then

 

Interesting article.

Yet, Ho hum... another research study with pretty graphs. (Just subsitute the vulnerable software/browser du jour). You may remember about a year ago this month, a research lab provided similar statistics:

BLADE MALWARE URL ANALYSIS RESULTS
http://www.blade-defender.org/eval-lab/

Which leads to another conclusion, that not much has changed:

• Users do not keep track of updates
  
  
• Users do not have proper protection in place to block these exploits in the kits, which are remote code execution, that is, they are triggered automatically when the victim is led to a compromised web site.

Several things are always conveniently missing from articles like this. For example, not all vendors have patches/updates readily available upon the appearance of an exploit in the wild (think Adobe in the past), thus creating a window of opportunity (0-day) whereby the user is is vulnerable without other protection in place,

Zero-Day Attack On Adobe Acrobat And Reader Under Way, But Patch Is Weeks Away
http://www.darkreading.com/security/attacks-breaches/214502130/index.html

How many would even know there was an exploit in the wild, unless they read security blogs daily?

That isn't to say that patching is not necessary, but I don't know anyone who helps others with security, that depends on a program being "patched" as a sure-fire means of protection. There are just too many 0-day occurrences out there to be patch-dependent.

So, how else to protect?

Web filtering and Data Execution Prevention (DEP) have been shown to be not reliable in all cases.

Controlling scripting on web pages works for certain exploits, but is dependent on the user being careful with which web pages are permitted to run scripts.

While Antivirus products have become very good in many cases, in an article in The Register CSIS research Peter Kruse noted:

Java, Adobe vulns blamed for Windows malware mayhem
http://www.theregister.co.uk/2011/09/28/window_malware_infection_exposed/

The "payload" refers to the executable file that the exploit attempts to install.

So, I'll paraphrase the opening of the article, which states:

to:

"Protection" can come in many ways. One example:

I'll always remember this from almost 7 years ago, by SecureWave, who advocated (ahead of the times) that systems should be protected from allowing unauthorized executables from installing without permission:

(Only Microsoft with Software Restriction Policies in WinXP said anything about this earlier)

Here is an example using an exploit listed in the study.

CVE-2006-0003 IE MDAC
This targets IE6, long since patched (2006). Why is this exploit still included 5 years later in the current Exploit Kits? I'll leave that for you to answer!

The code downloads an executable file, often with a spoofed file extension, then renames the file with the .exe extension and attempts to run it:



Here, the old ProcessGuard blocks, because this svchost.exe is not the correct file, nor is it in its proper location:



and, Software Restriction Policies in action (now AppLocker):



All of the other exploits listed in the article serve up a similar trojan executable file.

______________________________________________________________________________

This article presents excellent research, but:

• falls short of informing the reader of the potential hazards of depending on patching.
  
  
• does not present any discussion of other preventative measures to protect against the 0-day window of opportunity.

regards,

-rich

 

Don't they always?

 

I don't think the purpose was to show people how to protect against 0-days. Just to show statistics.

 

Usually exploit kits don't use 0-day exploits though. For example, see http://www.securelist.com/en/analysis/204792184/Exploit_kits_attack_vector_mid_year_update. "Though some exploit packs target zero-day vulnerabilities, a large number of exploits go after vulnerabilities for which patches exist," Lenny Zeltser said.

 

Very true, but they took the opportunity to mention their own product, so why not reference other articles, sites that go into discussions of prevention?


regards,

-rich

 

The best you can take from this is keep your software up-to-date. That includes your browser (get off of IE6 already), flash, and yes even Java too.

 

You make a good point. Most often, zero-day exploits surface first in targeted attacks. Stuxnet is a good example, which used 3 Windows unpatched vulnerabilities.

So, I can let CSIS off the hook (a little bit) since they confine their statistics to exploit kits.

I guess what always irks me about articles like this is that security organizations, like this Danish CSIS, blog about the current security scene, yet, do not offer much in the way of discussion on prevention.

Yet #2, are often self-serving in mentioning their own product.

Regards,

-rich

 

Same here I was very confused for a second.

 

Drive by downloads in Chrome?

So by drive by downlaods they mean a download is initiated and the user accepts?...

 

I personally don't see that as a drive by download, but as social engineering.

 

Me either. But that's what they seem to consider one. I don't know of any drive by downloads that work with Chrome unless they're including plugins.

 

It's unfortunate that there is no longer a strict adherence to termininology.

If you look in the Microsoft Advisories and Bulletins, you don't see the term "drive-by," rather, "remote code execution."

Strictly speaking, remote code execution means that once the user has gone to a compromised web page, the payload is installed "remotely" -- without any user confirmation.

Thus, some of the early fake AV exploits fell into this category, and the user was automatically infected unless some protection intervened:



However, later ones required the user to be tricked and allow the installation.

Here, javascript code starts the fake scan. Then, a prompt to install eventually comes up, a social engineering situation trying to trick the user:



Both of the above are commonly termed "drive-by" attacks, but are really quite different.

All of the exploit kits have PDF exploits remotely (automatically) triggered when the user lands on a compromised web site.

However, the results of the exploit are vastly different, depending on the user's browser configuration.

If the PDF plugin is enabled, the PDF file will open in the browser window and execute the code to install the payload executable (barring other protection in place), a true remote code execution exploit:



However, if the plug-in is not enabled, a prompt window will appear, and if the user chooses to open the file, infection will occur, barring other protection in place.




The CSIS study lists three PDF exploits, each a different way of triggering the PDF file to open in a browser.

How can we know from the statistics in the report, which of the two ways shown above was the means of infection?

They are all classified as "drive-by" attacks, but we can't really know what actually happened, unless I'm missing something in the report.

Hungry Man notes that exploits against browsers are often really targeting a plugin. This fact may slip by the casual reader who sees this statement in the report:

Since the report focuses on exploits against 3rd party software, should we assume that these are not exploits against the browser?

It's not clear, because this exploit,

CVE-2006-0003 IE MDAC

targets the IE6 browser, and not a plugin or other software.



regards,

-rich

 

Always learning from you, Rmus I agree that articles ought not to focus on the browser in these attacks, but what the attack was actually targeting. If it's attacking Java or another common plugin, it's not going to matter what browser you use. Hmm, actually, wouldn't Chrome users get nailed that way too? As far as I know, Java is still not sandboxed like Flash and PDF's are.

 

A reminder for those who think they're protected when using the Java plugin in Internet Explorer because Protected Mode is on: Java runs with different integrity level in Internet Explo. vs. low integrity Firefox. Other browsers - Chrome in particular - are also discussed in that thread.

 

Thank you MrBrian. As far as I know Java breaks at LowIL. I'll give that a read.

Thank you Rmus. I think they must be talking about plugins. That or they should really make it clear that drive-by exploits include those that need user interaction.

 

Thanks for this reminder.

Browser configuration is becoming more complex with each new generation of versions. Not always easy for the general user to understand.

regards,

-rich

 

Nice thread. Thanks, Rmus for the explanations in plain language and for the screen shots, which seem to be your trademark here and in many old posts

 

Yes, it squeals like a pig...