Understanding Outlook s Security Features

Understanding Outlook’s Security Features

There’s often a tension between convenience and security, and that’s particularly true of the security features introduced in the Outlook E-Mail Security Update for Microsoft Outlook 98 and Microsoft Outlook 2000. (The update’s features are built in to Microsoft Outlook 2002 and later versions.) The goal of the update was to add features to Outlook to limit the spread of e-mail-borne malware; unfortunately, this required restricting users’ ability to access some kinds of attachments, like executable files and VBScripts. In addition, the security update causes Outlook to warn users when external programs (from both Microsoft and third parties) try to access certain properties and methods; this has had a much greater impact than the attachment security changes in some corporate environments. Fortunately, administrators can customize the update’s behavior through an Exchange public folder, and end users have some ability to customize attachment handling on systems where administrators aren’t imposing control.

The Outlook Security Update

The security update (which is what I’m going to call it, even though it’s included in the current version of Outlook) includes five major changes:

• Improved attachment security. Outlook blocks access to some file types altogether, including .exe and .pif files and screen savers. Administrators can specify a second, less restricted set of file types that can’t be opened directly, but can be saved to disk.

• The ability for users to control programmatic access to the address book and to Outlook’s mail-sending functionality.

• Support for letting administrators specify which sources for code and add-ins should be trusted. Note that this feature is only available in Outlook 2002 and later versions; it’s not present in the security updates for Outlook 2000 and Outlook 98.

• A change to the default security zone in which Outlook runs.

• Code on unpublished or one-off Outlook forms does not run unless specifically allowed by the Exchange administrator.

Attachment Security

As a technical solution to what is largely a behavioral problem, Outlook 2002 checks the file type of each message attachment against an internal list of file types. A default list is included with the product, as shown here, but you can override or customize this list using an Exchange public folder.

• Level 1 These file types (including .bat, .exe, .vbs, .lnk, and .js) are blocked by Outlook. Recipients get a warning InfoBar listing the blocked files (see Figure 13-1) when they open or preview a message with a Level 1 attachment, but they can’t see or access the attachment themselves (at least through Outlook; Outlook Web Access, Post Office Protocol [POP], and Internet Message Access Protocol [IMAP] clients still allow access to Level 1 files). Table 13-1 lists the Level 1 attachment types.

  
  Figure 13-1: Blocked attachments are still in the store, but users can’t access them through Outlook.

  Table 13.1: Level 1 File Attachment Types

  Extension	File Type
  .ade	Access project file
  .adp	Access project
  .app	Visual FoxPro application
  .asx	Windows Media Player shortcut
  .bas	Visual Basic class module
  .bat	MS-DOS/Windows batch file
  .chm	Compiled Hypertext Markup Language (HTML) help file
  .cmd	Windows NT, Windows 2000, or Windows XP batch file
  .com	MS-DOS program
  .cpl	Control panel
  .crt	PKCS#7-format digital certificate
  .csh	C shell script file for Microsoft Services for UNIX
  .exe	x86 executable
  .fxp	Visual FoxPro compiled program
  .hlp	Help file
  .hta	HTML program
  .inf	Setup information file
  .ins	Internet Naming Service file
  .isp	Internet communication settings file
  .js	JavaScript script
  .jse	Encoded JavaScript file
  .ksh	Korn shell script file for Microsoft Services for UNIX

  .mda	Access add-in
  .mdb	Access database
  .mde	Encoded Access database
  .mdt	Access workgroup information
  .mdw	Access workgroup information
  .mdz	Access wizard
  .msc	Microsoft Management Console (MMC) console file
  .msi	Windows Installer package
  .msp	Windows Installer patch
  .mst	Visual Test source file
  .ops	Office settings profile (generated by the Custom Installation Wizard)
  .pcd	Visual Test compiled script
  .pif	Shortcut to MS-DOS program
  .prf	Outlook profile
  .prg	FoxPro program
  .pst	Outlook personal folders file (only blocked in Outlook 2000 Service Pack 3)
  .reg	Registry keys for REGEDIT
  .scf	Explorer command file
  .scr	Screen saver
  .sct	Windows scripting component
  .shb	Shortcut to a document section
  .shs	Shell scrap object
  .url	Internet shortcut/Uniform Resource Locator (URL)
  .vb	VBScript file
  .vbe	Encoded VBScript file
  .vbs	VBScript script
  .wsc	Windows script component
  .wsf	Windows script
  .wsh	Windows Scripting Host settings file

• Level 2 There are no Level 2 file types by default; you have to add them yourself. With Level 2 attachments, you can see the icon for the attachment, and when you double-click it, you are prompted to save the attachment to your hard disk, but you can’t run it directly from its current location. After you have saved the attachment, you can decide how to handle it. This is supposed to make users think before blindly double-clicking every collection of bits that lands in their Inbox.

When you attach a file to an outgoing message, Outlook checks the file type against the Level 1 list. If you’ve attached any Level 1 files, a dialog box warns you that the recipients might not be able to open the attachment. Clicking Yes in this dialog box sends the message as is. Note that you can tell Outlook to not give you this warning; I’ll tell you how later.

When you receive a message that contains a Level 1 attachment, your Inbox displays the paper clip in the attachment column to let you know that the message includes an attachment. When you open an e mail message containing an attachment, the attachment is blocked, and the Outlook InfoBar warns you that the attachment is untouchable. The File | Save Attachments command (as well as the View Attachments command on the shortcut menu that opens when you right- click) shows only those attachments that aren’t blocked, rendering the others completely inaccessible. When you open the message itself, you’ll see the same warning as shown in Figure 13-1, but you can still get to all attachments that have extensions that aren’t on the banned list.

If you receive a message containing a Level 2 file as an attachment, the attachment appears normally. However, when you try to open it, you’ll get a warning dialog box telling you that it’s a bad idea to run the attachment directly and offering to let you save it to disk.

Address Book and Object Model Security

Outlook supports the Office object model, so you can write scripts and programs that automate repetitive actions. This is a double-edged sword: it’s very useful to allow some programs (like ActiveSync or Palm Desktop) to access contact information, but the same interfaces can be used by viruses or other malicious executables to propagate. In fact, many macro viruses invade the victim’s address book to get addresses to which they can mail themselves; because the security update makes this harder, some virus creators have now switched to scanning local files and harvesting e-mail addresses from them.

To help counter this behavior, Outlook 2002 turns on object model guards that restrict what outside applications can tell Outlook to do. There are three categories of object model guard: one category restricts calls made with the Messaging Application Programming Interface (MAPI), one restricts calls made with the Outlook object model, and the third covers calls made using the Collaboration Data Objects (CDO) method. I describe the specific types of access you can guard against later in the chapter.

Security Zone Changes

In Outlook 2002, the default security zone setting is Restricted Sites, rather than Internet. Within the Restricted Sites zone, active scripting is also disabled by default. This security zone disables most automatic scripting and prevents ActiveX controls from opening without permission. This change is designed to protect against malware that might be contained in HTML messages. As long as you leave the default Outlook zone set to Resricted Sites, Outlook won’t run scripts in HTML messages, and ActiveX controls in those messages are deactivated. You should ensure that you always apply Microsoft Internet Explorer patches to all machines running Outlook, because Outlook uses Internet Explorer to render HTML messages.

S/MIME Security

S/MIME support is one of Outlook’s unheralded important features. (I used to write S/MIME security software, so I admit to being a little biased.) Outlook’s support for S/MIME gives you end-to-end protection: messages you create can be signed or encrypted on your computer, and they stay protected as they travel and while they are in the recipient’s Exchange mailbox server. Encrypting, signing, decrypting, and verifying messages is easy, and Outlook gives you a great deal of control over the security settings used with particular certificates. One of the nicest things about Outlook’s S/MIME support is that it’s completely integrated (through CryptoAPI) with the rest of the system’s cryptographic functions; if you’re using certificates or smart cards for access control or other functions, you might be able to use the same certificates with Outlook.

Chapter 2, “Security Protocols and Algorithms,” describes the S/MIME protocol in general terms, but this is a good time to get a bit more specific. The reason for the MIME in S/MIME is that the secured content in S/MIME messages is actually made up of Multipurpose Internet Mail Extension (MIME) body parts, as described in Request for Comments (RFC) 1847. That means, for instance, that a plaintext message can still contain an attached signature. This is called a clear-signed message, because the message is still readable by clients that don’t understand S/MIME signatures. Its opposite, an opaque-signed message, contains the message and signature combined in a single part that cannot be read except by verifying the signature.

The S/MIME version 3 standard, which is what Outlook supports and uses by default, consists of several parts that define various aspects of how clients and servers should create, process, and manipulate secured mail, as follows:

• RFC 3369 describes the Cryptographic Message Syntax (CMS), the format of S/MIME messages. CMS is derived from the older Public Key Cryptography Standards (PKCS) #7 format (RFC 2315), which is why S/MIME-protected messages still appear to have attachments with the .p7m extension—that stands for PKCS #7 MIME part. This RFC is interesting primarily because it describes exactly how clients must sign, encrypt, decrypt, and verify messages and how the messages should be structured so that other clients can read them.

• RFC 3370 identifies the algorithms that all S/MIME version 3 software must support to be called S/MIME: Secure Hash Algorithm 1 (SHA-1) and Message Digest 5 (MD5) for hashing, Digital Signature Algorithm (DSA) and RSA for signatures, and RC2 and triple Data Encryption Standard (3DES) for message encryption. Individual implementations are free to add more algorithms to this set, provided they properly identify which algorithms a particular message uses so the recipient can figure it out.

• RFC 2632 describes certificate handling for S/MIME-compatible software. It specifies when and how clients should check for certificate revocation and expiration, how they should handle unknown certificate authority (CA)- specific extensions, and so forth.

• By its own admission, RFC 2633 “defines how to create a MIME body part that has been cryptographically enhanced according to CMS, which is derived from PKCS #7. This memo also defines the application/pkcs7-mime MIME type that can be used to transport those body parts.”

As a messaging administrator, you probably won’t ever want to read these RFCs, but they can give you some useful insight into why S/MIME clients act the way they do in some circumstances.

Outlook provides complete S/MIME version 3 support, plus some additional features defined in RFC 2634, including digitally signed message receipts, security labels (like secret or confidential), and a few other features of interest primarily to users of the Defense Messaging System (DMS), which I’m not going to cover in this book.