E-mail Defenses in Windows Vista

Convert All E-mail to Plain-text

Unless you use e-mail clients that significantly restrict the permitted HTML tags and active content in HTML-based messages, all incoming and outgoing e-mail should be converted to plain-text, removing any potentially malicious HTML-enabled content. In many cases, this should be done regardless of the client. In Windows Mail, e-mails can be converted to plain-text when incoming, outgoing, or both. It is more important to convert all incoming e-mail to plaintext. Enable the Read all messages in plain text option, as shown in Figure 1.

Figure 1: Windows Mail can convert all messages to plain-text.

Most corporate mail systems can also convert all mail to plain-text. When enabled, this type of feature will strip all non-plain-text content. In Windows Mail, it also attaches the original HTML content to the e-mail message as a separate .htm attachment (see Figure 2). Any arriving legitimate, HTML-enabled e-mail can be converted back to its original HTML content by launching the .htm file attachment.

Figure 2: Windows Mail preserves the original HTML content as an HTML attachment.

Few, if any, corporate mail systems permit preservation of the HTML content in the way Windows Mail does, and it is questionable whether this is desirable in the first place. In most mail clients, conversion to plain-text is a one-way operation.

Although not as important as disabling inbound content, a user can also disable any non-plain-text content on outgoing e-mails. Enable the Plain Text options, as shown in Figure 3.

Figure 3: You can also use plain-text for all outgoing messages.

You might wonder why this option is needed, as if the user would be creating and sending their own malicious content. Malware writers have created e-mails that launch their malicious content only when replied to. The inbound e-mail contains scripting that is activated only when the user replies to the message. The malicious e-mail will contain a legitimate social engineering-enabled message that induces the receiver to respond. For example, it may claim that the user's check has bounced against some unknown online auction. Unsuspecting users may reply to tell the sender that they are mistaken. When the user replies, the malicious content gets activated. This allows the attacker to potentially bypass inbound content removal mechanisms, and still give them a chance to activate malicious code during the reply.

Execute All HTML Content in the Restricted Zone

If HTML content must be displayed in e-mail, make sure it is rendered in Internet Explorer's Restricted zone. By default, as shown in Figure 4, all e-mail content is displayed in Internet Explorer's Restricted sites zone.

Figure 4: Ensure that your mail client reads all mail in the Restricted sites zone.

This is also the default setting in Microsoft Outlook as well, and should be set as the default in any e-mail client. In fact, it should not even be an option that can be modified. By default the Restricted sites zone disables most active content, including scripting, ActiveX controls, and other binary objects. In order to change the behavior of rendered content in an e-mail, the user would have to modify the security permissions set in Internet Explorer for the Restricted sites zone or choose to enable the Internet zone as Windows Mail's default security zone (not recommended). Also, as shown in Figure 4, Windows Mail has a configuration option that allows the user to be warned if malware programmatically attempts to send e-mail out in an attempt to infect more e-mail recipients. This option attempts to prevent many types of e-mail worms and viruses, although these days most e-mail malware comes with its own built-in e-mail engines.

Disable Automatic Downloading of HTML Content

Spammers often include a link to a small, 1-pixel, transparent graphic file (called a web bug) that is quickly, and "silently" downloaded in the background when a spam e-mail is opened. The referenced file is uniquely named for each e-mail sent out by the spammer. When an affected user opens the spammer's e-mail, if the user's e-mail client downloads the referenced picture, the user's e-mail address is confirmed as a valid address (and potentially exploitable). The spammer then sends the user a lot more spam and sells the now verified, active e-mail address to other criminal and unsavory types.

Windows Mail defeats web bugs by refusing to download referenced content. The "Block images and other external content in HTML e-mail" option (as shown previously in Figure 4) prevents Windows Mail from downloading any externally referenced content.

Remote attackers can even place the web bug on a rogue Internet Information Service (IIS) server and require client authentication. In early versions of Internet Explorer on non-Windows NT-based platforms, (prior to IE 5.5), the e-mail client would silently transmit the user's current logon name and password to the remote Web site, where it was recorded. Now, Microsoft e-mail clients and Internet Explorer only automatically transmit the user's logon credentials in local intranet Web sites. As Figure 5 shows, Internet Explorer's Restricted sites zone, where HTML e-mail is rendered by default, will always prompt the user for their logon name and password any time it is requested. This default can be modified, although it should be left alone in most cases.

Figure 5: For sites and e-mail messages in the Restricted Sites zone, the user is prompted for her username and password.

Filter Out Dangerous File Attachments

All potentially dangerous file attachment types without a legitimate business purpose in the organization should be blocked by default.  To secure e-mail, all file extensions not expressly approved for legitimate use in the environment, should be blocked by default (i.e., a block-by-default rule). Which extensions are included should be guided by the organizational risk management strategy.

Unfortunately, Windows Mail and Microsoft Exchange Server do not allow file extensions to be blocked-by-default easily. Instead, a block-by-exception mechanism is used. The "Do not allow attachments to be saved or opened that could potentially be a virus" option (shown previously in Figure 5) will prevent 44 high-risk file types from being made accessible in Windows Mail, using the Attachment Manager (AM) functionality first shipped in Windows XP Service Pack 2.

By default, AM blocks the following file extensions:

• .ade

• .adp

• .app

• .asp

• .bas

• .bat

• .cer

• .chm

• .cmd

• .com

• .cpl

• .crt

• .csh

• .exe

• .fxp

• .hlp

• .hta

• .inf

• .ins

• .isp

• .its

• .js

• .jse

• .ksh

• .lnk

• .mad

• .maf

• .mag

• .mam

• .maq

• .mar

• .mas

• .mat

• .mau

• .mav

• .maw

• .mda

• .mdb

• .mde

• .mdt

• .mdw

• .mdz

• .msc

• .msi

• .msp

• .mst

• .ops

• .pcd

• .pif

• .prf

• .prg

• .pst

• .reg

• .scf

• .scr

• .sct

• .shb

• .shs

• .tmp

• .url

• .vb

• .vbe

• .vbs

• .vsmacros

• .vss

• .vst

• .vsw

• .ws

• .wsc

• .wsf

• .wsh

All of these file extensions are considered Level 1 or high risk files.

If Windows Mail is being run in the Restricted zone (the default) the user will not be able to access any high-risk file (see Figure 6). If Windows Mail is being run in the Internet zone, the user will be warned and prompted prior to executing any high-risk file.

Figure 6: By default, the user will not be able to access high-risk file types.

The user or administrator can also use group policy to modify the list of high-risk files, define moderate and low risk files, and implement other file attachment parameters. To modify Vista's file attachment treatment, use a group policy object or local computer policy (Gpedit.msc) to navigate to User Configuration\Administrative Templates\Windows Components\Attachment Manager (see Figure 7), and look for the settings starting with the words Inclusion list.

Figure 7: An administrator can modify the behavior of the AM using Group Policy.

You can add file extensions to the high, moderate, and low file types. When you do this, any program that uses the AM, such as Windows Mail and Microsoft Outlook, will act on that file. If left alone, the 40 or so files listed previously are placed in the high-risk file types.

File types placed in moderate-risk setting can be opened in Windows Mail, but the user will be warned. File types listed in the low-risk setting will not prompt the user in Windows Mail. If any file type is listed in the moderate- or low-risk file types is identical to the default high-risk file types, the more specific setting applies (although file types listed in moderate override any conflicts in the low-risk area). However, any files listed in the high-risk area will override any conflicts in the moderate or low risk setting area. File attachment blocking can also be configured in Microsoft Exchange and Outlook (http://www.support.microsoft.com/kb/837388).

There are other important settings in the Attachment Manager container that an Administrator should review and configure.Then use group policy to configure the appropriate attachment blocking policy.

Install Anti-Malware Software

Anti-malware software should be installed in most environments. Defenses should include an antivirus scanner, an anti-phishing product, and an anti-spam filter. Additional defenses can be included as desired. Anti-malware software can be run on the client, on the e-mail server, on a perimeter gateway device, or on the incoming e-mail traffic using an external application service provider (Messagelabs, Postini, and so on).

Disable Plain-Text Passwords

Many e-mail clients, including Windows Mail, will transmit a user's password in plain-text when using SMTP or POP3 connectors (as shown in Figure 10-5 earlier). You can configure Windows Mail (or Outlook or Outlook Express), to protect (i.e., encrypt) passwords by enabling the "Logon using Secure Protected Authentication" option. If possible, use SSL/TLS-enabled protocols instead of plain-text POP, IMAP, RPC, and HTTP. Windows Live Mail also has authenticated POP (APOP).