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:

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/3124.pic1.png)

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.

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/0118.pic2.png)

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.

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/1212.pic3.png)

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.

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/pic4.png)

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.

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/pic5.png)

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.

YARA RULE (RTF)

rule SA2953095_RTF { meta: description = “MS Security Advisory 2953095” strings: $badHdr = “{\\rt{” $ocxTag = “\\objocx\\” $mscomctl = “MSComctlLib.” $rop = “?\\u-554"condition: filesize > 100KB and filesize < 500KB and $badHdr and $ocxTag and $mscomctl and #rop>8 }

SAMPLE HASHES

Filename: %TEMP%\svchost.exeMD5: af63f1dc3bb37e54209139bd7a3680b1 SHA1: 77ec5d22e64c17473290fb05ec5125b7a7e02828

C&C SERVER AND PROTOCOL

C&C Server: h ps://185.12.44.51 Port: 443*NOTE: on port 80 the C&C host serves a webpage mimicking the content of “http://www.latamcl.com/” website GET request example: h ps://185.12.44.51/[rannd_alpa_chars].[3charst]?[encodedpayload] User-Agent string: “Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64;2*Uuhgco}%7)1”

C&C SSL CERTIFICATE (self-signed)

Issuer: CN=* O=My Company Ltd S=Berkshire C=NW NotBefore: 1/1/2013 3:33 AM NotAfter: 1/1/2014 3:33 AMPublic Key Length: 1024 bits Public Key: UnusedBits = 00000 30 81 89 02 81 81 00 dc 72 fc af 8f 51 de 2d 27 0010 3e de ad 21 ae 25 11 b6 b0 6e ce 6d 79 e4 d3 81 0020 4e 73 11 44 51 63 09 3b 1c e7 79 1f 85 82 94 c1 0030 e1 f1 83 b3 1c 6d 53 58 28 07 b5 80 86 30 51 2d 0040 78 c0 48 e8 b2 8d fb 84 e1 d1 59 ff d5 4e 1f 8f 0050 ff 60 44 56 6b 7b 4d 72 42 d6 da 6a 4c d4 6b 7d 0060 f1 68 4d 2c 62 58 53 e7 cd cc a1 a4 a2 7a 29 7d 0070 63 eb 42 30 af 24 eb 20 4c 86 f5 9e 6f 48 1c bd 0080 28 aa 47 13 4b cc 53 02 03 01 00 01Cert Hash(md5): f0 82 aa f8 16 0e 83 8c 20 d7 95 f0 9d d2 01 57 Cert Hash(sha1): df 72 40 fb 9b cd 53 12 eb a5 f9 c2 dd e7 a2 9a 1d c8 f3 55

CRASH INDICATORS

Faulting application name: WINWORD.EXE, version: 14.0.7113.5001, time stamp: 0x52866c04 Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc0000005 Fault offset: 0x40002??? Faulting process id: n/a Faulting application start time: n/a Faulting application path: C:\Program Files\Microsoft Office\Office14\WINWORD.EXE Faulting module path: unknown

REGISTRY INDICATORS

Registry key added: HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\Windows Startup Helper=”%windir%\system32\wscript.exe %TEMP%\[malicious.vbs]”Service name (possibly) created: “WindowsNetHelper”

- Chengyun Chu and Elia Florio, MSRC Engineering