The Future of AV?

Last week I struck a cord with a few people when I (once again) complained publicly about the short-comings of AV. I’ve gone on record claiming the current model is broken, so what do I think will help fix it? Below are some of the ideas I’ve had for the future of AV.

  1. Shim the web browsers, either between the Internet and the browser (preferred) or between the browser and the OS so that the AV app can keep its fingers around the browser’s throat and control it.
  2. Develop vulnerability protection into the browser shim that acts as a virtual patch rather than traditional AV models that look for malware. This will be much more effective at stopping variants than malware protection is.
  3. Include a killbit feature to snipe malicious CLSIDs. Granted, this is signature-based but we need a stop-gap in place while heuristic or HIPS-like technology catches up.
  4. Utilize P2P-like communication between AV clients within the enterprise. If a host detects a malicious file, have it communicate an MD5 hash of the file to all other hosts and prevent access to that file. This will also help when there is disparity of definition versions within the enterprise.
  5. Take advantage of worms that check for a local infection by duping it into thinking the host is already infected. For example, Nimbda first checked if the local machine was infected. If AV could simulate infection automatically, it could prevent an actual infection. AV is pretty useless against worms until a payload is delivered. The ability to simulate an infection could help in that phase of a compromise.

The key is for AV R&D teams to gather in a room with a white board and start a brain-dump, thinking out of the box, leaving no trivial idea unspoken.

i hope you don’t mind me referring to your bullet points numerically by their order of appearance…

for 1 and 2 (since they really seem like they should go together) such a shim between the internet and browser already exists (at least if i’m interpreting what you’re suggesting it does)… the technology is called a layered service provider (lsp) and a number of anti-virus products implement lsp’s for the purpose of preventing exploitation of network client software such as browsers… i singled out exploit prevent lab’s product on my blog some time ago because i thought it was a great idea and more mainstream av vendors should be implementing that sort of thing but that was before i discovered that some already were…

for point 1 with regards to a shim between the browser and the OS, i believe application virtualization / sandbox technology fits that bill… i’d like to see that in an av suite, but i haven’t looked closely enough at things to see if it’s already in some of them…

for point 3, are there really that many pieces of malware that technically need CLSID’s in the first place (other than bho’s, which are reportedly in decline anyways)? it seems like the effort could easily wind up being for naught if the malware writers change tactics…

for point 4, panda is already doing something like this… also, i suspect the digital immune system technology that symantec bought from ibm years ago may have been comparable as well (though i don’t think symantec ever deployed it in their home user product and i have no idea if they used it in their corporate product)…

for point 5, my suspicion is that the technique to determine if a worm is installed is unique to each worm… if you know how to ’simulate’ the worm infestation then you probably also know enough to generate a signature for that worm… and if you have a signature for a worm like nimba (your own example) then the scanner can stop it…

i’m not really clear on why you think scanners are useless against worms until they drop their payload though… if the scanner knows the worm then it can stop the worm before the worm does it’s dirty deed, and if it doesn’t know the worm then nothing the worm does is going to cause the scanner to raise an alarm…

I edited the post to change from bullets to numbers.

The reason I say AV is useless against the initial phases of a worm is this; AV is malware-oriented. It looks for bad files. However, the initial phases of a worm are; scan for other vulnerable hosts, exploit other hosts through vulnerable application X (or more if its a really nasty worm), open a shell, download the payload (malicious file), and so on. A worm is basically an escalation process from initial attack (vulnerable application), to getting the bad guy’s code on the machine (payload delivery, usually a bot), to establishing a back door, to executing commands (bot functionality).

AV in its current form is by and large unable to detect the scan or the attack on the vulnerable application simply because no file has traded hands yet. Therefore the best defense against worms is currently network or host-based IPS that can detect an attack against the vulnerability, be that a BO, memory injection, or whatever.

Based on that assumption, if AV could simulate an infection in a case where the worm checks for infection, AV could indeed stop the compromise process, even if the target application remains vulnerable. However, this too is signature-based; the AV vendor has to discover that the worm checks for infection, then publish the inoculation technique to all customers who in turn have to get it to all hosts, which means we still have a considerable race condition, which leads me right back to the idea of vulnerability versus malware orientation.

Regarding point 3, CLSIDs; I think there is indeed a need to counter these. Just last week the ISC released six additional CLSIDs that should be blocked using the killbit method. Unfortunately, the best way to set the killbit is usually a login script that is dependent on users logging out and back in in time to get the killbit set. If we had that functionality in the AV software we could probably get it deployed throughout the enterprise more effectively.

Before they took it down, the Spywareguide had a list of over 3,000 CLSIDs to block. That’s a pretty significant number and even if BHO attacks are on the decline, they aren’t gone yet.

My primary argument against AV technology is that of changing from malware to vulnerability orientation. As you’ve pointed out on your blog, there are an infinite number of variations in malware but a finite number of actionable vulnerabilities. The inherit problems of the malware approach are exactly what is killing AV today; variations in malware, sheer number of samples to analyze, getting definition updates all the way to the end host, etc. Not to mention the fact that waiting for malware to be delivered to the machine is in itself a reactive technique.

ok, thanks for clarifying what you mean when you say ‘worm’… i don’t necessarily agree with the definition, and there are a number of things that currently get called worm that would be excluded, but with the paradigm shift you talk about in the last paragraph the perspective does make some sense…

to that end, you’re right, known-malware scanners don’t detect port scans… historically software firewalls have done a pretty good job of that, which is probably why so many av vendors chose to bundle them in their suites…

that said, those products that implement lsp’s *do* detect and block shell code (at least that shell code which is known, the halting problem is just as relevant for shell code as it is for any other kind of code) that gets sent to the vulnerable app…

as for CLSID’s, i guess what i was really trying to get at was what proportion of malware can get by without using them in the first place… if the use of CLSID’s is largely only because of malware writer laziness then when an effective control based on their use is developed it will quickly become ineffective as malware writers become just a little bit less lazy… people often talk about the cost to businesses to implement various controls but when it comes to the vendors people often don’t stop to wonder if it’s cost effective for the vendor to develop the control in the first place… regardless, i simply don’t know one way or another how necessary CLSID’s are to the majority of malware currently being developed… i’m just pointing it out as an important variable to consider…

finally, with regards to the paradigm shift you’re proposing itself… you’re right that there are only a finite number of vulnerabilities, but detecting attempts to exploit those vulnerabilities beforehand means detecting exploits themselves (which is why vendors are developing lsp’s) and that is reducible to the problem of detecting malware in general (there are an infinite number of ways to exploit a finite number of vulnerabilities)…
detecting exploitation after the fact to my mind means looking for application behaviour that is out of character, which seems like it is more properly the domain of a behavioural HIPS (which many vendors have incorporated into their product suites)…

You are correct about the paradigm shift I’m proposing…I think AV and HIPS technologies need to get their freak on and spawn some ankle-biters that have the best of both worlds.

Why should we be limiting ourselves (ourselves being the network defenders) with an addiction to AV and its ‘traditional role’? That’s what’s getting us creamed right now. We’re stuck in the mindset that ‘AV detects bad files and we need AV on every single machine.’ Despite the fact that AV is clearly declining in effectiveness.

Granted, many security suites come with AV, firewall, and HIPS all bundled in a single package. But they are mostly patchworks of single-use apps that were purchased by the vendor and slapped into their security suite to as a value-adding afterthought. These suites are complicated and cumbersome and more prone to fail.

“I think AV and HIPS technologies need to get their freak on and spawn some ankle-biters that have the best of both worlds.”

anything specific in mind? what would be the best of both worlds in your mind?

The best of both worlds would be software that natively, not through a patchwork of various apps collected through mergers and acquisitions, could detect malicious behavior as well as or better than Cisco’s CSA, could provide virtual patching as well as or better than ISS’s Proventia Desktop and also detect malware orders of magnitude better and substantially faster than the current best AV (whoever that is, frankly none are very impressive to me right now).

Improvements need to be made in decomposer engines, update techniques, and overall client stability and reliability.

I’d be willing to pay a hefty premium for something that does all of that very well. And to anyone who says ‘you’re expecting an awful lot’ let me say ‘you’re damn right.’ The enemy is innovative, creative and fluid and I expect my security software to be the same and then some.

Having said all that. What are your thoughts on the current state of AV? Do you find it currently provides an adequate response to threats such as Storm, Mayday, or Agobot (phatbot, gaobot, et al), etc, etc?

I should also mention that I just read your long (but worthwhile) post titled ‘the state of antivirus’. Very well said and many good points that will take me some time to digest and then discuss with you. And no I didn’t take your enjoyment in my ironic statement the wrong way. I’m not easily offended.

Moving forward, I should clarify a few things;

  1. I am indeed not as intimate as you regarding the inner guts of AV software and I certainly do respect your knowledge. Your experience and time spent focusing on AV puts you in a better position than my background, which has been network-based and very broad.
  2. When I bash AV technology, I am bashing, specifically, malware research and detection. Not behavior analysis or vulnerability analysis. Malware defense is truly the end game in a fight with a specific worm or bot, because there is plenty of opportunity in the early stages of a worm to counter it before malware is ever within reach of the AV scanner. My bitch is that I’ve had enough of uploading files to the likes of virustotal.com and having a 2% detection rate and the only reason I knew to upload said files was because of a behavioral analysis. The malware model of AV is broken when its evaluated against today’s threats. (I mention worms as a specific example but this observation isn’t limited to them)

i guess when i asked about what you thought the best of both worlds would be i was hoping to find out what you thought the best parts of each one individually is…

my own thoughts on the current state of av come from a perspective where anti-virus == anti-malware and all those other technologies are actually part of the industry… from where i sit, those technologies got neglected by the traditional mainstream av vendors because there wasn’t an immediate market for them (scanners had an immediate market because they required basically no knowledge to use) and the vendors had to please their stake-holders… cottage industries rose up around those alternate technologies and startups fought to build markets for them and when those markets get big enough the traditional av vendors will re-integrate the technologies back into their offerings… it happened with software firewalls, it’s currently happening with HIPS, and it will happen with others when they get big enough…

“decomposer engines”

i saw this terminology in your comment on my blog but i’m afraid it doesn’t mean much to me… my initial reaction is to wonder if this is the result of a translation from a different language… could you clarify what you mean by decomposer?

“The malware model of AV is broken when its evaluated against today’s threats.”

it may not seem like it (especially not in our novelty-addicted society) but some of todays threats were also yesterdays threats, and known-malware scanning does quite well against those… obviously, however, known-malware scanning doesn’t do well against new/unknown malware… it’s just not the right tool for that particular job, it never was, and the anti-virus industry has done both themselves and their customers a disservice by acting like they could fix that…

there’s a definite (and to me quite obvious) oxymoronic quality to the idea of using known-malware techniques against unknown malware… that’s a domain where generic techniques (such as HIPS) are better suited…