Because the vast majority of Windows users use Outlook, Outlook Express, or Microsoft Internet Explorer (IE) to read email, I base my discussion on those applications. However, much of what I recommend applies to any HTML-enabled email client.
HTML in Outlook and Outlook Express
Some email and newsreader clients come with their own HTML-rendering functionality, but most integrate with an Internet browser, which performs the rendering. You might use a non-Microsoft client, but it probably uses IE to display the Web content.
Microsoft designed Outlook, with its calendaring and scheduling groupware features, for corporate use, and it intended Outlook Express for the home environment and for users who don't connect to a Microsoft Exchange Server server. But Outlook doesn't include an integrated newsreader for Internet newsgroups—it gains the necessary functionality when you run it with Outlook Express or Exchange. Both client applications include support for SMTP, POP3, and IMAP email protocols and can recognize and render HTML content.
If Outlook or Outlook Express encounters an embedded URL, the client will launch IE in its entirety. The three products are so closely integrated that if you change the security settings in one product, you affect the security settings in the other two products.
Programmers designed early HTML commands to format text, which seemingly didn't leave much room for malicious use. But as HTML overtook the Internet, it grew in functionality and gave intruders more to work with. Form commands, frames, cookies, and encoding character sets offer rogue programmers new avenues for attack. But an intruder's best friend is an Internet-enabled script language. Script languages enable more interaction with an end user's machine (e.g., calling helper programs; downloading, reading, writing, and exploiting files).
To determine whether an HTML email or newsgroup message contains script, examine the source code for the following syntax:
where ScriptLanguageName is a language such as VBScript, and the tags enclose one or more script-language commands. The following three HTML commands can call programming objects such as Java applets, ActiveX controls, or browser plugins:
Dozens of ways exist to use HTML to call different objects, but the methods all share a commonality: They use HTML code to activate or access components that aren't included in basic HTML code. What Microsoft calls active scripting and active content*not plain ASCII text or typical HTML formatting commands*are what you must watch for. Sometimes the active content is encoded with special ASCII characters that conceal plaintext commands. If you receive an email message that appears to be empty, it probably contains "hidden" HTML commands. If the HTML coding includes many percent sign (%) characters, which are indicative of encoding, or links to unknown Web sites, assume that you have received a malicious message. To view embedded codes in Outlook, select View, Options, or select File, Save as and save the email as a text file.
In February 2000, the Computer Emergency Response Team Coordination Center (CERT/CC) and several other organizations released CERT Advisory CA-2000-02: "Malicious HTML Tags Embedded in Client Web Requests" (http://www.cert.org/advisories/CA-2000-02.html), which warned that intruders could trick legitimate Web and newsgroup servers into accepting and distributing a malicious script. An intruder could post a response containing a hidden script to a public Web server or newsgroup that expected only text responses and hadn't implemented the necessary code to check for and remove scripts. The server could then post the intruder's message and embedded script to everyone who subscribed to its service. This injection of scripting code is known as Cross-Site Scripting (XSS). Innocent users would then open an email message or read a newsgroup posting and unwittingly launch an attack.
Don't assume that such attacks are limited to obscure bulletin boards that most Web users don't visit. eBay fell prey to one of the first XSS attacks, dubbed eBayla, in 1999, and new XSS occurrences arise daily. XSS vulnerabilities occur on many of the world's most accessed Web sites, including Microsoft, MSN Hotmail, Yahoo!, AltaVista, Netscape, Amazon.com, TIME.com, InfoSpace, ABCNews.com, CNET, and Google.
You might think that disabling scripting and active content in your email client or newsgroup reader would limit your exposure to such attacks. However, if you use an email or newsgroup client that relies on a browser or its security settings, as Outlook and Outlook Express do, disabling scripting can be impractical and doesn't always work. If you surf the Web with a browser that blocks active content, many Web sites will produce errors. Several browser and newsreader vulnerabilities can force active content to run even when scripting is disabled. So disabling scripting can disrupt typical Web browsing without preventing many malicious attacks*not a great trade-off. The primary responsibility for preventing the majority of XSS attacks lies with server developers, who must ensure that their products don't let malicious users inject into forms HTML code or scripts that then dynamically generate and send content to other users. Responsibility also lies with end users, who must be suspicious of all email and newsgroup messages that contain active content and disable that content whenever possible. You must configure your browsers to prevent malicious execution of files and content.
Does previewing a message in Outlook or Outlook Express permit scripts and active content to run automatically? The short answer, in most cases, is yes for previewing but no for autopreviewing. But your security zone settings govern all subsequent message viewing. The most recent versions of Outlook and Outlook Express disable active content by default. Russ Cooper of NTBugtraq compiled a list of the different treatments of active content in different versions of Outlook and Outlook Express. See Web Table 1.
SMTP and Network News Transfer Protocol (NNTP) look a lot alike, so the similarity between email and newsreader client messages is hardly surprising. Both message types have message headers and bodies, can include attached files, and can contain HTML code. As a result, many of the following email attacks can also exploit newsgroup readers.
Embedded HTML. Malware can try to activate itself from within the body of the message (i.e., it doesn't require that you open an attachment). In 1999, BubbleBoy accomplished this feat by using HTML to exploit a flawed ActiveX control called Scriptlet.Typelib. At the time, most email clients' preview panes automatically ran HTML commands, and the media incorrectly reported that the worm could run even if users didn't open infected email messages. Dozens of viruses and worms have used similar methods to run automatically when you open email messages. Most involve a wrongly marked ("Safe for Scripting") ActiveX control.
In February 2002, the <EMBED> HTML directive I mentioned earlier played a role in a buffer overflow attack. The src variable, which is supposed to contain the path and name of a file, instead contained a long string of characters that crashed MSHTML and resulted in a buffer overflow. See CERT Advisory CA-2002-04 "Buffer Overflow in Microsoft Internet Explorer" (http://www.cert.org/advisories/CA-2002-04.html) to read more about this exploit.
Embedded links. Messages can contain links to malicious Web sites and files. Clicking the URL usually launches IE and activates the rogue programming. One such exploit, which Microsoft Security Bulletin MS02-009 (Incorrect VBScript Handling in IE can Allow Web Pages to Read Local Files) documents, uses VBScript to launch a new browser frame in a new Web security zone. The first frame might open in the Internet zone, but the second frame opens in the minimally restricted My Computer zone, in which local files are vulnerable. Several new HTML attacks seek to fool IE into opening malicious content in unrestricted zones, even if scripting is initially disallowed in the high-security zone. Other link exploits activate browser plugins to open additional exploit opportunities.
Signature injections. The Kak worm, using a novel approach to spread itself, infects Outlook Express signature files. When infected clients send an email message or newsgroup posting, Kak accompanies the message in the signature. Before Kak appeared, many virus scanners checked only the body of messages.
Malformed messages. Intruders have discovered that if they put identification information for an attached file in an incorrect place within the message header, antivirus scanners and email and Internet gateways will overlook the file. Email or newsgroup servers will receive the malformed message and*disregarding Internet Engineering Task Force (IETF) Request for Comments (RFC) specifications*reorganize the message correctly and pass it to the end user. Some security researchers believe the MyParty worm contained incorrect SMTP control codes in an attempt to bypass antivirus gateways.
New Sneaky Attacks
In 2000, after a rash of email worms, Microsoft released the Outlook E-mail Security Update. The update blocked many potentially malicious email attachments, increased default email security to prevent malicious scripting, and blocked other programs (i.e., worms) from using Outlook to spread themselves. The update limits Outlook's functionality, but it also significantly limits your exposure to malicious code.
Virus and worm writers didn't take long to respond. Most new email worms (e.g., Gibe, SirCam, NewApt) now contain their own SMTP engines. These worms infect a client, grab email addresses from Outlook address books, and send themselves out. Security-patched Outlook doesn't let worms use the mail interface, Messaging API (MAPI), to access email addresses, so worms now scour hard disks to find address-book files or find what they need in the registry.
The Taripox (aka Tariprox and Taricone) worm uses another sneaky method*it modifies the Windows domain-resolution HOSTS file so that any SMTP email message travels first to a malicious, locally stored SMTP proxy engine, which can mischievously modify the message. When the worm infects a machine, it looks up the email client's SMTP server name and places the name in the HOSTS file with the loopback address of 127.0.0.1. When the email client sends a message, the email travels to the worm, and the worm attaches itself and resends the message to the intended recipient.
Defending Against Attacks
Defending email and newsgroup readers against potential threats is a tough job. Be sure to install a reliable antivirus scanner on all computers, and instruct end users to update the scanner frequently and to avoid links and file attachments they receive in email messages. However, end users frequently disregard such advice and hostile embedded code often arrives hidden, so you must take several additional steps to minimize the risks.
Install the latest client software versions. The latest email and browser clients have most known security holes plugged. In Windows environments, be sure to update your email client and browser versions together because of their interconnectedness. The latest email clients are wary of HTML code, which is good. By default, Outlook Express 5.5 and Outlook Express 5.0 run messages in the more lenient Internet zone, while Outlook Express 6.0 runs them in the Restricted zone. Outlook 2002 Service Release 1 (SR1) lets you convert all messages you send and receive to plain text.
Apply the latest security patches. Microsoft's Critical Update program lets you automate the update notification process and ease installation hassles. Ten of this year's first 14 Microsoft Security Bulletin patches addressed email problems. Updating pays. However, be sure to consider the trade-offs before installing Outlook E-mail Security Update. The patch is excellent, but your end users might not think so when they discover that they can no longer access certain file attachments.
Strengthen security settings. No matter which email client you use, disable scripting and active content. Considering the risks, I can think of few reasons to enable HTML in email or newsreader clients. Outlook and Outlook Express users should set security to the Restricted zone. If you've installed the latest client versions and applied the latest security updates, scripting and active content are disabled for you. To set security options in Outlook Express 6.0, select Tools, Options and select the Security tab, which Figure 2 shows. Outlook provides similar options under its Tools menu.
Block malicious file extensions. Most people know to avoid the well-known Windows executable types, including .exe, .com, .bat, .pif, and .shs files, as well as the usual script file types, .vbs and .js. But you should instruct your end users to avoid dozens of other file types. They shouldn't click .jse, .vbe, .wsc, .wsf, or .wsh files, which might launch Windows scripting engines. They should also avoid any .jar, .chm, .class, or .hta files. All these file types have the potential to be malicious.
However, you can't assume that your end users won't click file attachments; you must block known malicious file extensions, either at the client or at an Internet gateway. The Outlook E-mail Security Update blocks a few dozen file types, but you should add many more file types to the list. For example, I can't think of a legitimate reason for an end user to send an .eml file, although Nimda sure had fun with it. As a security administrator, I block all potentially malicious attachments until they are proven innocent. If an end user needs a blocked attachment, I can help him or her retrieve it. But I deny by default.
You can use a template on the Exchange server (or set registry subkeys on Outlook 2002 clients) to block specific file types. See the Microsoft article "OL2002: Cannot Access Attachments" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q290497) for more details. To block file types in Outlook Express 6.0, select Tools, Options, Security and, under Virus Protection, select the Do not allow attachments to be saved or opened that could potentially be a virus check box. See the Microsoft article "OLEXP: Using Virus Protection Features in Outlook Express 6" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q291387) for more information.
Reveal file extensions. Windows hides known file extensions by default (e.g., picture.jpg.exe appears as picture.jpg). To change this behavior in most Windows versions, open Windows Explorer; select Tools, Folder Options; select the View tab; clear the Hide file extensions for known file types check box; and click OK. Even after you make this adjustment, Windows continues to hide selected extensions (e.g., .shs). To see these files, open Windows Explorer and select Tools, Folder Options, File Types. Select a file extension, click Advanced, and select Always show extension. Repeat this process for each file type. (These steps vary slightly among different versions of Windows.)
Use Outlook instead of Outlook Express. Outlook doesn't have an integrated newsreader, but it has proven itself more resistant than Outlook Express to malicious exploitation over the years. Microsoft is making Outlook Express safer, but it remains something of a security stepchild.
Use a scanning email service. Several companies offer to scan your email messages before delivering them to your Inboxes. MessageLabs, for example, has had such success in preventing viruses from spreading that security experts use its virus scanning counter to determine whether a particular piece of malicious mobile code exists in the wild. MessageLabs says that it finds malware in 1 of every 450 messages.
Scan workstations for SMTP. If you run Exchange and Outlook, consider scanning your workstations for port 25 (SMTP) communications. Outlook uses remote procedure call (RPC) to connect to Exchange servers, and Exchange servers use port 25 to connect to other SMTP servers. Typically, a workstation shouldn't be using port 25 to communicate. Such activity might indicate the presence of malware.
Use a fake email address as a warning tool. Some email users have realized early warning benefits from inserting a fake email address at the top of their address or contact lists. When a malicious email program tries to send a message to this address, you receive an undeliverable message. Receiving such a message might be an early indication that an email worm is active. I call this tactic a trick because it doesn't always work and can't stop malicious code.
Email and newsgroups will remain a primary malware battleground for the next few years, with Internet-surfing Trojan horses coming on strong. Public email and newsgroup servers that permit XSS abound. Vulnerabilities can take the form of file attachments, malicious links, buffer overflows, and maliciously embedded scripts. You must disable all active content and block potentially malicious file attachments on all email and newsgroup clients. You diminish your risks significantly when you upgrade clients, apply security patches, and implement the appropriate settings.