Posts Tagged ‘testing’

Killing Antivirus, One DLL At A Time

Tuesday, February 2nd, 2010

Browsing the Web for online virus scanners will yield an increasing array of available services. Ranging from vendor-specific portals featuring their latest antivirus engine through to public testing portals offering 40+ different scanning engines, these online scanning services allow visitors to submit suspicious files and help identify their true malicious nature.

The bigger portals – the ones offering dozens of popular antivirus products to test against – are quite useful to corporate security teams. They allow the organization to not only inspect suspicious files without the need of building and maintaining a whole malware testing lab, but also allow the organization to get a better feel for specific product coverage of the threat. I’ve also seen many organizations using the portals as a convenient source of malware naming correlation – i.e. which vendor calls the sample what?.

This handy feature hasn’t gone unnoticed by the malware authors either. They use these online portals as part of their Quality Assurance (QA) process to guarantee that their latest malware creation will go undetected when deployed against their target. They’ve been doing this for nearly a decade now though.

Many of the biggest virus testing portals (such as VirusTotal) work with the major antivirus product vendors by handing over copies of the submitted files to them. Obviously, this process isn’t so cool for the actual malware authors and, as you’d expect, enterprising individuals now offer similar malware testing portals with guarantees that they will never share the files with anyone. Which, obviously, has resulted in the growth of testing portals that cater exclusively to cybercriminals and offer monthly subscription testing services optimized for batch processing of malware.

The malware portal scanning ecosystem is rather interesting, but perhaps the most interesting aspect is how it’s become a critical tool by which vendors keep pace with the latest malware threats. Because the portals have become popular vehicles for checking and verifying coverage, they’ve attracted mainstream attention (and adoption) as a vehicle for tracking the relative performance and effectiveness of the antivirus vendors themselves. It’s not what the portals were originally intended for, but nevertheless that’s what they’ve become.

Now, because of this “competition” in coverage, samples submitted to popular portals like VirusTotal seem to have a higher probability that vendors will ensure some level of detection coverage – especially if at least one other vendor detected the sample or flagged it as suspicious. This was discussed a little in yesterdays blog on Kaspersky’s blog – On the way to better testing – in which they describe how the system can be rigged and abused (i.e. creating fake malware detections and watching who is copying who).

Anyhow, there’s another aspect of this ecosystem that’s both worrying and fun to explore at the same time. Given the mix of different detection engines and strategies all the antivirus products within these portals use, many files get marked as suspicious or incorrectly flagged as malicious. This applies especially to files that have been compressed, packed or armored to speed up Internet transfers or prevent the loss of intellectual property through reverse engineering. As such, the whole “signature copying” system is ripe for abuse.

To give you an example (names of the perpetrators/victims intentionally left out), I remember someone a year back intentionally grabbing the DLL’s of the most current version of a popular antivirus product and submitting them to one of these portals. Low and behold, by a few days later there was news about XXX vendor’s product killing/quarantining YYY vendors product.

Which I guess brings me to this blog’s title – Killing Antivirus, One DLL At A Time. Anyone can abuse these feedback-loop systems – and some people already do (for fun). If anyone wanted to cause a degree of havoc to the antivirus vendors that rely upon these testing portals as a crutch for their detection, here are some of the things that would likely have them tripping over their tails…

  • Every time antivirus vendor XXX updates their engine, the antagonist submits the newest DLL’s and EXE’s for vendor XXX’s product to a testing portal. They’d likely see all kinds of false positives immediately (especially for DLL’s), but after a few days they’d also discover increased “coverage” amongst other vendors – and maybe a news story that vendor YYY accidentally killed vendor XXX’s product.
  • Each time Microsoft or a major software vendor releases an new update of their product, they could submit the latest files and observe which vendors false-positive on them. They’re probably not a vendor you’d want to consider deploying in a large enterprise though.
  • Packing antivirus vendor XXX’s key DLL’s and EXE’s with popular “known bad” packers that also have well covered unpacking solutions will likely increase the immediate number of false positives – which may in turn result in a quicker turn around of vendor YYY’s signatures for detecting the new “threat”.
  • Binding vendor’s brand new (and critical operation) DLL’s and EXE files with known malware samples, or adding them to popular droppers will likely increase the “guilt by association” detection systems – and similarly result in more false positives.

I could probably think of many more ways that evil-doers could mess this signature generating ecosystem up, and even then I’d probably miss several that the bad guys are already doing or in the process of testing out.

Some may argue that by having pointed out the frailties of this ecosystem I’m in turn exposing the antivirus industry and their customers to more risk. But lets face facts, this stuff already happens. This is not rocket science. I can just as easily see some computer science under-grad over the road at GATech conducting his own tests and publishing a great paper on the topic. Perhaps he already is?

Regardless, there are lessons to be learned here and the ecosystem exposure is real. I’d be curious to see what the effect would be of criminals actively and persistently conducting the “attacks” described above – would that cause pain to enterprises that intentionally run multiple antivirus products together to help weed out false-negatives and improve overall coverage? Or would consistent abuse of these testing and submission portals result in lowering the probability that real malware submitted to them would eventually be covered in signature updates at a later date?

– Gunter Ollmann, VP Research