Sunday, 29 May 2016

On 02:53 by admin   No comments
Rich Text Format (RTF) is a document format developed by Microsoft that has been widely used on various platforms for more than 29 years. The RTF format is very flexible and therefore complicated. This makes the development of a safe RTF parsers challenging. Some notorious vulnerabilities such as CVE-2010-3333 and CVE-2014-1761 were caused by errors in implementing RTF parsing logic.

In fact, RTF malware is not limited to exploiting RTF parsing vulnerabilities. Malicious RTF files can include other vulnerabilities unrelated to the RTF parser because RTF supports the embedding of objects, such as OLE objects and images. CVE-2012-0158 and CVE-2015-1641 are two typical examples of such vulnerabilities – their root cause does not reside in the RTF parser and attackers can exploit these vulnerabilities through other file formats such as DOC and DOCX.

Another type of RTF malware does not use any vulnerabilities. It simply contains embedded malicious executable files and tricks the user into launching those malicious files. This allows attackers to distribute malware via email, which is generally not a vector for sending executable files directly.

Plenty of malware authors prefer to use RTF as an attack vector because RTF is an obfuscation-friendly format. As such, their malware can easily evade static signature based detection such as YARA or Snort. This is a big reason why, in this scriptable exploit era, we still see such large volumes of RTF-based attacks.

This vulnerability, reported by Team509 in 2009, is a typical stack overflow bug. Exploitation of this vulnerability is so easy and reliable that it is still used in the wild, seven years after its discovery! Recently, attackers exploiting this vulnerability targeted an Ambassador of India.

The root cause of this vulnerability was that the Microsoft RTF parser has a stack-based buffer overflow in the procedure parsing the pFragments shape property. Crafting a malicious RTF to exploit this vulnerability allows attackers to execute arbitrary code. Microsoft has since addressed the vulnerability, but many old versions of Microsoft Office were affected, so its threat rate was very high.

Because pFragments is rarely seen in normal RTF files, many firms would simply detect this keyword and the oversized number right after \sv in order to catch the exploit using YARA or Snort rules. This method works for samples that are not obfuscated, including samples generated by Metasploit. However, against in-the-wild samples, such signature-based detection is insufficient. For instance, the malicious RTF targeting the Ambassador of India is a good sample to illustrate the downside of the signature based detection. Figure 1 shows this RTF document in a hex editor. We simplified Figure 1 because of the space limitations – there were plenty of dummy symbols such as { } in the initial sample.

As we can see, the pFragments keyword has been split into many pieces that would bypass most signature based detection. For instance, most anti-virus products failed to detect this sample on first submission to VirusTotal. In fact, not only will the split pieces of \sn be combined together, pieces of \sv will be combined as well. The following example demonstrates this obfuscation:

Users can embed variety of objects into RTF, such as OLE (Object Linking and Embedding) control objects. This makes it possible for OLE related vulnerabilities such as CVE-2012-0158 and CVE-2015-1641 to be accommodated in RTF files. In addition to exploits, it is not uncommon to see executable files such as PE, CPL, VBS and JS embedded in RTF files. These files require some form of social engineering to trick users into launching the embedded objects. We have even seen some Data Loss Prevention (DLP) solutions embedding PE files inside RTF documents. It’s a bad practice because it cultivates poor habits in users.


Post a comment