Vulnerabilities, Exploits & Payloads, Oh My!

Over the past few years at NSS Labs we have interacted with some very smart people and been able to observe which technologies and approaches work better than others. And being immersed in information security product testing, it is easy to forget that not everyone has the same vantage point that we do.

I was having a conversation recently with a very smart Intel Hardware/Software Engineer when the Google / Aurora attack came up. He said that based upon the explanations from AV community, he assumed that the attack was not stoppable… I assured him that was not the case, and that there is a technical solution that can protect against attacks like Aurora. Host Intrusion Prevention technology exists and works by preventing the vulnerability (in this case CVE-2010-0249) from being exploited. If the vulnerability cannot be exploited, the payload (malware) cannot be delivered.

So the question is whether it is easier and better to protect against:

- One (1) vulnerability
- Six (6) exploits
- 55,000+ viruses, Trojans, rootkits and other malware PER DAY



I then shared that in our recent study of seven Endpoint Security (AV) products, only one product (McAfee) protected against Aurora and exploit variants. And that the AV industry as a whole is still focused on chasing malware and, as such, is ill equipped to deal with exploit-based attacks like Operation Aurora.

So the discussion turned to ways in which someone can be infected with malware from the web. Basically, there are two methods:

1. An attack on the User – i.e. tricking someone to download software that contains malware – video codecs, pirated software, fake AV, etc.
   
2. An attack on the computer – i.e. exploits containing malicious payloads (aka “drive-by” exploits).
   

The first is solved by a combination of user education and reputation systems like those provided in Internet Explorer 8, Firefox, Chrome, etc., which warn people that the software they are about to download is infected. Some AV products have this as well. The second is solved by HIPS. Not AV. Why HIPS? Because true HIPS products protect the vulnerability from exploit. They do this by operating in memory and inspecting data as it streams onto a computer as well as inspecting processes before allowing them to run. Traditional AV products do not do this; which is why AV vendors have purchased HIPS technology over the past few years (McAfee bought Entercept, TrendMicro bought ThirdBrigade, Cisco bought Okena, etc.).

But, in general, no vendor seems to have uniform integration of HIPS into their endpoint products either on the consumer or corporate side. It clearly takes some time to integrate these technologies. Unfortunately, the marketing message of “proactive protection” has gotten ahead of the technical reality. This is what we found in our Aurora test: http://nsslabs.com/test-reports/NSSLabs_Vulnerability-based%20Protection-Google-EPPv14.pdf

The bottom line is that the best way to solve the “drive-by” problem is for AV vendors to implement true HIPS which prevents a vulnerability from being exploited, and thus a malware payload cannot be delivered.

-----

However, nearly two weeks after the attack was made public, one product still does not stop the original exploit, and 85% failed to stop additional exploit variants. Few cyber-security attacks were better publicized than this one. It is concerning that such shallow coverage was delivered. Are lesser publicized but equally dangerous vulnerabilities better protected? Probably not.

In lieu of applying patches to thousands of machines, IT professionals rely on network and endpoint security products to provide a virtual shield for these vulnerabilities. Patching is usually prioritized and scheduled monthly. Deferring patching without good vulnerability coverage increases risk. When faced with these test results, organizations would be advised to install the Microsoft patch(es) as soon as possible.