10.10 Email and viruses

---

Any Exchange server that runs without protection against email viruses is a disaster waiting to happen. New viruses spread quickly once they enter a messaging system. The current crop of viruses exploits both the programming capabilities of Outlook and the curiosity of people to propagate them faster than ever before. People find it difficult not to read a message with an interesting attachment or respond quickly to a message that proclaimed that someone loves them.

A sizable proportion of the messages that circulate around the Internet today contain embedded objects or attachments, and many hide viruses. The pervasiveness of common Internet protocols means that you can confidently send attachments in the expectation that their contents will survive the transit between sender and recipient intact. Once in a mailbox, clients can download the attachment, and most PC-based clients can process the code in embedded objects unless security settings prevent this. Executables sent in attachments are an obvious source of potential contamination from viruses, whether included in messages received from outside the organization or those unwittingly passed on by people working inside the organization. It is frustrating to see normally sensible individuals send executables to their friends every Christmas on the basis that the executable contains nothing more than a suitable cheery message dressed up in holiday decorations. Despite warnings to treat executables with suspicion and not to send executables unless absolutely required, the same old Christmas card executables appear every year. Short of firing anyone who sends such an attachment, I suspect that it will be very difficult to eliminate these electronic greetings. Thankfully, electronic cards are an exception to the rule. Most users are now aware of the problems posed by executable-based viruses, and system administrators have taken steps to address the problem. For example, some sites disable floppy drives, while most have implemented some sort of automatic virus checking for system memory and .EXE and .DLL files whenever PCs are booted.

10.10.1 A brief history of office viruses

The first document-transmitted virus appeared in the Word for Windows "Prank" macro in 1995. The virus worked by inserting a macro called "Pay- load" into NORMAL.DOT, the default Word for Windows document template, and propagated itself by spreading the macro every time the user opened a document on the PC. This virus was primitive in concept and implementation and resulted in some irritation, but it was essentially harmless because you could eradicate the virus easily. All it ever did was display a dialog box, but it pointed the way for others to adopt the technique by extending the basic virus concept by including some more malevolent instructions. WordBASIC and Visual BASIC for Applications (VBA), the macro programming languages used in different versions of Word for Windows, are both capable of including calls to Windows API functions and file operations. In turn, virus writers can use these calls to inflict grave damage to user files. For instance, it is easy to write a macro that will automatically delete all sorts of important system files whenever the macro fires.

Many Windows products include a macro language, and the majority of these languages are already capable of making the same type of damaging system calls. You can create precisely the same effect as the "Prank" macro with an Excel macro written in VBA, or in a WordPerfect for Windows macro. Developers extend macro languages all the time to make them easier to use and less programming-centric. These developments make system administrators nervous, because users do not exercise the same level of care and attention when they deal with documents or spreadsheets. The lack of care when opening documents is perhaps natural, because so many documents flow around a messaging system, but it means that viruses created as document macros spread rapidly once they've been introduced into an installation.

10.10.2 The Melissa virus, Outlook, and variants

Everyone in the email world received a wake-up call when the Melissa virus appeared on March 26, 1999, as the payload in a message that had the ability to replicate itself and infect other servers. Melissa was the first virus to exploit features in MAPI and Outlook and caused a huge amount of concern within the Exchange community. Other similar viruses, such as "Papa," which used a variation on the approach to accomplish much the same effect, followed Melissa to add to the workload of harassed system administrators. The Melissa virus initially appeared in a message posted from an America Online account to the alt.sex bulletin board and spread rapidly, perhaps helped by the popularity of this Internet. Microsoft and other companies with major deployments of Exchange had to stop Internet connectivity until they could disinfect servers.

The New Jersey authorities tracked down David Smith, the author of the Melissa virus, in April 1999 and charged him with four counts of violating state computer laws for "interruption of public communication." His lawyer, Edward F. Borden, Jr., pleaded that Melissa did not cause damage because no data was corrupted or files deleted. Indeed, all the virus had done was to send a relatively innocuous message to 50 other people. No mention was made of the cost of isolating and removing the virus from documents around the world or the frantic overtime worked by system administrators to keep their messaging systems up under the strain of the attack. Smith eventually pleaded guilty in December 1999 and received a 20- month prison sentence with a $20,000 fine in May 2002, with the judge explicitly noting that a prison sentence was necessary to deter other would- be hackers.

The second major attack that exploited MAPI and Outlook came in early June 1999 with the Worm.ExploreZip virus, which launched a much more destructive attack on servers, because the virus deleted files on the infected PC, including any Word, PowerPoint, or Excel documents that it could find. The infected message deposited an executable on the PC to search out files on disks, including network file shares. Once located, the virus replaced files with useless zero-byte-length files.

Programmers also seemed to be high on the Worm.ExploreZip hate list, since common source code files for programs that you'd expect to find on PCs used for development (C language header and source files, assembler programs, and so on) were also infected. Users did not realize that the virus had affected their files because the files still seemed to be in place. It was only when users attempted to open the useless zero-byte-length files that the dreadful effect of the virus became apparent. Some companies lost gigabytes of information before they managed to stop the attack. Good backup procedures saved the day for some people, but many users lost the complete contents of their local drives.

The Nimda virus (2001) raised the bar higher by attacking servers on multiple fronts through file shares, IIS, Outlook, and Outlook Express. Nimda inflicted enormous damage on many corporations and stopped some operations dead. The threat continues, and there is no sign that the bad guys will stop their attempts to come up with new attack techniques any time soon.

10.10.3 Luring users toward infection

Apart from the impact wreaked by code in virus payloads, virus authors attempt to exploit human weaknesses by making their messages appear as normal as possible. The aim is to lure users into opening the infected attachment and so cause the attack to proceed. The first viruses, such as Worm.ExploreZip and Melissa, used the "trusted sender" technique to convince users to drop their level of vigilance. The payload message appears to come from a trusted correspondent and contains information that you might reasonably expect to receive. In the case of Worm.ExploreZip, the attachment had a WinZip icon and exploited the human fallibility that we all tend to open attachments we receive via email from trusted sources without thinking about what the attachment might contain. The attachment is not a true zipped file. Instead, the attachment is a hugely destructive program!

It is only natural for users to open any message with a subject that appears to be important, and curiosity is enough to make them complete the task by opening the infected document. The Melissa virus lured people to open the document by including the text:

"Here's the important document you asked for… don't show it to anyone else ;-)."

Once the user opened the infected document, the virus lowered the security settings for Word to allow macros to run automatically when the user opened documents in the future. In other words, users would not be asked whether they wanted to run macros—the code would just execute! The author of the Worm.ExploreZip virus clearly studied Melissa and copied some of the techniques. In this case, the text that lured users is:

"Hi <User>     I received your email and I shall send you a reply ASAP. Till then, take a look at the attached zipped docs."

How many users would have a second thought about opening the attachment? The Papa virus exploited another human failing: to trust instructions that come in messages, especially if they come from apparently trusted sources or the computer tells them to do something. This virus instructed users not to disable the macros in the Excel attachment when they opened the attachment. The aim here was to execute the virus contained in the VBA code. Other viruses instructed users to enable ActiveX controls in Internet Explorer to allow some processing to continue. It is relatively easy for administrators to warn users about messages with specific attachments or subjects, so current viruses make things harder by changing attachment names, subjects, and message content using randomly generated text. When this happens, people can no longer manually detect infected messages. Antivirus software recognizes viruses through patterns of data and other hallmarks and are not fooled by switching words around.

It did not take long before email viruses moved from being not particularly destructive to inflicting massive damage on a user's desktop. First-generation email viruses swamped email networks and often caused servers to come to a complete and total halt while administrators ran disinfection routines. Viruses continue to swamp networks, cause server shutdowns, and delete hundreds of important files. Each time a new virus appears, administrators have to disable external connections and disrupt the flow of email in and out of the company, which obviously has an immediate effect on communication. Users expect email to be available all the time, and they expect messages to go immediately. Once connections are closed, huge queues accumulate and it can take several hours for normal service to resume, with an obvious domino effect on user productivity and cost to the enterprise.

10.10.4 The dangers of HTML

HTML-formatted email has dangers of its own. A virus carried around in HTML code within an email has not yet appeared, but the danger exists. If you examine the VBscript code shown in Figure 10.45, you can see some simple HTML code that you can compose in FrontPage and then paste into an auto-signature file. As it happens, the code is not very exciting. It is an edited version of code from messages posted to the Internet mailing list for Exchange, so it is a real example of the types of messages that people are already sending. When executed, the HTML commands add a set of command buttons to the bottom of a message (Figure 10.46). The intention behind the command buttons is very laudable, since they act as pointers to different Web sites, but a real danger exists in the processing that could occur when users click on a command button when they do not know exactly what will happen next. For example, the code could connect to a Web site and download an executable to the PC. Equally, the command button could execute code to delete messages, send some email, remove all of your personal contacts, and other unfriendly acts. An infection could even add HTML code to everyone's auto-signature file and propagate itself in that manner.

Figure 10.45: Creating HTML code with Microsoft FrontPage.

Figure 10.46: HTML code creating command buttons in a message.

There is no good way to stop users from including HTML code in their auto-signature files, although Outlook 2003 includes a feature called External Mail Content Control, which you can use to block users from loading images and other external content referenced in HTML code inside messages. This feature blocks a trick that some spammers use to avoid detection, where they send messages that seem innocent but contain links to load content at viewing time. If spam can slip underneath your guard, it is fair to say that content that is more malicious can as well. If your antivirus tool does not proactively scan for dangerous HTML content, you can moderate some of the danger by:

• Education: Tell users not to click on command buttons displayed in messages.

• Administration: Since programmers and administrators are the most likely people to use HTML code in auto-signature files, you should provide guidance about the potential danger of such code to these people.

• Enforcement: If necessary, you can amend Windows login scripts to search for HTML auto-signature files in user directories and delete any found. Auto-signature files are stored in the directory:

  \Documents and Settings\Username\Application Data\ Microsoft\Signatures

Detecting HTML-enabled viruses transmitted in the body of messages is a challenge for antivirus products. Before making a decision on which antivirus software to deploy to protect Exchange, ask vendors how they deal with this danger, along with all the other points on your antivirus checklist. Good products will either be able to identify and disinfect problems in HTML or have clearly defined plans outlining how they will do this in the future. Vendors of second-rate products will not even be aware of the problem and will be unable to begin to discuss possible solutions, while vendors of leading-edge products will be working on a solution and will possibly combine message body scanning with other interesting features such as content management. This means that the scanners can examine the body of outgoing and incoming messages for profanities or other unacceptable content as well as potentially damaging code. It is an area that can be expected to develop greatly to keep pace with new probes and attacks from virus authors.

10.10.5 The damage caused by viruses

Despite the workload it generated for the many harassed system administrators, the Melissa virus and its followers did some good. It gave a wake-up call to everyone who was not running AV software and forced those who did to update their pattern files. More importantly, it illustrated the inherent danger that comes from a dependency on an integrated suite such as Office. In this instance, attackers used one component (Word) to exploit the fact that VBA code could use Outlook to dispatch infected messages. Melissa really did not do much damage—its effect could have been much worse, a point that rapidly became apparent when later viruses arrived.

Virus authors continue to explore new techniques or variants of previous attacks—all you can expect is for threats to continue to occur. Now that email is a proven viable method to distribute viruses, an increasing number of "me to" or developments of existing code-based virus attacks occur. The "Love Bug" virus, first reported in early May 2000, is a classic example of a combination virus and worm that caused enormous grief for major corporations, including Microsoft, and high-profile establishments such as the British Houses of Parliament. AV professionals regard Love Bug as a virus, because it inserts code onto a PC's hard drive to pull additional infective code from the network; it is a worm, because it replicates over the network. Unlike Melissa, the Love Bug virus depends on Windows scripting to locate Outlook on a PC and send it commands to generate messages to infect other users. A particularly nasty piece of the virus creates a new home page for a browser with code to steal passwords and email for the virus author. Unhappily (for the authors), the code is easy to interpret (save the code as a text file and open it with Notepad or another text editor to examine what it does), and the email address in the code gave the first clue regarding where to look for the culprits, eventually leading to a number of students in the Philippines.

The Love Bug attack was easy to detect, because not many people send each other Visual BASIC script files, so the arrival of such a file in a message titled "I love you" should have heightened suspicions. Unfortunately, many users have become so accustomed to receiving and launching attachments of all types in messages that they probably would not have known or noticed the Visual BASIC script icon on the attachment. The Love Bug virus set new records in terms of the speed of propagation and evolution of variants, with five additional variants reported in the wild in the days following the original attack. Variants seen since include an invoice for a Mother's Day gift, with the attack provoked when a user clicked on the icon to view the purported invoice, and others with subjects such as "Joke for you." In all cases, the viruses exploited human frailty and curiosity, relying on people's desires to read about interesting items that had nothing whatsoever to do with work. In some respects, the success of these viruses is similar to the success of hunters who lure animals into traps with tasty morsels of food.

Since Love Bug, we have seen many more attacks. According to Sophos, Klez and Bug Bear were the most widespread viruses in 2002. The persistence of viruses has changed. Love Bug appeared and disappeared very quickly, because virus checkers were able to eliminate infected messages very effectively. On the other hand, Klez topped the monthly chart for most popular viruses (an oxymoron in itself) for seven months in 2002. This proves both the extra persistence gained through better disguising of pay- loads and a worrying lack of discipline in terms of maintaining antivirus patterns that may have let viruses slip through long after the antivirus companies identified their signatures and released pattern files that companies could deploy to stop the viruses.

As horrible as the thought is, we may not have seen the worst yet. Imagine the damage if the code in a new virus searches your PC for documents marked "Important" or "Confidential" and then attached them to messages sent to your competitors or posted them to an Internet mailing list. We have already seen email-enabled viruses that are capable of mutating, when they change the contents and subjects of messages to get around the warnings issued to look out for specific attachments or message subjects.

User education about the dangers of viruses is not something that happens overnight, nor does it come about through a one-off class given to people when they become Exchange users. As we know from email viruses, new threats appear all the time, and administrators both owe it to their users and can save themselves a lot of time and effort through good communication and advice. As an example, here are four simple tips that can be given to users to help stop people from opening suspect attachments.

• Do not open an attachment if it does not seem to belong with the message. For example, if the message contains a small amount of text saying something like "Hi, how are you today?" and no attachment is mentioned, any attachment is suspect and should be treated with caution.

• Do not open an attachment if you would not expect to get it from the sender. The Melissa virus is transmitted through messages that state "Here's the important document you asked for… don't show it to anyone else ;-)." If you do not expect to receive an important document from the sender, then the attachment is suspect.

• Do not open attachments received from unknown correspondents. If you receive something, reply to the sender and ask him or her what the document is all about before opening it.

• Do not open an electronic greeting card from anyone, no matter how happy you feel about the sender or the particular time of year.

The last point is critical. Users should be encouraged to stop sending electronic greeting cards that attach executable programs. People have been sending these types of messages for years, but the early examples were composed of either simple text or escape character sequences that caused the terminal to display primitive graphics. No great harm came about from these messages, even if they took up almost 50 KB of valuable network to send. Today's executables, which are far more charming and cute, take up even more space and can hide a virus. Users need to be on their guard at holiday time, when electronic greeting cards are at their peak.

Microsoft has now addressed many of the concerns about how Outlook handles attachments that could contain harmful code, but there is no doubt that virus authors will attempt to exploit any possible weaknesses both in software and user behavior, so this is good enough reason to track any hot fixes that Microsoft releases for Outlook on a regular basis.

Email viruses are not very new. Back in the days of "green screen email," the IBM Education Networks BITNET and EARN and the IBM internal VNET networks were hit by a similar "worm" in 1987. Users received a message with a batch file embedded at the bottom of the file. The start of the file had instructions on how to save the message to disk and run it. It claimed it would then display a "Christmas Tree" on the user's terminal. What it actually did was mail itself to every one in the user's "Nickname" file, the equivalent of today's "Contacts" folder.

Administrators need to keep up-to-date with threats as they develop. You browse the security bulletins posted on sites such as http://www.ntsecurity.net/, http://www.cert.org/, or http://www.sar.com/, or have messages sent to you from alert lists.^[6] Of course, an obvious problem with an email alert is that it may not get to you or to an administrator who can action the alert if a virus has already attacked your mail server. In general, independent security advice is better than that offered by AV vendors. There have been suspicions in the past that vendors have stirred the pot of controversy by announcing the arrival of new viruses that their product has detected first or maybe even uniquely! Sometimes these viruses are real, and sometimes the viruses never appear outside the vendor's software laboratory.

10.10.6 Multistage protection

Document-borne viruses are a major challenge for messaging system administrators, especially so in the case of systems such as Exchange, which place a high degree of importance on information sharing through distributed document repositories such as public folders. What can you do to defeat the best efforts of document virus creators? There are three basic ways to detect viruses:

• PC-based: Deploy AV software to all PCs to check as users create and copy files. These products do not understand the structure of Exchange files such as PSTs and OSTs, but they will stop users from creating infected files before attaching them to messages. Make sure that you regularly update AV pattern files on all PCs so that the software can detect new viruses.

• Store-based: Deploy Store-based AV software to ensure that any viruses that arrive via email are detected and disinfected before they have a chance to spread. Know if the AV software is unable to cope with specific format or message types and determine how you can protect your servers. For example, can the AV software scan for viruses in ZIP files? If not, maybe you want to block all ZIP files at the perimeter of your messaging infrastructure. How do you scan encrypted messages? There is no good answer for this problem today, but at least you can console yourself with the fact that the mass virus attacks do not usually cloak themselves in a layer of encryption, because the virus authors want to generate easily accessible messages.

• Perimeter-based: Consider deploying AV software that scans incoming SMTP traffic before messages arrive at Exchange. You can combine AV protection with other barriers, such as antispam measures, to ensure that only acceptable email penetrates inside the company. Note that these barriers will not stop infected messages from arriving through connectors such as X.400 or Lotus Notes. In these situations you depend on the administrators of those systems to deploy adequate protection to eliminate most viruses; you also rely on your Store-based AV software to detect any viruses that creep in.

If you use front-end servers, you probably do not need to run antivirus scanners on those servers, since you can leave the scanning and disinfection to Store-based products that run on the back-end servers. However, it is a good idea to consider running antispam and content scanners (including blocks for suspicious files and attachments) on the front-end servers, so that the only messages that pass to the back end are those that absolutely need to get through. Best practice is to erect barriers at multiple levels of the messaging system and desktop, so that if a virus manages to get past one check, checks at the next will detect the virus. Combining multiple levels of protection creates a more resilient solution, and the combination of Store- and perimeter-based checking is an excellent way to catch the vast majority of viruses. (See Figure 10.47.)

Figure 10.47: Changing the security settings in Outlook 2002.

Despite recent virus attacks conducted via email, some managers balk at the investment required to deploy multitier virus checking. It is true that the licenses for virus checkers can be expensive, especially when you have to deploy across multiple servers, but this should not be a reason to attempt to take any budgetary shortcuts. The current generations of Windows and Exchange allow you to consolidate servers into a smaller number of computers, and if you take the opportunity to consolidate, you can save a great deal of money in software license fees for add-in products such as virus checkers. Even so, the cost to deploy virus checkers can still appear high to the untrained eye, especially when it does not make a direct contribution to the company's bottom line. With this in line, you need an argument to convince doubters that the investment is worthwhile.

Consider this scenario: Dealing with an infected message is a major hassle, and you may lose the email service for a day or so while you take servers offline for disinfection. However, sending an infected message to your business partners is a sure way to demonstrate that your company has a very low degree of attention to detail and does not care very much about secure business communications. A company that dispatches infected email regularly is clearly not one that you would care to do much business with; there is usually a competitor in the same business that manages its email correctly. No businessperson likes to think he or she might project a bad company image. Yet now that so much communication is via email, why take the risk of projecting an image of ignorance and bad management to customers? Enough said. Make sure that you scan every outgoing message for viruses in the same way as every incoming message is checked. Protect your business and your company's image by investing in good antivirus tools. From a purely organizational perspective, administrators need to agree on a common protection policy across the organization. It does not make sense to run multiple AV products, since this makes tracking updates more difficult. A simple policy includes the following:

• Agreement on the levels within the messaging infrastructure where antivirus products are installed: desktop, server, and backbone

• Agreement on how to secure servers by applying lockdown tools or closing off potential holes. For example, you should avoid creating file shares on an Exchange server to minimize the impact of a Nimda- type attack.

• Agreement on the antivirus products in use and the version of that product to use on production servers

• Full details of who is responsible for monitoring sources such as newsgroups, antivirus Web sites, and internal sources for information about virus outbreaks, as well as how this information disseminates to both administrators and users. It is easy for administrators to focus on the need to protect servers and stop new viruses from arriving. However, if you do not tell users that a virus is in the wild and active, their level of vigilance will remain low and more will become infected. Do not depend on email being available to distribute bulletins about new viruses, because it may be necessary to take down servers to disinfect databases or stop connectors between routing groups or to the Internet to prevent further spread. You should have some alternatives in place to ensure that as many people as possible know about a virus and can react accordingly.

• Be sure that you do not cause unnecessary panic by reacting to every new report of a virus attack, because an increasing percentage of such reports are hoaxes. Some hoaxes have advised users to delete specific files from their PCs on the pretext that the files are infected, only for users to discover later that the files are essential . . . such as a Java virtual machine.

• A mechanism to distribute new virus patterns across all servers in the organization

• Agreement on how to test new versions of antivirus products against new versions of Exchange and other associated products (such as new editions of IIS or Windows). Some products are sensitive to the version number of a specific component, such as STORE.EXE, and will stop working if you install a patch that increments the build number for the module. You need to be sure that the procedures for implementing a patch from Microsoft incorporate a check for antivirus support.

  Table 10.5: Details of an Antivirus Protection Policy

  Protection	Achieved through . . .
  Firewall Filter	All SMTP entry points into the company are able to filter, quarantine, or reject messages based on string comparisons against header or attachment names.
  Store	Sybari Antigen runs on mailbox servers to protect against any infected messages that sneak through the firewall.
  Store Cleaning	If the Store protection fails to detect a new virus, perhaps because the pattern file is out-of- date, utilities from Microsoft are available to remove messages from a Mailbox or Public Store based on strings in the header, message body, or attachment names. Jobs to clean a server can be launched from a central location.
  Voicemail	After a virus attack begins, users receive voicemail notifications to warn them against opening infected messages.
  Email	To back up the voicemail and inform users who may be out of the office, automated distribution lists are used to send flash messages to inform users that a virus attack is under way and tell them what action to take if they receive an infected message.
  Global Response	When an attack happens, individuals from key internal functions around the world convene via con-call to collect data, determine the actual status, and coordinate an appropriate response. These individuals also check that the virus is not a hoax and check sites such as www.sophos.com to validate newsflashes about new viruses.
  Desktop	Separate antivirus utilities run on Windows-based desktops to guard against infected files.

As an example of how to incorporate the principles outlined into a protection policy, Table 10.5 lists the steps used by a large company to protect its Exchange environment against attack. As you can see, they achieve protection through a combination of software and people action, all coordinated into multilayered protection.

One mistake with a virus can be very expensive, with damage running well into millions of dollars for even a small organization. Disinfecting a system, especially a large networked system, will take a lot of time and effort, and it is probable that the system will be unavailable to users while you eliminate the viruses.

^[6] . You can subscribe to the Windows 2000 security alert list by sending an email to [e-mail] with the words "subscribe securityupdate anonymous" in the body of the message (without the quotes).

---