Topic: McAfee Labs Detects Zero-Day Exploit Targeting Microsoft Office

[Pez]

McAfee Labs Detects Zero-Day Exploit Targeting Microsoft Office

Last Thursday morning (October 31), our Advanced Exploit Detection System (AEDS), which we discussed in an earlier post, detected a suspicious sample targeting Microsoft Office. After some investigation, we confirmed this is a zero-day attack.

Considering the importance of this incident, we shared our findings immediately with the Microsoft Security Response Center and worked closely with them in the last couple days. Today, as Microsoft has publicly released the security advisory with mitigations and workarounds, we feel it is time to share some detail of this zero-day attack.

Here is the traffic captured by this attack on a fully updated version of Office 2007 running on Windows XP SP3.



("click on the images to make them larger")

As we can see, after successful exploitation, the exploit downloads an executable (saved to C:\Documents and Settings\<username>\Local Settings\Temp\winword.exe) from the controlled web server.

The executable is actually a RAR SFX containing another executable and a fake Word document. The another executable (dropped to C:\Documents and Settings\<username>\Updates.exe) is a backdoor allowing attacker to take control of the victim’s computer. The fake document (dropped to C:\Documents and Settings\<username>\Shanti.doc) is popped to the victim right after the success of the exploitation, this is a common post-exploitation trick which tries to prevent victims from being aware of this attack.

The zero-day exploit sample is organized as the Word OpenXML format (.docx). We observed many ActiveX objects contained in the “activeX” directory after unzipping the .docx file. This suggests that the exploit uses ActiveX control to spray the heap memory.



It is worth to note that this heap-spraying in Office via ActiveX objects is a new exploitation trick which we didn’t see before, previously attackers usually chose Flash Player to spray memory in Office. We would believe the new trick was developed under the background that Adobe introduced a click-to-play feature in Flash Player months ago, which basically killed the old one. This is another proof that attacking technique always tries to evolve when old ones don’t work anymore.

As it shows, the meta date of the files were set to October 17, 2013, which may suggest a creation time of this exploit (though, the meta time could be faked).

And this is the place that EIP is being controlled to a sprayed memory space 0×08080808.



Speaking on the vulnerability leveraged by this attack, while we spotted the attack performed via Office 2007 running on Windows XP, this is actually a fault existing in a TIFF-processing component shipped with Microsoft Office. Therefore, not only are Office 2007 with Windows XP vulnerable to this attack, but also more environments are affected by this vulnerability. In addition, our later research showed this exploit also works on Office 2007 running on Windows 7. We’d suggest that readers take a look at the SRD blog post where they shared the exact affected environments and views from the vendor’s perspective. The Labs has been actively working on getting every piece of details of this exploit, we may share our additional findings in the near future.

Our AEDS continues to monitor advanced threats such as zero-day exploits and APTs worldwide, as a part of our commitments to protect our customers from today’s fast-evolving attacks.

For McAfee customers, we have released NIPS signature “UDS-ShantiMalwareDetected” last Friday to deliver protection in advance, our HIPS product is able to detect this attack without any update.

Thanks Bing Sun, Chong Xu, Xiaoning Li (Intel Labs)  and Lijun Cheng for their hard work on the exploit analysis as well as IPS detections. Guilherme Venere and Abhishek Karnik also contributed from the anti-virus side.


Original article: By Haifei Li on Nov 05, 2013

[Samker]

More info: http://scforum.info/index.php/topic,8462.0.html

Thanks P. 

[Pez]

Solving the Mystery of the Office Zero-Day Exploit and DEP

On November 5 McAfee Labs blogged about a Microsoft Office zero-day (See above) attack that we spotted in the wild. In another post we discussed coverage for our various products. Now, we’d like to report some interesting technical findings from our research team.

As pointed out in our previous post (See above), we found the exploit works pretty well on Office 2007 running Windows 7. We originally thought there must be some technique used by the exploit to bypass address space layout randomization and data execution prevention. However, our findings show something different because of the DEP system policy setting.

While debugging the shellcode, we noticed quite a few interesting things. First, the shellcode was in a PAGE_READWRITE memory block, which encouraged us to further check the DEP status of the process winword.exe. We found the DEP status was “on” at the process start but “off” during shellcode execution.

McAfee Labs researcher Haifei Li found this exploit worked on system-level DEP options, including both the Opt-In and Opt-Out for Office 2007. If the system policy is set to Opt-In, DEP is enabled only for processes that explicitly opt-in to DEP. Office 2007 Word is not in the DEP-enabled list; thus DEP is not enabled for Office 2007 under the Opt-In mode and there is no need for an exploit to bypass DEP to succeed. We tested further for the Opt-Out mode. If the system policy is set to Opt-Out, DEP is enabled by default for all processes except those that explicitly opt out of DEP. That means usually DEP is on for all processes for this option when they start, but a process has the option to opt out of DEP at any moment. We figured out that if we blocked the loading of VBE6.DLL (C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6.DLL), the exploit would not work–a DEP-violation error was triggered. Also, if we forced DEP with Microsoft EMET, the exploit would not work.

The test results caused us to wonder whether there was a DEP bypass, such as using ROP gadgets. Though many other researchers claimed this point after their analysis, they might have analyzed different samples. (The MD5 hash for our analyzed sample is 1FD4F3F063D641F84C5776C2C15E4621.)

Quickly we injected our DLL in winword.exe with a hooked LoadLibraryExA and called GetProcessDEPPolicy before and after the loading of each module. We opened the log and found that DEP status changed to “off” just after the loading of VBE6.DLL. After some investigation we I found that ntdll!ZwSetInformationProcess can be called with parameters -1 and 0×22 to turn off DEP for the process. So, just before the call to LoadLibrary with VBE6.DLL, we set a break point at ntdll!ZwSetInformationProcess, and it got hit with the expected parameters (-1,0×22). Back-tracing the call, we came across this:



("click the images to make them larger")

This is the code to disable DEP for the process:



This solves the mystery of the exploitation. Our analyzed exploit didn’t bypass ASLR and DEP. Instead, it leveraged a backward compatibility feature in Office 2007 to disable DEP. Without DEP, ASLR is quite easy to bypass with heap spraying, as discussed in this Microsoft SRD post.

We believe that the DEP compatibility issue of old DLLs such as VBE6.DLL makes this exploitation possible. Microsoft’s guidance confirmed our suspicions. The DEP system policy can be set to Opt-In, Opt-Out, Always-On, and Always-Off. Only the Always-On option enforces DEP, which means that a process cannot turn off DEP. For compatibility reasons, the Always-On setting may cause DEP-related crashes due to Microsoft Office applications opening documents that contain Visual Basic for Applications macros.

The lesson we learned is interesting. For better security, the system setting for DEP should be Always-On. But for compatibility, Opt-Out can be used to protect applications that assume DEP availability. However, the Opt-Out system setting does not necessarily have full DEP protection for an application that does not explicitly opt out of DEP; thus such an application (Microsoft Word in this case) is still subject to exploits that may be prevented by DEP.



Original article: By Vinay Karecha on Nov 07, 2013