Outlook PR_ATTACH_METHOD file execution vulnerability

Yorick Koster, October 2009

Abstract

It has been discovered that certain e-mail message cause Outlook to create Windows shortcut-like attachments or messages within Outlook. Through specially crafted TNEF streams with certain MAPI attachment properties, it is possible to set a path name to files to be executed. When a user double clicks on such an attachment or message, Outlook will proceed to execute the file that is set by the path name value. These files can be local files, but also file stored remotely for example on a file share. Exploitation is limited by the fact that its is not possible for attackers to supply command line options.

Tested version

This issue was tested on the latest versions of Outlook 2003 SP3 and Outlook 2007 SP2.

Fix

Microsoft released MS10-045 that blocks unsafe use of the PR_ATTACH_METHOD property in e-mail messages.

Introduction

Microsoft Office Outlook is a personal information manager. It is often mainly used as an e-mail application, but it also includes a calendar, task manager, contact manager, note taking, a journal and web browsing.

Outlook supports various e-mail formats, including plain text, HTML and TNEF. TNEF is a proprietary format used by Microsoft Outlook and Microsoft Exchange Server. TNEF messages or TNEF streams exist of message and/or attachment attributes. These attributes contain basic properties, such as message subject, date sent and attachment title (file name). Additional attributes can be set using MAPI properties, which are stored in attMAPIProps or attAttachment TNEF structures.

MAPI attachment properties

In MAPI, there are a couple of properties available that are specific for handling e-mail attachments. One of these properties is the PR_ATTACH_METHOD property. This property can be set to a MAPI-defined constant and represents the way the contents of an attachment can be accessed. For most attachments, this property will be set to ATTACH_BY_VALUE. When set to this value, the attachment data is either stored in the PR_ATTACH_DATA_BIN MAPI property or it is stored in an attAttachData TNEF structure.

If the PR_ATTACH_METHOD property is set to ATTACH_BY_REFERENCE, ATTACH_BY_REF_ONLY or ATTACH_BY_REF_RESOLVE, Outlook expects a fully-qualified path name instead of an embedded attachment. This path name is set using either the PR_ATTACH_PATHNAME or PR_ATTACH_LONG_PATHNAME MAPI property. The path name can be set to a Universal naming convention (UNC) name.

ATTACH_BY_REF_RESOLVE

A message or attachment can have a Message Class property that loosely defines the type of a message, contact or other personal information manager objects. For normal e-mail messages, the message class is set to IPM.Note. The Message Class is set by the TNEF attMessageClass structure or by the PR_MESSAGE_CLASS MAPI property.

If the Message Class is set to IPM.Document Outlook will process this message as an e-mail message consisting of a single attachment. By appending a subclass to IPM.Document it is possible to more specifically state what type of document the attachment is. For example, a Message Class of IPM.Document.txtfile indicates that the attachment is a plain text file, while IPM.Document.Excel.Sheet.12 indicates a Microsoft Excel document created with Excel 2007.

If Outlook receives a message with its Message Class set to IPM.Document.<type>, Outlook will search the Windows Registry using the last part (<type>) of the Message Class to see if such a file type is registered in Windows. If so, it will look in the Registry to see if this file type has an icon associated (i.e. HKEY_CLASSES_ROOT\txtfile\DefaultIcon). If so Outlook uses this icon as the icon for the e-mail message.

It appears that if Outlook receives a message with a Message Class set to one of IPM.Document values and it contains a PR_ATTACH_METHOD MAPI property set to ATTACH_BY_REF_RESOLVE, the message behaves like a (simple) Windows shortcut. If a user double clicks such a message, Outlook will open the link provided by the PR_ATTACH_PATHNAME or PR_ATTACH_LONG_PATHNAME MAPI property.

Setting PR_ATTACH_PATHNAME to cmd.exe causes Outlook to search the PATH environment variable for an executable named cmd.exe. If such a file is found, this file will be executed. Normally this will result in a command shell. The path name can be set to anything that is supported by Windows, including UNC names (i.e. \\servername\sharename\executable.exe) but also URLs (i.e. http://www.akitasecurity.nl/advisory/RunCalc.exe). For URLs, Outlook will open the default web browser. For other types of URIs, the registered protocol handler determines how the supplied URI is opened and by which application.

Attachment file names

Even though the attachment can be loaded from a location other than the message itself, Outlook still processes the file name of attachments. If none is set and a user double clicks the specially crafted message, Outlook will show a "Opening File" dialog, warning the user only to open files from trustworthy sources.

It appears that Outlook uses the file name property to determine if and if so which dialog must be shown. For example, by setting a fake name with a .exe extension causes Outlook to show a "File Security Warning" dialog. In this case users only have the option to save the file to disk or cancel. The fake name is not checked against the actual file name provided by the PR_ATTACH_PATHNAME or PR_ATTACH_LONG_PATHNAME MAPI property. Some extensions do not trigger a dialog, for example Office files and image files. Consequently, this can be used to prevent any dialog from being shown even though the actual file is an executable. File names can be set through the PR_ATTACH_FILENAME and PR_ATTACH_LONG_FILENAME MAPI properties.

ATTACH_BY_REF_ONLY

Outlook will not be able to load messages in the preview pane for messages with the MAPI property PR_ATTACH_METHOD set to ATTACH_BY_REF_RESOLVE and a Message Class set to one of the IPM.Document values . Instead it will issue the following notice:

This file cannot be previewed. Try opening the file in the program in which it was created.

Choosing a different Message Class (i.e. IPM.Note) will allow Outlook to load the message and the specially crafted attachment will be shown as a normal attachment. However, if a user tries to open this attachment, Outlook will issue the following warning dialog:

The program used to create this object is Outlook. That program is not installed on your computer. To edit this object, you must install a program that can open the object.

In order to create an attachment containing a link (shortcut), the PR_ATTACH_METHOD property has to be set to ATTACH_BY_REF_ONLY instead of ATTACH_BY_REF_RESOLVE. In this case Outlook will look at the extension of the filename (PR_ATTACH_FILENAME or PR_ATTACH_LONG_FILENAME), but also at the extension of the path name (PR_ATTACH_PATHNAME or PR_ATTACH_LONG_PATHNAME). If the path name contains an extension such as .exe, Outlook will block the attachment. This check can easily be circumvented using URIs containing query string values ending on a extension Outlook does not block. For example, the file URI file:///c:/windows/system32/calc.exe?.txt will cause Outlook to not block the attachment and still open Calculator.

Limitations

This issue does not allow attackers to supply command line options, limiting the possibilities for attackers when executing local files. It is possible to place a malicious executable on a file share. In order for this attack to succeed, the attacker has to be on the same intranet as the target user or the target user's system has to be allowed to make outbound connections to the attacker's share (over the Internet). Note that it is possible to access file shares through WebDAV (see also Security Research & Defense blog).

Executables can be delivered of the web (HTTP), but in this case the file is loaded through the default web browser that will normally issue a warning when it is about to run an executable.

Proof of concept

Proof of concept code has been released as part of the Metasploit project.

- ms10_045_outlook_ref_only.rb
- ms10_045_outlook_ref_resolve.rb