By posteriori/shutterstock.com

 

ABSTRACT

RTF (Rich Text Format) files have been around since 1987 and are often times overlooked and underestimated as being a viable attack vector. Although the RTF version has not been updated since 1.9.1 was released in March 2008, most document processing applications (e.g., Microsoft Office) still support the format.

This ongoing support of an aging file format has led to a recent surge of attacks exploiting a weakness in Microsoft Office (CVE-2017-0199). Attackers have discovered the ability to execute malicious code on a victim machine, without any prompting or warning to the user. On April 7, 2017, Haifei Li from McAfee Labs first reported about the attack in a blog posting. On April 8, 2017, Genwei Jiang of FireEye provided an acknowledgement that they were already working with Microsoft on this vulnerability and timing their disclosure to coincide with a patch being made available.

On April 11 2017, Microsoft released the patch for Microsoft Office for this zero-day vulnerability. The patch prevents attackers from targeting the HTA handling logic of OLE autolinks within RTF files. On an unpatched system, as a victim opens an infected RTF, an embedded OLE autolink causes Microsoft Word to download a malicious HTA file and execute it prior to prompting the user. Prior to the user seeing any prompt, the infection has already occurred. The malware ensures this by terminating Microsoft Word prior to the prompt being displayed at all. Instead, a new instance of Word is started with a decoy document displayed. The victim is clueless they have been compromised.

Let’s examine the first two stages of this attack to better understand how RTF files are exploited and to better understand possible detection methods…

 

BACKGROUND

RTF File Specification

Unlike, the more common document choices for malware droppers (e.g., HTA, PDF, Flash, M/S Office), Microsoft’s Rich Text Format (RTF) specification appears to leave very little room for exploitation. This misconception is largely due to RTF’s lack of support for an embedded scripting language. Without scripting language support, RTFs have been wrongly mistaken as being less likely candidates for malware infection.

To understand how RTF files can be exploited, lets first review how the files are encoded. The RTF pasted below is an excerpt from the Microsoft specification. It is a small document that, when rendered in an RTF viewer, displays “This is plain text”. In other words, it is the RTF example of “Hello World”.

 

 

As shown above, RTF files are comprised of a header (i.e., \rtf1) followed by a sequence of control words (e.g., \ansi, \deff0, \fonttbl). These control words are used to mark characters to be displayed or printed. Control words are comprised of a single backslash, followed by one or more ASCII letters, and, terminated by a delimiter (a space, a digit, a special character). Control words can be nested inside of groups using curly braces (i.e., {}). All other characters in the RTF represent text or data to be displayed (e.g., This is plain text).

As listed in Appendix B in Microsoft’s Rich Text Format (RTF) specification (excerpt of abbreviated list pasted below), over 1800 control words are supported. This support for a vast number of control words makes the RTF a fairly complex file format. This complexity comes at a cost. RTF viewers are burdened with responsibility of properly (and safely) parsing each of these features. If the parsing logic is flawed, vulnerabilities can possibly be exploited.

 

 

Parsing Engine Vulnerabilities

Historically, attacks involving RTF files have come in two flavors. The first is to exploit vulnerabilities in RTF parsing engines. In this scenario, the attacker discovers a flaw in the parsing logic and crafts an RTF file to exploit the flaw. For example, in 2010, a buffer overflow (CVE-2010-3333) in M/S Office was discovered, where the parsing of malformed pFragments led to arbitrary code execution. Simply said, a control word parsing error resulted in a malware infection. Similarly, in 2014, arbitrary code execution was made possible via vulnerability in the parsing of the overridetablecontrol word (CVE-2014-1761).

These two vulnerabilities are representative of how RTF parsing errors can be exploited. With over 1800 control words supported, there remains a possibility that additional zero day vulnerabilities exist that have yet to be discovered.

The Microsoft Office Zero-Day described in this article uses an alternate form of attack… exploiting RTF’s support of OLE objects.

Let’s examine how OLE exploits work…

 

Object Linking and Embedding (OLE) Exploits

The second common form of attacks against RTF files targets the support of objects (\object). The primary use of objects within RTF is to add Microsoft’s OLE (Object Linking and Embedding) capabilities. OLE provides the ability for one document (or object) to be linked or embedded into another document of the same or different file format. If a document is embedded, a copy of the document is inserted into the target document. If linked, a pointer is inserted into the target document, which specifies the location of the linked document. The linked document can reside locally on the same computer, or, linked via a URL that points to a document served from the Internet.

Interesting… the link can point to a document at a remote Internet location.

As a document containing an OLE link is opened, the content is updated to reflect the current content of the linked document. This means that if the link points to a remote URL, the remote document will be downloaded and sourced as part of the update process. The intent is that the user will be prompted to choose whether or not this update is allowed to happen as shown below.

 

With the support for OLE, RTFs can link or embed document formats, which support scripting languages. In other words, malware authors have figured out that the RTF document, which looks harmless, can link to, or embed a much more harmful document type. Even worse, this harmful document can be downloaded from the Internet. Attackers are betting that malware scanners either underestimate RTFs and ignore them, or, scan RTFs and overlook embedded OLE links to remote malware droppers.

Like many other attacks against RTF documents, the zero-day vulnerability described in this article leverages OLE autolinks to accomplish its goal. This attack distinguishes itself from previous attacks by automatically downloading and running an OLE autolinked document without any user intervention. In other words, the user can be victimized without seeing the prompt shown above.

Lets dive deeper into the RTF format and see exactly how this attack takes place…

 

ANALYZING THE DOCUMENT 

Analysis Overview

Similar to many other attacks, the RTF HTA Handler exploit begins as an RTF attachment (MD5: 5ebfd13250dd0408e3de594e419f9e01) in an alluring email.  As the user opens the attachment, M/S Word (WinWord.exe) parses and renders the RTF file. During the RTF parsing, an embedded OLE autolink is encountered which links via a URL to a remote RTF file (template.doc).

This second stage file (template.doc) is an RTF file, named with a .doc extension, and tagged with an application/hta Content-Type. The Content-Type is part of the HTTP header, which is used to indicate the media-type of the returned content. Ultimately, this contradiction of file types results in the file being processed as an HTA file. As M/S Word downloads the file, it disregards the file extension (.doc), disregards the internal file signature (\rtf1) and invokes M/S HTA application (mshta.exe) to process the file. The M/S HTA application scans the file, disregarding most of the internal RTF tagging and ultimately finds an embedded VBScript payload to run.

This file is downloaded and executed prior to prompting the user if they “want to update this document with data from linked files”. This is the critical logic flaw, which allows this attack to succeed. The downloaded HTA file has the opportunity to infect the victim and terminate M/S Word before the prompt is ever displayed (replacing M/S Word with a new running instance and a decoy document displayed). This means that the attack has been launched without the user ever being notified or given the chance to prevent it.

Lets walk through this attack and see how this happens…

 

Stage 1 – Decoding the RTF File

Since the attack begins with an embedded OLE autolink, lets decode the RTF and see what this link looks like. There are several good ways to decode an RTF file. Didier Stevens provides an extremely useful tool (rtfdump.py) to decode the contents of an RTF file.

In this article, the decoding of the RTF file will be done manually as we compare the raw encoding to Microsoft’s Rich Text Format (RTF) specification. The first step is to understand how OLE objects are encoded within an RTF. Microsoft’s specification describes the object encoding as shown below.

 

 

Objects are encoded using the \object control word, followed by a sequence of optional control word modifiers (e.g., objmodobjclassobjnameobjtimeobjsize, and rsltmod). Following the last optional modifier is the actual Object Data. The Object Data is tagged using the \objdata control word and is stored in an OleSaveToStreamformat. This means that when viewing the raw RTF file, embedded objects can be found by searching for the \object control word, followed by any of these optional control word modifiers as described.

Armed with this new knowledge, let’s view a raw dump of the malicious RTF file and see if we can spot the OLE object. If we scan the file for the \object control word as shown below, it becomes obvious that the document has an embedded object contained within it.

 

 

Following the object control word are some interesting follow-on control words. Listed below is each, along with their definition as described in the Microsoft RTF specification. Looking at the list below, we can see that the object is tagged with the \objautlink control word. This means that the object is actually a link to another object rather than an embedded object.

 

 

The next interesting item to look at is the object data itself. Following the \objdatacontrol word is a sequence of bytes as shown highlighted below. These bytes are an ASCII representation of hexadecimal values. For example, the first 8 bytes of ASCII values shown below (i.e., 01050000) represent the hexadecimal value 0x00000501. Similarly, the following 8 bytes (02000000) represent the hexadecimal value 0x00000002. If the byte ordering seems strange, it is due to the interpretation of these fields as four byte integers as opposed to string values (described in more detail below). For integers, the byte ordering reads from right to left, rather than left to right.

 

 

The Microsoft RTF specification describes that the object data is saved in an OleSaveToStream format. This format begins with an ObjectHeader as shown in the table below.

 

 

The first four bytes represent the OLEVersion, which is described in the specification as being “set to any arbitrary value and MUST be ignored on receipt”. That’s simple; we ignore the first four bytes. Regardless, the first four bytes of OLE object headers tend to always be 01050000.

The next four bytes represent the FormatID, which is described in the specification as 0x00000001 indicating a LinkedObject structure and 0x00000002 indicating an EmbeddedObject structure. As shown above, our FormatID is set to 0x00000002 telling us that the follow-on data will be an EmbeddedObject structure. Ignore that this seems to conflict with the \objautlink control word – the EmbeddedObject structure will ultimately define an OLE2link.

The next field is the ClassName and it is represented as a LengthPrefixAnsiString. This is a common data structure used by Microsoft for variable-length string fields. The first four bytes of the LengthPrefixAnsiString represent the number of bytes in the follow-on string value. For example, our ClassName shown above is prefixed with 0x00000009 (meaning 9 bytes of string value follow it). This leaves 0x4f4c45324c696e6b00 as a null-terminated string, which converts from hexadecimal to ASCII as the value ‘OLE2Link’.

Following the ClassName is the TopicName and the ItemName. Both of these fields are also in a LengthPrefixAnsiString format. Since the first four bytes of each of these fields are 0x00000000, both fields have a zero length string value. This is Microsoft’s way of saying the field is empty (no value).

Since the FormatID decoded above indicated that we are dealing with an EmbeddedObject, the remaining bytes (shown below) need to be decoded using the EmbeddedObject specification from Microsoft.

 

 

The EmbeddedObject specification describes that a four byte NativeDataSize defines the number of follow-on native data bytes to follow. As shown below, our sample indicates that 2560 bytes (0x00000a00) comprise the NativeData field. Parsing the NativeData field, we can see that it starts with the M/S Office Document file signature value 0xd0cf11e0a1b11ae1.

 

 

This is good news…

So far, our parsing matches our expectations. We expected the RTF to contain an OLE Autolink. It did. Parsing the ObjectHeader in the object data field told us that we are dealing with a OLE2Link EmbeddedObject. We expected that to be true. As we start parsing the EmbeddedObject, we see that it contains a file signature for an M/S Office file. All of our expectations have been met.

So…. if the EmbeddedObject is an OLE2Link, where is the URL to the remotely linked OLE document?

At this point, we could either continue parsing the NativeData portion of the EmbeddedObject, or, we could take a shortcut and hexadecimal convert the Native Data bytes to ASCII. As shown below, converting the hexadecimal bytes in the NativeData to ASCII reveals the URL (http[:]//46.102.152[.]129/template.doc).

 

 

We have now successfully decoded the RTF, revealing that it contains an embedded OLE2Link pointing to a remote “doc” file.

Can traditional static analysis of the RTF identify the file to be malicious? The strict answer is no. Everything uncovered so far is part of designed functionality provided by Microsoft. Microsoft intentionally provides the ability for a document to leverage OLE to link to external documents. Part of that OLE linking capability provides for the linked document to be specified via a URL pointing to a remote file. That said, is it suspicious (or unprofessional) to see a remote link to a hard-coded IP address as shown above? The answer is probably yes. In security-conscious environments, it is useful to know that RTF documents are being downloaded that contain OLE autolinks links to hard-coded IP addresses. These type of documents are atypical and risky in nature and should be highlighted as such.

Lets decode template.doc and see if a more definitive detection can be made…

 

Stage 2 – Decoding template.doc file

As described in the analysis summary, the template.doc file is downloaded from the malware-hosting site, tagged with an application/hta Content-Type. The Content-Type causes WinWord.exe to invoke the M/S HTA Application (mshta.exe) to process the file.  As described earlier, this is done without the user being prompted whether they want to allow a linked document to be downloaded and run.

So, is template.doc an HTA file, a DOC file, or an RTF file?

Shown below is a scrape of template.doc (MD5: fb475f0d8c8e9bf1bc360211179d8a28). The file begins with seventy-five blank lines and then ultimately, an RTF header on the seventy-sixth line. The seventy-five blank lines are most likely a form of obfuscation in an attempt to evade detection (perhaps it is assumed that malware scanners will only be examining the first few bytes of the file to recognize the \rtf file signature). Regardless, template.doc is definitely an RTF file.

 

 

So, if template.doc is an RTF file, how does mshta.exe process it successfully as an HTA file?

Taking a closer look at template.doc, we can see that the 123rd line of the file is extremely long (6238 bytes long). Scrolling to the 2589th byte of line 123 reveals a block of VBScript code as highlighted below.

 

 

The VBScript on line 123 shown below is actually embedded within the hexadecimal payload that comprises the \themedata starting on line 121. As the HTA Application parses template.doc, it eventually stumbles upon something it is able process. It finds the VBScript payload… something that it would expect to find in an actual HTA file. Once it finds it, it happily executes it.

 

 

The code shown below is the raw VBScript extracted from line 123. It was formatted to add several line breaks to improve readability. Lines 10-15 reveal that the malware author attempted to avoid detection by obfuscating critical commands (e.g., PowerShell) and reassembling them at runtime.

 

 

Cleansing the VBScript reveals the following code as shown below. The de-obfuscation shown is the result of removing string concatenation logic (e.g., “c” + “m” + “d” + “.” + “e” + “x” + “e” becomes “cmd.exe”). This was done to improve readability.

 

 

The logic flow of the of the VBScript shown above is as follows:

 

 

Can traditional static analysis be used to identify that template.doc is malicious? The answer is definitely yes. The file itself is structured unusually with the RTF header being located deep into the start of the file. Even more definitive is the presence of obfuscated VBScript buried inside of a theme data section. De-obfuscating the VBScript and scanning for typical techniques used to download Internet files provides the most accurate detection. In summary, this file can be statically analyzed to determine that it is a malformed RTF file, containing obfuscated VBScript capable of downloading follow-on VBScript files from the Internet. These attributes make the file malicious.

Can network analysis techniques be used to identify this stage of the attack? The answer is yes. Correlating various aspects of the network session should raise the suspicion level appropriately. To begin with, network analysis should reveal that a GET request was made to an IP address (46.102.152.129) rather than a Domain Name. Most HTTP activity wouldn’t limit itself by targeting a specific IP address. Secondly, the GET request was for an M/S Word document (e.g., GET /template.doc), however, the Content-Type indicated that an HTA file was being returned (e.g., application/hta). Extracting the file from the network session reveals that an RTF was actually returned. In a security-minded environment, suspicion should be raised for network sessions that target downloading a file from a hard-coded IP address combined with obfuscation surrounding the file type being returned.

At this stage of the attack, we can easily see how the RTF file format was exploited to infect the system. From this point onward in the attack, a series of VBScript files are downloaded and ultimately the malware EXE itself is downloaded and installed.

Given that we now understand RTF’s role in the attack, we will stop our analysis here…

 

CONCLUSION

Ultimately, there is no substitute for precaution. Do not open documents from untrusted sources. In the non-digital world, do you open packages without knowing and trusting whom and were they come from?

As usual, it is recommended that security patches should be applied in a timely manner. However, this attack is an example of a zero-day vulnerability in Microsoft Office. Regarding software, there will always be the possibility of zero-day attacks. A diligent patching regime is an absolute must, but patching is not a complete solution to the problem. It is part of an overall solution that needs to include educating users on safe handling of documents in the digital world.

 

ACKNOWLEDGEMENTS

“Alone, we can do so little; together we can do so much.” — Helen Keller

For additional reading on this attack and RTF attacks in general, please reference the list provided below. The information provided in these links is incredibly interesting and informative. The researchers involved have provided a tremendous amount of knowledge sharing in the links posted below.

“Critical Office Zero-Day Attacks Detected in the Wild” – Haifei Li, McAfee

“Acknowledgement of Attacks Leveraging Microsoft Zero-Day” – Genwei Jiang, FireEye

“CVE-2017-0199: In the Wild Attacks Leveraging HTA Handler” – Genwei Jiang, Rahul Mohandas, Jonathon Leathery, Alex Berry, Lennard Galang from FireEye

“CVE-2017-0199: life of an exploit” – Gábor Szappanos, SophosLabs

“Cisco Coverage for CVE-2017-0199” – TALOS

“How RTF Malware Evades Static Signature-Based Detection” – Junfeng Yang, FireEye

“Attacking Interoperability: An OLE Edition” – Haifei Li and Bing Sun, Intel Security

“Malicious RTF Files” – Didier Stevens

Microsoft Office Rich Text Format (RTF) Specification, Versions 1.9.1

Thanks for reading… You can also connect with me on Twitter at @kd_cybersec.

Written by 

Leave a Reply

Your email address will not be published. Required fields are marked *