Ferris Zero Hour Defense Report

View the Ferris Zero Hour Defense Report (87 KB)

Executive Summary

Enterprises have invested heavily in anti-virus defense on e-mail boundary servers, e-mail and other internal servers, and on client systems. This highly distributed approach is necessary because computer viruses can enter, and propagate within, an enterprise from a variety of sources.

Despite this large investment, enterprises are indicating that they are still vulnerable to a class of e-mail-borne viruses—those that enter an enterprise in the gap between their initial outbreak (the so-called zero hour) and the availability of a matching anti-viral signature. This gap is currently reported to be between six and eight hours. Recently a
number of approaches to eliminating this gap have entered the market. None of them offers a 100% solution. However, they are worth considering as a means of significantly reducing the chance of a rapidly propagating, e-mail-borne computer virus entering an enterprise during this six- to eight-hour gap.

Computer Viruses

In this report we employ the term "virus" to refer to all forms of malware, including viruses, worms, Trojan horses, and zombies.

A virus is computer code that, when executed:

• May insinuate itself into that computer system so that it, or some subfunction, will be executed again at a later time or when some event occurs.
• Attempts to propagate itself to other computer systems.
• May cause varying degrees of damage.

A computer virus insinuates itself into a computer systems by:

• Installing itself in a file and instructing the operating system to execute it on startup, at a scheduled time, or on the occurrence of some event.
• Overwriting an existing file that the operating system already executes, either on startup, at a scheduled time, or on the occurrence of some event.
• Inserting itself into an existing file that the operating system normally executes upon startup, at a scheduled time, or on the occurrence of some event.

A computer virus attempts to propagate itself by:

• Attaching itself to the boot sector of a writable floppy disk or other removable boot media.
• Including itself as the payload of e-mail messages.
• Inserting itself directly into another system by exploiting a security vulnerability in some protocol.

In epidemiological terms, propagation via a floppy disk or e-mail message is a form of indirect infection in which the floppy or e-mail message serves as a vector, while exploiting a security vulnerability is a form of vectorless direct infection.

Historic Anti-Virus Approaches

Historic anti-virus techniques operate by scanning files on hard disks, on removable media such as floppies, or in e-mail messages to determine whether they include viral code. Basically, this consists of matching the contents of a file against a library of viral patterns, known as "viral signatures," to determine whether the file contains viral code. Using this approach, the detection of viral code is dependent upon the availability of an appropriate viral signature.

In order to run efficiently, a variety of optimizations are employed. For example, anti-virus programs will typically:

• Remember the identity of files that have already been scanned and only rescan them if they have been modified (by verifying a checksum).
• Scan a file once for all possible viral signatures, rather than once for each viral signature.

Remaining Vulnerabilities

Following the arrival of a new computer virus, there is a window of vulnerability that occurs between an initial infection (the zero hour) and the publication of a matching viral signature. The good news is that unlike biological viruses, at least to date, it has always been possible to construct a vaccine in the shape of a matching viral signature. The bad news is that this may take some time—currently, six to eight hours—and that today's rapidly propagating e-mail-borne viruses are often able to wreak considerable damage during this time.

This has led a number of new entrants to the anti-viral field to develop zero-hour, or near-zero-hour, approaches that target this six- to eighthour window of vulnerability. We are aware of at least three such vendors:

• MessageLabs
• IronPort
• Avinti

MessageLabs claims to have developed a set of heuristic filters that identify potential viruses and quarantine them for the period that it takes for matching viral signatures to be published. We have no way of assessing either the effectiveness of these heuristic filters, or the impact of delaying heuristically suspect e-mail for six to eight hours on
the off chance that it may be infected.

IronPort has extended the SMTP traffic-based, pattern-matching techniques that it had developed to identify and block spam to identify and block outbreaks of fast-spreading e-mail-borne viruses. While this is not strictly a zero-hour solution, it may detect a virus outbreak in enough time to establish a block before a new e-mail-borne virus
reaches any of its customers. We believe that this type of approach will reduce the number of e-mail-borne viruses that enter an organization during those six to eight hours before matching viral signatures are published. What we are unable to assess is just how large this reduction will be. What we can assert with certainty is that it will not be a 100% solution.

Avinti is taking the most novel approach, which is to invoke suspected e-mail attachments—a category that includes in-line objects—inside a virtual machine "surrogate" for each recipient's computer. If an attachment is determined to have propagated itself, caused damage, or otherwise acted suspiciously, then it is deemed to carry a virus and is
treated accordingly. If it hasn't, then it is deemed safe. Note that Avinti's approach is used not only on obviously executable attachments such as .exe, .sys, and .com files, whether in the clear or encapsulated in .zip or other compressed-format files, but also on apparently passive attachments such as .jpg files that may exploit a
security hole to trigger their nefarious viral activity.

The good news about the Avinti approach is that it is a true zero-hour anti-virus defense. The bad news is that there is a class of e-mail-borne viruses that depend upon user input to trigger their behavior and therefore will not be detected by Avinti virtual machine technology. Members of this class—the W32/Bagel family of computer viruses—
have already been observed in the wild.

At the same time, it can be argued that viruses that require operator input to trigger their transfer to other systems/vectors are incapable of explosive propagation. If this is the case, and we believe it is, then the fact that they escape detection by Avinti technology does not constitute a significant threat.

Given the novelty of Avinti's approach, we will describe it in greater detail below.

Avinti's Anti-Virus Technology

Virtual Machine Technology

A virtual machine is "virtual" in the sense that it is an execution environment, maintained by software, that is effectively identical to that of a physical computer. Thus, it is able to run software that canotherwise only run on a physical computer platform such as DOS, Windows 95, Windows XP, NetWare, and Linux.

Virtual machines have existed for a long while, though their roles have varied over time. IBM's historic Virtual Machine (VM) operating system allowed a single expensive mainframe computer to be partitioned out to many time-sharing users, and/or run two operating systems in parallel when migrating from one to another.

Many observers thought that virtual machine technology had passed its"sell by date" as less expensive minicomputers became available, followed by downright inexpensive microcomputers. However, virtual machine technology has now reappeared in contexts where large numbers of execution environments that can be rapidly deployed and retired are required. Virtual machines are particularly useful in test environments where many different configurations of hardware and software are needed. Virtual machines are also useful for organizations that host Web servers for multiple clients, or where individual Web servers need to be rapidly launched and retired within a common server farm to match varying demand.

Now Avinti has identified another use—the monitored invocation of e-mail attachments. We use the term "invocation" to cover two activities:

• The launching of directly executable attachments (e.g., .exe, .sys, .com files, etc.).
• The launching of associated applications to process attachments.

Also, note that the malicious effects of attachment invocation may be either direct or indirect. That is, the attachment itself may perform a malicious action, or it may plant code that at a later time performs a malicious action. Monitored invocation has to address both forms of malicious action.

Test Invocation of E-mail Attachments

Avinti's premise is that the best way to tell if an e-mail attachment is malicious is to invoke it and see what happens. This requires an ironclad execution environment, as well as a means of both provoking and detecting malicious behavior.

Virtual machine technology is able to provide both. It is ironclad because it can be constrained to modify only virtual resources. Enabling a virtual machine to provoke and detect malicious behavior requires an additional step, however, and this constitutes Avinti's unique contribution.

Unfortunately, the line between malicious and nonmalicious behavior is not a sharp one. Clearly, deleting all of the files on a C: drive is malicious. Likewise, modifying no files (including registries and data bases) and performing no communication is benign. The problem, as always, arises in the middle, and here Avinti has been forced to take a
"better safe than sorry" approach. Avinti's method treats as malicious any attachment that, when invoked, updates the Windows registry, creates/overwrites/deletes a file, or attempts to communicate with another system. This means that an attachment that legitimately installs/updates new software will be incorrectly identified as malicious. Ferris views this as acceptable, because in today's virus-laden environment, e-mail is simply not an acceptable means of
software distribution.

Even when a line is drawn between malicious and nonmalicious activity, getting an attachment to reveal its intended actions is not so simple. As we have already noted, malicious behavior can occur either as a direct result of invoking an attachment or later as an indirect result. In the first case, detection of potentially malicious behavior is relatively straightforward if this behavior does not require operator input to trigger it. The dilemma for Avinti is how to have a virtual operator respond in a way that provokes malicious behavior. This is a nontrivial problem.

Provoking indirect malicious behavior is a similarly nontrivial problem. Avinti is able to advance the clocks of its virtual machines so as to invoke malicious behavior with a time-based trigger. What Avinti is not able to do is have a virtual operator perform the operation, or series of operations that may be required to trigger malicious behavior, such as entering a password provided in the text of an e-mail message.

Finally, there is the question of the virtual machine environment itself. Even if an organization runs a common desktop environment, there will always be periods of upgrade during which a minimum of two different desktop environments will exist simultaneously. In such a case, it may be appropriate for Avinti to test attachments by invoking them in both of these environments. Where rganizations impose less version control, there may be many more different desktop environments operating—running either different major software releases or the same major software release but at different patch levels. In this case, it is not clear how Avinti should proceed.

Test Invocation of E-mail Message Bodies

While e-mail attachments are often the vectors for viruses, e-mail message bodies may themselves serve as virus vectors, especially if they are encoded in Microsoft or Notes proprietary rich text formats or in HTML with embedded scripts.

It is relatively easy to directly invoke an attachment in a virtual machine. Unfortunately, the same is not true of rich text e-mail message bodies, which need to be first processed by e-mail servers and then opened using e-mail clients. Avinti has not provided an explanation of how it achieves this.

Even if Avinti doesn't provide an explanation, the good news is that, in general, e-mail clients can be configured to disallow script execution or sandbox the execution of scripts. This is usually sufficient to prevent e-mail message bodies from serving as virus vectors, and absolves anti-viral e-mail gateways from having to inspect, or in Avinti's case, invoke e-mail message bodies.

Conclusion

Avinti is adding an interesting new weapon to the arsenal of anti-viral e-mail gateways, and, more importantly, one that is able to deal with rapidly propagating e-mail-attachment-borne viruses during that crucial period between the start of an outbreak (the zero hour) and the availability of a suitable viral signature some six to eight hours later. Unfortunately, it is not a 100% solution. As we have described, it is possible to construct viruses that cannot be detected by Avinti's technology. Does this matter?

To be dangerous during the period from initial outbreak until a suitable viral signature becomes available, a virus has to achieve explosive propagation. If it doesn't, there won't be enough copies around to pose a significant danger. It can be argued that viruses that require operator input to trigger their malicious behavior (including self-replication) are
incapable of explosive propagation. Thus, the fact that they escape detection by Avinti technology may not be relevant. We tend to agree with this analysis, and therefore believe that Avinti technology constitutes a relevant form of defense against rapidly propagating e-mail-borne viruses, from the zero hour through the availability and installation of a suitable viral signature.