Security Advisory 2953095: recommendation to stay protected and for detections

Today, Microsoft released Security Advisory 2953095 to notify customers of a vulnerability in Microsoft Word. At this time, we are aware of limited, targeted attacks directed at Microsoft Word 2010.

This blog will discuss mitigations and temporary defensive strategies that will help customers to protect themselves while we are working on a security update. This blog also provides some preliminary details of the exploit code observed in the wild.

Mitigations and Workaround

The in the wild exploit takes advantage of an unspecified RTF parsing vulnerability combined with an ASLR bypass, which depends by a module loaded at predictable memory address.

First, our tests showed that EMET default configuration can block the exploits seen in the wild. In this case, EMET’s mitigations such as “Mandatory ASLR” and anti-ROP features effectively stop the exploit. You can find more information about EMET at http://www.microsoft.com/emet. The exploit code seems to target Word 2010 and it deeply relies on the specific ASLR bypass mentioned. We were glad to see in our tests that this exploit fails (resulting in a crash) on machines running Word 2013, due to the ASLR enforcement introduced for this product.

In addition to EMET mitigations, users may consider to apply stronger protections by blocking the root cause of the issue with one of the following suggested workarounds:

• disable opening of RTF files;

• enforce Word to open RTF files always in Protected View in Trust Center settings.

To facilitate deployment of the first workaround, we are providing a Fix it automated tool. The Fix it uses Office’s file block feature and adds few registry keys to prevent opening of RTF files in all Word versions. After the Fix it is installed, opening RTF file will result in the following message:

If blocking RTF files is not an option, enterprise could enforce “Open selected file types in Protected View” instead of “Do not open selected file types” in Trust Center settings. The “Protected View” mode in Office 2010/2013 does not allow ActiveX controls to load. This will mitigate the attack we observed. Once the workaround is enabled, Word will prompt the Protected View gold bar, but will still allow the preview of the document.

Enterprise admins may also consider to make their own custom protection using Trust Center features of Office instead of the Fix it, since these settings can be managed and deployed through GPO. For more details, please refer to: http://office.microsoft.com/en-us/word-help/what-is-file-block-HA010355927.aspx#_File_Block_settings.

Theoretical Outlook attack vector

There is a theoretical Outlook attack vector for RTF vulnerabilities through the preview pane. The reduced functionality of the preview pane makes this attack vector extremely hard to carry, and to date we have never seen exploits leveraging this mechanism.

Technical details of the exploit

The attack detected in the wild is limited and very targeted in nature. The malicious document is designed to trigger a memory corruption vulnerability in the RTF parsing code. The attacker embedded a secondary component in order to bypass ASLR, and leveraged return-oriented-programming techniques using native RTF encoding schemes to craft ROP gadgets. The structure of the malicious document and the individual blocks is described in the picture below.

When the memory corruption vulnerability is triggered, the exploit gains initial code execution and in order to bypass DEP and ASLR, it tries to execute the ROP chain that allocates a large chunk of executable memory and transfers the control to the first piece of the shellcode (egghunter). This code then searches for the main shellcode placed at the end of the RTF document to execute it.

One peculiar aspect of the main shellcode is the fact that it employs multiple consecutive layers of decryption and well-known anti-debugging tricks, such as test of debugging flags an, RDTSC timing checks and jump-hops over hooks, possibly to defeat automated sandbox, analysis tools and researchers. The shellcode has also been programmed with a special date-based deactivation logic. In fact, it parses the content of “C:\Windows\SoftwareDistribution\ReportingEvents.log” file and it scans all the available Microsoft updates installed on the machine. The shellcode will not perform any additional malicious action if there are updates installed after April, 8 2014. This means that even after a successful exploitation with reliable code execution, after this date the shellcode may decide to not drop the secondary backdoor payload and simply abort the execution. When the activation logic detects the correct condition to trigger, the exploit drops in the temporary folder a backdoor file named ‘svchost.exe’ and runs it. The dropped backdoor is a generic malware written in Visual Basic 6 which communicates over HTTPS and relies on execution of multiple windows scripts via WScript.Shell and it can install/run additional MSI components.

Detection and indicators for defenders

We are providing a good list of IOCs (Indicator of Compromise) hoping to facilitate defensive efforts and to help security vendors and professionals to stay protected from this specific attack. The remote C&C server used by the current backdoor in the file uses encrypted SSL traffic with a static self-signed certificate that can be easily detected.

- Chengyun Chu and Elia Florio, MSRC Engineering