Better OWA Attachment Security

Microsoft Outlook Web Access (OWA) is a useful tool for giving remote or mobile users access to their Outlook mailboxes. Although OWA lacks some of Outlook's features, the overall user experience is similar to that of Outlook and is a reasonable alternative. However, some of the functionality that makes OWA useful and convenient also raises some security concerns—among them fears about attachment safety, either from sensitive information getting into the wrong hands or from malicious content that can harm a user's PC or the network. But rather than deny users the ability to use OWA to remotely access their mailboxes, you can take some steps to help secure OWA attachments and reduce the security risks involved. You can also plan ahead to take advantage of some new attachment-control features that Microsoft has included in Exchange Server 2007.

OWA Attachment Handling
When an OWA user receives an email message containing an attachment, the user can perform one of three actions:

• From within the browser, the user can right-click and save the attachment. This behavior is purely a function of the browser and has nothing to do with OWA.
• From within the browser, the user clicks the attachment link, and the browser displays a dialog box that asks whether the user wants to save or open the file. If he or she chooses to save it, the browser saves the file—again without OWA being involved.
• The user chooses to open the document, in which case, OWA sends an HTTP header to the browser indicating that the document expired the previous day. This causes the browser to not cache the document, although it might write the document to a temporary file area on the hard disk.

Note that in the first two cases, OWA has no control over what happens to the file. If the user chooses to save the file, the browser will simply ignore the "don't cache this" header. Even if you manually add the Cache-control: no-cache header to the Exchange virtual directory, users will still be able to save attachments. To amend this behavior, you can take advantage of OWA 2003's attachment-control features to prevent users from being able to open the attachments. To be specific, with OWA you can

• customize the list of file types that are completely blocked and those that can be opened only after saving to disk. This capability parallels the controls you get in Outlook when you install the Outlook Security Features Administrator Package.
• control whether users can access documents saved directly in public folders.
• restrict which servers users can use to access attachments.

These controls help prevent users from opening malicious attachments, and they give you a degree of control over where users can open attachments that might contain sensitive or proprietary data.

Blocking Attachments Depending on File Type
The first line of attachment control is restricting the types of files that users can open directly from the email message. This capability came about because Outlook users have shown a distressing tendency to open malware programs disguised as legitimate attachments. By making some file types unavailable in Outlook and requiring users to save other files to disk before opening them, the Outlook development team successfully blocked several potential attack vectors. OWA implements these same controls.

Attachment types that are completely unavailable are known as Level 1 file types; attachment types that users can save to disk but not directly open are called Level 2 file types. You can use a registry setting to control which file types are in each category. By adding the Level1FileTypes and Level2FileTypes values (of type REG_SZ) under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA registry subkey and setting the value of each to a comma-delimited list of the attachment types you want in that category, you can force OWA to block certain file types or force users to save them to disk first. For example, if you want to specify Perl (.pl) scripts as a Level 2 file type, perform these steps:

1. Log on to your OWA server with an account that has Windows administrative privileges.
2. Open a registry editor (regedit.exe).
3. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\MSExchangeWeb\OWA.
4. Double-click the Level2FileTypes entry.
5. When the Edit String dialog box ap- pears, scroll to the end of the string and add, "pl" (without the quotes). Click OK.

You can also customize the Level1MIMETypes and Level2MIMETypes, which instruct the OWA server to block attachments according to the MIME type of the file delivered by the server. This feature is useful if your users frequently work with messages that contain links to content that doesn't contain extensions (e.g., Macintosh-format files on a Windows file server) because you can block the MIME type that corresponds to the file content no matter what the actual file extension might be. It also helps protect you against situations in which the extension of an attachment doesn't match the true MIME type; malware payloads sent via email often contain misleading extension information that attempts to fool users and antivirus software. To customize the MIME types used for filtering, use the steps outlined for customizing the Level2FileTypes value, except you'll modify the appropriate Level1MIMETypes and Level2MIMETypes values.

Controlling FreeDoc Access
Public folders can contain many different data types. After Exchange 2000 Server shipped, the fact that public folders supported direct access via WWW Distributed Authoring and Versioning (WebDAV) led many organizations to store documents directly in public folders—not as attachments to posts in those folders, but as raw documents. Microsoft calls these documents FreeDocs, and they raise a security problem. FreeDocs can have embedded macro code that will execute in the local security context of the browser when someone opens the document. Exchange Server 2003 blocks FreeDoc access from OWA out of the box. You can override this behavior by adding a new REG_DWORD value named EnableFreeDocs under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA, then customizing its value. You can set the value to

• 0 to block all FreeDoc access from within OWA (OWA's default behavior). However, this setting doesn't stop Microsoft Office users (or others using WebDAV–capable applications) from creating and opening FreeDocs.
• 1 to block FreeDoc access from front-end servers but allow access via WebDAV and via back-end servers.
• 2 to allow FreeDoc access from back-end servers and from front-end servers whose names appear in the AcceptedAttachmentFront Ends value. You specify the set of allowable front-end servers by creating or adding to a comma-delimited list that includes the Fully Qualified Domain Name (FQDN) of each server. The list should go in a REG_SZ value named HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\AcceptedAttachmentFrontEnds.