Understanding Virus Protection Principles

The general goals of antivirus systems are fairly simple: catch as many viruses as possible before they reach protected systems, and keep viruses from being executed or stored on protected systems. Of course, as with many other computer- related tasks , this is much more simply said than done. We can decompose the general goal into two more specific goals: we want our antivirus system to correctly identify viruses without missing any or flagging legitimate data as infected, and we want it to be able to repair (or at least quarantine) any infected items.

Finding Viruses

Because viruses are executable code, you might think that all the antivirus software would have to do is look for a particular string of bytes to identify a piece of code as containing a particular virus. This was how early virus scanners worked: antivirus product vendors would produce a list of signatures for known viruses. Each signature was nothing more than a byte sequence representing either damage done by the virus or the actual virus code; if the scanner found the signature in a file, that file was assumed to be infected. This straightforward approach worked fine for several years , but the virus makers got clever and began to modify their viruses in a number of ways. Encrypting the virus code foiled simple signature scanners, although eventually the vendors learned to look for signatures in the unencrypted part of the virus ”the code that actually decrypted the payload. The next major development was the emergence of self-modifying polymorphic viruses. These viruses (which include Chameleon, Tequila, and Satanbug) could change their code structure to better evade scanners . Most conventional viruses now are both encrypted and polymorphic (although encryption is really just a simple case of polymorphism). More sophisticated virus writers use other techniques, too, including creating their own compression schemes to obfuscate virus code and modifying attachment contents (and thus the attachment s signature) each time a new host is infected. Antivirus vendors always eventually catch up, but they are often operating in a reactive mode because they have to respond to whatever the malware community has dreamed up. (As viruses get more virulent, this reactivity is a bad thing, which is why it s so important that your servers be locked down, too!)

In earlier days (say, the late 1970s), viruses were limited to executable code: you had to run an infected program to infect your computer. However, when Lotus introduced its groundbreaking 1-2-3 spreadsheet program, the rules of the game changed. Lotus 1-2-3 brought us a compelling new feature: the ability to attach executable code, or macros, to a document. These macros could be used to automate repetitive tasks or complete complex calculations. Other vendors picked up on the idea, and now all major office productivity applications include some kind of support for macro languages. The macro facilities offered by Microsoft Outlook and the other components of Microsoft Office are unusually rich and powerful. Unfortunately, like any other powerful tool, the Office Visual Basic for Applications (VBA) tools can be misused to write and deliver malicious code. So-called macro viruses consist of VBA macros that implement the virus code. These macros are attached to Office documents, mail messages, or Web pages, so the virus spreads without infecting executable programs. Because the VBA code is actually text attached to a message or Web page, antivirus product vendors were largely unprepared when Melissa and LoveLetter (the ILOVEYOU virus), the first fast-spreading macro viruses, hit computers. These two viruses, along with their many imitators and variants, sparked a renewed interest in messaging security ”particularly at sites that had to clean up large-scale infections.

Tip  

Although we all tend to lump them together, Melissa and LoveLetter are actually quite different; Melissa is a true macro virus, whereas LoveLetter is a script virus. The difference is that a macro virus is carried as a macro within an object (like a Microsoft Word document) that contains some other data. A script virus contains only the malicious script itself.

Microsoft responded to the increase in the prevalence of macro viruses by changing the Office security model so that administrators and end users can better control which macros execute and when they can run. Outlook s macro security features are discussed in detail in Chapter 13, Securing Outlook. There are some additional security measures you can take to block macro viruses without completely disabling the useful and desirable ability of Office applications to run macros you create.

Messaging systems pose a couple of unusual challenges for antivirus screening. First, messages themselves can be infected with macro viruses, but it s more likely that any infection will be in the files attached to the messages, meaning that antivirus scanners must be able to pick apart messages, whether stored or in transit, and examine their component parts . In a related vein, infected files could be contained inside other files. Consider the common case of a message that has a .zip file attached to it! The wide variety of file attachment encoding problems can disrupt scanners, which might stop working properly if they encounter a malformed message. Encrypted messages can create a similar problem, which is why many administrators prohibit them.

These challenges are compounded by the fact that viruses can be detected at several different places in a messaging system. In particular, looking for viruses in a large mailbox store can be troublesome : it takes time and resources to scan the store, and just scanning the individual pages doesn t do any good because the scanner has no way to distinguish where messages and attachments start and stop; you ll need an Exchange-aware scanner. A good virus protection strategy builds on the principle of defense in depth to provide several layers of antivirus protection, but all of those layers depend on scanning.

There are three primary kinds of scans , each of which does something slightly different. Note that for all three types, the amount of resources used varies depending on how often the scan runs, the number of items that have to be scanned, their size , and their arrival rate.

• Proactive scans check new items as they arrive at the server. These scans are designed to catch infected or suspicious items before they re stored (either in a client s mailbox or on the server). These scans don t scan any stored data.

• On-demand scans (also called on-access scans) are triggered when a file or message is accessed, whether by a user or some other automated tool. These scans try to catch infected content that might have landed in the store before the item is downloaded to the requested client.

• Background scans scan every item in a store or file share. This might seem silly, because the other two scans should theoretically catch all viruses. However, background scans are very useful for two reasons: you can schedule them, and they can happen when your virus signature definitions are updated, allowing you to catch variant versions of viruses that slipped through the on-demand scans before the signature updates were received. In fact, whenever you get a new signature update, it s a good idea to let your scanner make a thorough background check, just in case you re harboring an infection that slipped past the older signatures.

Cleaning Up Viruses

There are two primary approaches to cleaning viruses from code or data. The first approach is to give up and quarantine (or destroy) the message without any attempt to repair it. This is often the only feasible approach. Let s say your antivirus scanner detects an infected executable. It can see where in the file the virus signature falls , but it has no way to know what bytes occupied that space before the virus infected it. In other words, the antivirus scanner lacks knowledge of how to properly repair the file. The other approach, of course, is to repair or reconstruct the message or data by removing the virus. For virus-infected messages, this cleaning usually involves removing any infected attachments while leaving the rest of the message alone (most products now add a text part to the message body indicating that an infected attachment was quarantined or removed).

Of course, cleaning an infected mailbox database is harder than cleaning a single message, partially because the cleaning code has to understand the structure of the Exchange message store. Most Exchange-aware antivirus products depend on one of two interfaces for viewing the store as a logical set of mailboxes, folders, and messages: our old friend Messaging Application Programming Interface (MAPI) and the Anti-Virus Application Programming Interface (AVAPI), introduced with Microsoft Exchange 5.5 Service Pack 3 and refined in various later releases of Microsoft Exchange 2000 Server and Exchange Server 2003. I talk more later about the pros and cons of these different interfaces.