Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

March, 2014

  • 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.

     

     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.exe

    MD5: 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 AM

    Public Key Length: 1024 bits
    Public Key: UnusedBits = 0

        0000  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 01

    Cert 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

     

  • When ASLR makes the difference

    We wrote several times in this blog about the importance of enabling Address Space Layout Randomization mitigation (ASLR) in modern software because it’s a very important defense mechanism that can increase the cost of writing exploits for attackers and in some cases prevent reliable exploitation. In today’s blog, we’ll go through ASLR one more time to show in practice how it can be valuable to mitigate two real exploits seen in the wild and to suggest solutions for programs not equipped with ASLR yet.

     

    Born with ASLR

    ASLR mitigation adds a significant component in exploit development, but we realized that sometimes a single module without ASLR loaded in a program can be enough to compromise all the benefits at once. For this reason recent versions of most popular Microsoft programs were natively developed to enforce ASLR automatically for every module loaded into the process space. In fact Internet Explorer 10/11 and Microsoft Office 2013 are designed to run with full benefits of this mitigation and they enforce ASLR randomization natively without any additional setting on Win7 and above, even for those DLLs not originally compiled with /DYNAMICBASE flag. So, customers using these programs have already a good native protection and they need to take care only of other programs potentially targeted by exploits not using ASLR.

     

    ASLR effectiveness in action

    Given the importance of ASLR, we are taking additional efforts to close gaps when ASLR bypasses arise in security conferences from time to time or when they are found in-the-wild used in targeted attacks. The outcome of this effort is to strength protection also for previous versions of Microsoft OS and browser not able to enforce ASLR natively as IE 10/11 and Office 2013 can do. Some examples of recent updates designed to break well-known ASLR bypasses are showed in the following table.

    MS BULLETIN

    ASLR BYPASS

    REFERENCE

    MS13-063 

    LdrHotPatchRoutine

    Ref: http://cansecwest.com/slides/2013/DEP-ASLR%20bypass%20without%20ROP-JIT.pdf

    Reported in Pwn2Own 2013, works only for Win7 x64 

    MS13-106 

    HXDS.DLL (Office 2007/2010)

    Ref: http://www.greyhathacker.net/?p=585

    Seen used in-the-wild with IE/Flash exploits
    (CVE-2013-3893, CVE-2013-1347,
    CVE-2012-4969, CVE-2012-4792)


    MS14-009 

    VSAVB7RT.DLL (.NET)

    Ref: http://www.greyhathacker.net/?p=585

    Seen used in-the-wild with IE exploits
    (CVE-2013-3893)


    We were glad to see the return of these recent ASLR updates in two recent attacks: the Flash exploit found in February (CVE-2014-0502) in some
    targeted attacks and a privately reported bug for IE8 (CVE-2014-0324) just patched today. As showed from the code snippets below, the two exploits would not have been effective against fully patched machines with MS13-106 update installed running Vista or above.

     

     

    Exploit code for CVE-2014-0502 (Flash)

    Unsuccessful attempt of ASLR bypass using HXDS.DLL fixed by MS13-106.

    NOTE: the code attempts also a second ASLR bypass based on Java 1.6.x

     

    Exploit code for CVE-2014-0324 (IE8)

    Unsuccessful attempt of ASLR bypass using HXDS.DLL fixed by MS13-106.


    Solutions for non-ASLR modules

    The two exploit codes above shows another important lesson: even if Microsoft libraries are compiled natively with ASLR and even if we work hard to fix known ASLR gaps for our products, there are still opportunities for attackers in using third-party DLLs to tamper the ASLR ecosystem. The example of Java 1.6.x is a well-known case: due to the popularity of this software suite and due to the fact that it loads an old non-ASLR library into the browser (MSVCR71.DLL), it became a very popular vector used in exploits to bypass ASLR. In fact, security researchers are frequently scanning for popular 3rd party libraries not compiled with /DYNAMICBASE that can allow a bypass; the following list is just an example of few common ones.

     

    3rd PARTY ASLR BYPASS

    REFERENCE

    Java 1.6.x (MSVCR71.DLL)

     Very common ASLR bypass used in-the-wild for multiple CVEs

     NOTE: Java 1.7.x uses MSVCR100.DLL which supports ASLR

    DivX Player 10.0.2

    Yahoo Messenger 11.5.0.228

    AOL Instant Messenger 7.5.14.8

     Ref: http://www.greyhathacker.net/?p=756 
     (not seen in real attacks)

     

    DropBox

     Ref:http://codeinsecurity.wordpress.com/2013/09/09/installing-dropbox-prepare-to-lose-aslr/

     (not seen in real attacks)

     

    veraport20.Veraport20Ctl

    Gomtvx.Launcher

    INIUPDATER.INIUpdaterCtrl

     Ref: KISA report http://boho.or.kr/upload/file/EpF448.pdf

     (seen in-the-wild with CVE-2013-3893)

     

     

    As noted at beginning of this blog, Internet Explorer 10/11 and Office 2013 are not affected by ASLR bypasses introduced by 3rd party modules and plugins. Instead, customers still running older version of Internet Explorer and Office can take advantage of two effective tools that can be used to enforce ASLR mitigation for any module:

    Conclusions

    ASLR bypasses do not represent vulnerabilities, since they have to be combined with a real memory corruption vulnerability in order to allow attackers to create an exploit, however it's nice to see that closing ASLR bypasses can negatively impact the reliability of certain targeted attacks. We encourage all customers to proactively test and deploy the suggested tools when possible, especially for old programs commonly targeted by memory corruption exploits. We expect that attackers will continue increasing their focus and research on more sophisticated ASLR bypasses which rely on disclosure of memory address rather than non-ASLR libraries.

     

    - Elia Florio, MSRC Engineering

     

  • Assessing risk for the March 2014 security updates

    Today we released five security bulletins addressing 23 unique CVE’s. Two bulletins have a maximum severity rating of Critical while the other three have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

    Bulletin Most likely attack vector Max Bulletin Severity Max Exploit-ability Likely first 30 days impact Platform mitigations and key notes
    MS14-012

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. Addresses vulnerability described by Security Advisory 2934088, an issue under targeted attack.
    MS14-013

    (DirectShow)

    Victim browses to a malicious webpage. Critical 3 Unlikely to see reliable exploits developed within next 30 days. Addresses single double-free issue in qedit.dll, reachable via a malicious webpage.
    MS14-014

    (Silverlight)

    Attacker combines this vulnerability with a (separate) code execution vulnerability to execute arbitrary code in the browser security context. Important n/a No chance for direct code execution with this vulnerability. This vulnerability does not result in code execution directly. However, it is a component attackers could use to bypass ASLR.
    MS14-015

    (Kernel mode drivers)

    Attacker running code at low privilege runs exploit binary to elevate to SYSTEM. Important 1 Likely to see reliable exploits developed within next 30 days.
    MS14-016

    (Security Account Manager)

    Attacker able to make API calls to security account manager password API able to brute-force password guessing attempts without triggering account lockout policy. Important n/a No chance for direct code execution with this vulnerability. Attacker must authenticate before calling the affected API. After authenticating, the attacker can choose to guess either their own or other user's password without risk of lockout.

    - Jonathan Ness, MSRC engineering team