Topic: RTF Attack Takes Advantage of Multiple Exploits

[Pez]

RTF Attack Takes Advantage of Multiple Exploits

This is a joint analysis by Haifei Li, Stanley Zhu, and Jun Xie of McAfee Labs

Recently, the rich text format has provoked new interest in the security industry due to a critical RTF zero-day (CVE-2014-1761) exploit found in the wild. McAfee Labs has investigated this threat. As usual, we suggest our customers apply our solutions right away if you haven’t already done so.

In this post, we want to share our analysis of another RTF exploit. This attack is particularly interesting because the single RTF sample tries to exploit two previous vulnerabilities. This multiexploitation technique is usually seen in HTML or JavaScript exploits but rarely for RTF or Office exploits.


Analyzing the exploit

 As you can see in the following figure, the malicious RTF comes as an attachment to an email that appears to be a UPS delivery invoice.



("click the images to make them larger")

We have analyzed the content of the RTF at a deep level. The content consists of several objects, which we will examine one by one.

The first object looks like the following:



The first object loads both first- and second-stage shellcode in memory. After successful exploitation, the first-stage shellcode searches the memory for the second-stage shellcode and executes it. We’ll explain this later.

The second object in the RTF file is some OLE data read via the program ID “Word.Document.12,” which suggests that it contains a Word 2007 OpenXML document.



We can simply “unzip” the .docx file and find something like this.



As shown above, the attack uses the same nonscriptable heap-spraying trick that we first identified in the Office TIFF zero-day attack, which we discovered in the wild last November. Previously we had seen the trick used only with OpenXML formats (.docx); this time the trick is used with RTF.

The third object aims to exploit a years-old but still popular Office vulnerability. This vulnerability, CVE-2010-3333, is a stack-based overflow in MSCOMCTL.OCX. The vulnerability is easy to exploit, which makes popular in many exploit kits.

After successfully exploiting CVE-2010-3333, shellcode will execute; it’s a very smooth attack. However, CVE-2010-3333 is an old vulnerability that was patched more than three years ago. To maximize the chance of hacking into victims’ systems, the attacker has made some innovations.

The third object also tries to trigger the CVE-2013-3906 TIFF paring vulnerability through a “\pict” control word, with the object stream actually a crafted TIFF file.



CVE-2013-3906 is an integer overflow vulnerability in OGL.DLL. By exploiting the vulnerability, an attacker can control the program flow to heap memory around 0x0A0AXXXX. At this point, the heap memory has already been sprayed there via the second object, so the first-stage shellcode will be correctly executed in the heap. The shellcode uses 0x3F (AAS) as the NOP instruction.



After that, the first-stage shellcode in the second object searches for and executes the second-stage shellcode.


Analyzing the dropped malware

 After a successful start, the exploit downloads the malware from http://track.invoice-accounts.org/WebTracking/updateoffice.exe and executes it. See following piece of shellcode:



The dropped updateoffice.exe is a variant of the Win32/Trojan.zbot family. Now let’s look at a behavior analysis of the malware, consisting of three steps.

Step 1
 The malware copies itself to the %temp% directory and renames itself laruo.exe (with perhaps some random characters), and executes. The full path may look like this:
 C:\Documents and Settings\%user%\Local Settings\Temp\Owma\laruo.exe.



Step 2
 Laruo.exe releases its driver file (2ad5a3) to the %system32\drivers directory and loads it into the kernel (C:\WINDOWS\system32\drivers\2ad5a3.sys). The malicious driver replaces a kernel-mode driver, and also hooks NtOpenProcess and NtOpenThread in the SSDT kernel. The driver code is encrypted. The malicious driver is a variant of the W32.Rootkit.Necurs family.

Step 3
 Laruo.exe is injected into the explorer.exe process, and adds itself to AutoRun by editing the following register key:
 HKCU\Software\Microsoft\Windows\CurrentVersion\Run Value: “C:\Documents and Settings\sh1t0u\Local Settings\Temp\Owma\laruo.exe.

Laruo.exe disables the Windows firewall by modifiying the value of the register key
 HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile.

It also does some self-deleting using the following command line:
 C:\WINDOWS\system32\cmd.exe” /c “C:\DOCUME~1\%user%\LOCALS~1\Temp\OLDFF57.bat.

With the malware injected into explorer.exe, the injection code connects to the malicious domain aulbbiwslxpvvphxnjij.biz (50.116.4.71) for DNS requests. The string is contained in the malware file itself, as shown next:



The address 115.126.143.176 is the active control server as we write this:



Conclusion

 To simplify, the process of the RTF exploit takes four steps:

1.Load the second-stage shellcode for future execution (preparing for Step 4)

2.Spray the heap using the method we first saw in the CVE-2013-3906 .docx exploit (preparing for Step 4)

3.Exploit CVE-2010-3333
 A. If successful, the malware executes (shutting down the Word process). => Game over
 B. If failing, nothing happen except go to Step 4.

4.Exploit CVE-2013-3906 with the sprayed heap and second-stage shellcode prepared in Step 1 and 2. => Game over

In this post we have showcased a real-world multiexploitation RTF attack that we recently detected in the wild. Even though the RTF is not a scriptable file format, this RTF-specific trick is able to exploit multiple vulnerabilities in one single RTF attack. This trick helps bad guys maximize their chances of success.

From this analysis we now know how flexible the RTF file format can be: It could perhaps embed any Office exploit. From a defense point of view, the complexity of the RTF format poses a challenge for accurate detection via signature-based methods. We have seen quite a lot of RTF exploits that lack detections, but we are glad to see that our sandboxing solutions–such as McAfee Advanced Threat Defense and the Advanced Exploit Detection System project–are filling the gap.

We would like to thank Bing Sun, Xiaoning Li (Intel Labs,) and Chong Xu for their help with this analysis.


Original article: By Haifei Li on Apr 03, 2014

[Pez]

A Close Look at RTF Zero-Day Attack CVE-2014-1761 Shows Sophistication of Attackers

A serious RTF zero-day attack has struck recently. McAfee detection solutions were provided a couple of days ago that allowed us to spot in-the-wild attacks. We detected this exploit on Wednesday. McAfee Labs researchers have been actively working on this threat. In this post, we will share our perspective on how the exploit works–specifically how an extended instruction pointer (EIP) is controlled at a deep technical level.

From our analysis, we believe the root cause of the vulnerability is related to the RTF “overridetable” control word (also called a structure) or the inside structures. An “overridetable” structure may include the “listoverride,” “listoverridecount,” and “lfolevel” fields. The “listoverridecount” basically tells how many instances of “lfolevel” the structure may contain. According to Microsoft’s official specification, the legal value should be 0, 1, or 9. However, in this exploit, the value is 25.

The in-the-wild exploit is a bit complex. However, we can simplify it into this one-line proof of concept:



During our tests, when the value of the “listoverridecount” is set to 25, starting from the 29th value the “lfolevel” structure is handled incorrectly by the Microsoft Word. Specifically, an object-confusion fault occurs, for example, class A is wrongly handled as class B. As every byte of the confusing object can be controlled by the attacker via various control words, the attacker can control the program flow (EIP) accurately.

The attacker controls the EIP to an address in MSCOMCTL.DLL. Because the DLL doesn’t have address space layout randomization (ASLR) enabled (for Office 2010 or earlier versions), the attacker can make the exploit work for Office on newer operating systems such as Windows 7. The first controlled EIP is a fixed address, 0x275A48E8. Let’s see what it looks like:



The preceding first address is controlled from somewhere (shown in the following image) in wwlib.dll via a “call [ecx+4]“.



As we can see, at this point the object (pointed by ecx, at 0×07941060 for this test) is being used incorrectly. What we see is that the memory bytes are always the following (listed at 0×18 length):

07941060  7B 7B 00 00 E8 48 5A 27 89 64 59 27 EF B8 58 27
07941070  59 59 00 00 5A 5A 00 00

Note the second DWORD 0x275A48E8; this is the EIP that is controlled. The other bytes are also important for making sure all the following steps (after the first EIP control) work correctly, such as ROP and shellcode executions. So the question is, Where do the memory bytes for this incorrectly used object come from? Is this filled by some kind of heap spraying or something else? More deep research showed that all of the bytes actually came directly from the RTF file; in other words, all the bytes can be controlled.

The mystery lies in the fields (and their values) in the “listoverrideformat” structure inside the incorrectly handled “lfolevel” structure. The following image shows exactly how the fields’ values are transferred into the 0×18-length memory bytes:



Here are the highlights:

1.Bytes 0-3 (first DWORD) are controlled via the “\levelstartat” control word

2.Byte 4 is controlled via the “\levelnfcn” control word

3.Controlling byte 5 is a little tricky, but it’s important because that’s where the first EIP control goes. This step is not easy due to the nature of the confusing object. The attacker is apparently smart enough to realize that he or she can control the fourth and seventh bits (from low to high) of the byte via the “\levelnorestart” and the ”\levelold” control words, respectively. When these two bits are set, the byte comes to 0×48 (in bits, 0100 1000) which is a part of the DWORD 0x275A48E8. This is enough to transfer the program flow to a useful starting address in MSCOMCTL.DLL.

4.Bytes 6-14 can be controlled via the “\levelnumbers” control word. In this example, the attacker uses a “\’” control word to input a hex byte 0x5A (\’5A). The program reads the other bytes (7-14) directly from the following bytes in the RTF file.

5.Byte 15 is controlled via the “\levelfollow” control word

6.The DWORDs at bytes 16-19 and at bytes 20-23 are controlled via the “\levelspace” and the “\levelindent” control words, respectively. (The linking relationship isn’t shown in the preceding figure.)

Because the object memory can be controlled accurately by the attacker via specific RTF control words, the attacker can make a highly reliable and accurate exploitation, even without a heap spray.

Overview of follow-up executions
(provided by McAfee Labs researcher Jun Xie)

The ROP chain (in MSCOMCTL.DLL) allocates a memory block marked as READ/WRITE/EXECUTE at address 0×40000000, and copies the first-stage shellcode to this address. After that, a specific ROP, usually known as stack pivot, runs and the program flow goes to 0×40000040.

In the first-stage shellcode, the exploit performs a brute-force search to find the file handle to map the RTF file into memory. Then it searches the second-stage shellcode and copies the second-stage shellcode to address 0×40002000. The second-stage shellcode reads the Microsoft patch-log file on the system. If it finds that the last patch time is after April 8, the execution is terminated. Otherwise, it will decrypt and drop malware named svchost.exe (to confuse the victim). The malware makes some other confusing moves, for example, at the end it decrypts and shows a harmless Word document (which includes some porn images) to the victim.

Conclusion
 From what we’ve learned, we can see how sophisticated this exploit is and how deeply the attackers understand RTF. Apparently the bad guys understand the related control words and their memory representations at a really deep level.

Considering these elements, we see this zero day as a serious threat and suggest that everyone take the following action(s) as soon as possible:

  • For McAfee customers, apply our detection solutions, found here

  • Apply the “Fix It” tool or install EMET, as suggested by Microsoft

  • Wait to apply the patch that will be released next Tuesday, according to the Microsoft Security Response Center blog post

Thanks to Bing Sun, Xiaoning Li (Intel Labs), and Chong Xu for their help with this analysis.


Orginal article: By Haifei Li on Apr 03, 2014