I’m part of a non-professional volunteer organization that conducts tests of antivirus products based solely on flat file-scanning ability. We (the virus collecting team) hunt for our own samples, which are then verified by behavior analysis and/or disassembling them before adding them to the test set. Number of samples range from 90-200 per day, and the test is conducted daily. Samples from Asia account for at least half the number (we’re from China), but we try to keep a balance by collecting as many samples from US/EU as we can, most notably the Zlob/Vapsup/Vundo/Banker/Zhelatin families, since they’re so predominant among the malware scene in the West.
There’s a few issues I want to raise regarding avast! that I’ve found. I’ll keep this as brief as I can.
The Web Shield scans only HTTP traffic over port 80 by default, while HTTP traffic can occur across any port a program specifies. For example, the Web Shield will miss a trojan located at http://www.baddomain.com:8080/virus.exe. This could be a potential security issue because the Standard Shield has no ability to scan embedded files inside a host binary once it is downloaded onto the hard disk, also, it will miss script exploits targeted at other programs using non-conventional ports. In contrast, NOD32 and Kaspersky’s HTTP scanners have the ability to detect HTTP communication across all ports, and filter them accordingly.
Poor handling of non-ASCII filenames. If the system language is set to English, the Standard Shield will be able to detect, but not remove, viruses with non-ASCII filenames. This problem disappears when the system language is set correctly, however, but it could be a problem for English users who receive viruses with non-standard filenames.
Poor detection. avast! displayed surprisingly poor detection rates in our tests, averaging only 55-65% across our sample set. The samples in question have been sent to your company, with no follow-up results. We had high hopes for avast!, since it was a light and stable product that was localized in Chinese, and generously provided for free by your company. But it was heartbreaking to see avast!'s performance over a period of three months so far. We’re willing to provide any cooperation to your company as required to resolve this problem; please PM me if interested.
There have been rumors that the behavior blocker module of the Standard Shield will be scrapped come version 5. I would like to protest this if it is true. Given avast!'s low detection rates, the blocker is perhaps its only saving grace by acting as a pseudo-HIPS of sorts. I hope your company will reconsider.
I don’t know how to detect HTTP stream realiably and I would like to see if NOD and Kaspersky really does this well. From my experience even the well known port 80 is frequently flooded with non HTTP streams, or data the seems to have a HTTP heades, but than follow completely different logic - for example they are heavily bi-directional, do not follow the Content-Type and Length negotiation and so on. We fight with incompatibilities from time to time.
However, it is not that difficult to add the port 8080 to the list of protected (scanned) ports - just edit the redirected Ports box in the WebShield config.
Truly, as 8080 and 3128 are the de-facto standard for HTTP proxy ports, we might add these by default, but again - we have to have a reliable fail-safe method to handle the connection once the stream is not HTTP. We can hardly blame someone, that their custom protocol running on a custom port so closely resembles HTTP that WebShield would mess all the communication.
Since WebShield is implemented as a HTTP proxy it is generally not very friendly to non-http data. Even if it would be more friendlier, I would definitely not like to have any generic proxy inspecting every packet on my desktop. It would kill the network speeds as hell. Surely there are other ways, like scanning every packet blindly, without decoding HTTP specific stuff, like chunked-encoding, deflate etc., but I doubt it would bring that much for the security. Detecting connection by process, e.g. every connection from Internet Explorer, does not seem to be a good idea either. IE can host JAVA and Flash and other scripting engines that can connect to their friends with what-ever-hand-made-protocol they choose.
What I don’t get is the objection to the Standard Shield:
This could be a potential security issue because the Standard Shield has no ability to scan embedded files inside a host binary once it is downloaded onto the hard disk, also, it will miss script exploits targeted at other programs using non-conventional ports.
Standard shield will surely catch the virus even if it would be downloaded from any non scanned port or transferred and written to the disk by any means.
I am not privy to the internal technical details of how your product works, nor that of NOD32 and Kaspersky, so the best I can do is give my observations on what happens. Taking NOD32 for instance, the HTTP scanner detects when a program requests network access, and – according to the documentation, and my personal observation – can monitor traffic requested by that program across all ports if active mode is turned on. This would be a nice feature for avast!'s Web Shield. Of course, starting by adding ports 8080 and 3128 to the defaults would be a very good idea.
Regarding my comments on the Standard Shield, the Web Shield and on-demand scanner have the ability to “unpack” executables (so to speak) and scan the embedded files inside, that will be dropped when the executables run. Note that I am not referring to a self-extracting exe, but a dropper trojan that releases its components when executed. Perhaps you could ask the technical department of your company for details. The Standard Shield lacks this capability, which I assume is to conserve resource usage. Of course, the embedded files will still be detected when their dropper is executed and they are released.