Security Research & Defense

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

June, 2013

  • New Bounty Program Details

    Today we announced the upcoming Mitigation Bypass Bounty, the BlueHat Bonus for Defense, and the Internet Explorer 11 Preview Bug Bounty program.  It’s very exciting to finally take the wraps off of these initiatives and we are anticipating some great submissions from the security research community!  These programs will allow us to reward great work by researchers and improve the security of our software – all to the benefit of our customers.  Also, we just like to analyze and fix cool bugs!

    Mitigation Bypass Bounty Program

    Security features such as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) have made it increasingly difficult and costly to exploit vulnerabilities on modern systems.  As a consequence of this, good exploitation techniques that work reliably when exploiting vulnerabilities on modern systems have become increasingly valuable.  By learning about novel exploitation techniques, we can design better defenses that help protect our customers even when they are running software with an unknown vulnerability or a vulnerability that has not yet been addressed through a security update.  This is why we are announcing the Mitigation Bypass Bounty program.

    Anatomy of a good report

    A high quality submission to the mitigation bypass bounty program will describe and demonstrate a truly novel method of exploiting one or more memory corruption vulnerability classes when all modern mitigations are in place (e.g. DEP, ASLR, SEHOP, and so on).  For a submission to eligible, it must include a detailed whitepaper and a functioning exploit which demonstrates the exploitation technique against a real world remote code execution vulnerability. The technique must also meet a high bar: it must be generic and reliable, it must have reasonable requirements, it must apply to a high-risk user mode application domain, and it must be applicable to the latest version of our products.  The complete set of requirements can be found in the official rules.

    A good example of an exploitation technique that could have qualified for the mitigation bypass bounty program is JIT spraying.  This technique was publicly described for the first time in 2010 by Dionysus Blazakis.  It outlined a method of leveraging a Just-In-Time compiler to generate large amounts of partially controlled instructions that could enable alternative instruction streams if executed at a misaligned offset.  As a result, an attacker can implicitly bypass DEP and ASLR and thereby more easily exploit many classes of memory corruption vulnerabilities.  In response to this exploitation technique, multiple software vendors have released JIT compilers that include built-in mitigations for JIT spraying.

    BlueHat Bonus for Defense

    In addition to encouraging researchers to report novel exploitation techniques, we also want to encourage submissions to include recommendations on how an exploitation technique can be mitigated.  Submissions that include a whitepaper that describes an effective, practical, and robust mitigation for a qualifying exploitation technique may qualify for up to an additional $50,000 USD bonus.

    Internet Explorer 11 Preview Bug Bounty Program

    The Security Research and Defense team worked with the core bounty program team to develop the bounty program bug bar for the Internet Explorer 11 Preview Bug Bounty:

    Vulnerability Type

    Crash dump

    Proof of concept

    Functioning exploit

    Whitepaper

    Sandbox escape

    Base Payout Tier

    RCE vulnerability

    optional

    required

    required

    required

    required

    Tier 0

    Could exceed

    $11,000 USD*

    optional

    required

    required

    required

    optional

    optional

    required

    required

    optional

    optional

    Tier 1

    maximum payment

    $11,000 USD

    optional

    required

    n/a

    optional

    optional

    Tier 2

    minimum payment

    $1,100 USD*

    Important or higher severity design-level vulnerability

    optional

    required

    Proof of Concept is

    sufficient

    optional

    optional

    Eligible security bugs that also have privacy implications

    optional

    required

    optional

    optional

    optional

    ASLR Info Disclosure Vulnerability

    optional

    required

    n/a

    optional

    n/a

    Tier 3

    minimum payment

    $500 USD*

    Sandbox Escape Vulnerability

    optional

    required

    optional

    optional

    required

     

    More detail on the submission criteria is available in the official guidelines.  One area worth highlighting is our additional focus on eligible security bugs that also have privacy implications.  While these bugs would be considered as vulnerabilities in their own right, we thought it was important to highlight them and actively incentivize research that furthers our longstanding commitment to privacy.

    Anatomy of a good report

    The quality and completeness of a submission determines not only the payout but also the priority in which it will be reviewed.  High quality submissions should include a detailed analysis of a vulnerability’s root cause in addition to a proof of concept that reliably reproduces the issue.  This information helps us rapidly confirm your findings so that you can get paid!

    The highest rewards will go to submissions that include a fully functioning exploit which concretely demonstrates that remote code execution is possible.  This means the exploit must be capable of bypassing exploit mitigations such as DEP and ASLR.  These submissions allow us to study the exploitation techniques that were used to achieve code execution and thereby identify opportunities for new exploit mitigation features.  In this way, we can increase the cost and difficulty of exploiting entire classes of vulnerabilities rather than simply addressing a single vulnerability at a time.

    Triage

    The SRD team is also responsible for technical triage on issues as they come in.  We’ve invited several security researchers on contract with Microsoft to help us in this effort.  Our current roster of analysts is as follows:

    • Memory corruption issues
      • Richard van Eeden
      • Ken Johnson
      • Michal Chmielewski
      • Kostya Kortchinsky
      • Matt Miller

    • Design level issues
      • Mario Heiderich
      • Manuel Caballero
      • David Ross

     

    • Internet Explorer Engineering
      • Jim Fox
      • Wilson Guo
      • Forbes Higman
      • Prashant Singh

    We are currently aiming to provide feedback and confirmation of payout within two weeks of a report.

    Finally, please remember that the IE11 Preview Bug Bounty runs between June 26 and July 26, 2013, so make sure to get your reports wrapped up and submitted in time.

    Next steps

    We are incredibly excited to get these programs underway and are really looking forward to seeing the submissions that come in. 

     - Matt Miller and David Ross, SRD Bloggers

    *Postings are provided "AS IS" with no warranties, and confer no rights.*

  • EMET 4.0 now available for download

    We are pleased to announce that the final release of version 4.0 of the Enhanced Mitigation Experience Toolkit, best known as EMET, is now finally available for download. You can download it from http://www.microsoft.com/en-us/download/details.aspx?id=39273.

    We already mentioned some of the new features introduced in EMET 4: Certificate Trust, mitigations improvement hardening, and the Early Warning Program. During our beta period we added new features and solved application compatibility issues that have been reported both externally and internally. Below is a summary of the changes and enhancements:

    Redesigned User Interface: We realized that with the addition of the new features introduced in EMET 4.0 Beta, the old graphical user interface was not as effective and easy to use. For this reason, we decided to re-design EMET’s GUI to facilitate and streamline the configuration operations. We also added the possibility to select the look-and-feel of EMET from a set of skins that we included. Finally, the new user interface is accessible and will change automatically according to your system settings:

     

    Configuration Wizard: We know that configuration can be challenging when installing EMET for the first time. In EMET 3.0 we added the Protection Profiles, which were used to facilitate the initial configuration for applications. With EMET 4.0 we are introducing a Configuration Wizard that will automatically configure EMET with a standard set of SSL certificate pinning rules as well as a list of applications to protect. It also can preserve existing EMET 3.0 settings, and gives the possibility to add standard configuration for the new features. The Configuration Wizard will start automatically during EMET’s installation and can also be accessed, at any time, from EMET GUI. Advanced users can choose to apply a standard configuration through the Configuration Wizard and then customize EMET’s configuration afterwards according to their needs.

    Changes in Certificate Trust: We made a few changes to the Certificate Trust feature, based on users’ feedback, further internal investigation, and partnership with third party online services. We added a new exception to the SSL certificate pinning rules that if enabled will make EMET verify just the Public Key component of the Root CAs present in the rule without matching subject name and serial number. Additionally, we made the Certificate Trust feature available on 64-bit versions of Internet Explorer. Finally, we added to the previous default rules for Microsoft online services new rules also for Twitter, Facebook, and Yahoo!.

    Updated Group Policy profiles: Enterprise customers will notice that we updated our Group Policy profiles to include not only the ability to configure system and application mitigations, but also the reporting mechanisms, the advanced mitigation configurations, and the exploit action.

    If you have EMET 4.0 Beta or EMET 3.5 Technical Preview installed on the system, you will need to uninstall them before installing EMET 4.0, and you will need to remove EMET’s configuration from the registry, by deleting the registry hives HKLM\Software\Microsoft\EMET and, if existing, HKLM\Software\Policies\Microsoft\EMET. If you have EMET 3.0 installed on the system, you don’t need to uninstall it before installing EMET 4.0. The previous version will be uninstalled and at the end of the installation you’ll have the opportunity to migrate the existing settings or to reset EMET configuration with the new default settings.

    We want to thank those of you that downloaded EMET 4.0 Beta in the past two months and that provided valuable feedback that greatly helped us finalize EMET 4.0. In particular, we want to thank the Yang Yu from NSFocus security team that reported a technique that allowed to bypass EMET’s protections, and Adam Langley and Cem Paya from Google for feedback on the Certificate Trust feature. As said, we received many, many emails, and it would be impossible to name all the people that provided feedback for EMET 4.0 Beta. You know who you are, and we really appreciated your effort in testing EMET and reaching out to us to provide feedback. Again, thank you!

    We truly hope that you enjoy all the new features that we introduced in EMET 4.0. We will continue working on improving EMET to provide better and better protections against internet attacks for customers and to make it even more user friendly and easy to use.

    -          The EMET Team: Ali Rahbar, Chengyun Chu, Cristian Craioveanu, Dan Beenfeldt, Elia Florio, Elias Bachaalany, Gerardo Di Giacomo, Jonathan Ness, Matt Miller, Neil Sikka, Nitin Kumar Goel, Ken Johnson 

  • MS13-051: Get Out of My Office!

    MS13-051 addresses a security vulnerability in Microsoft Office 2003 and Office for Mac. Newer versions of Microsoft Office for Windows are not affected by this vulnerability, but the newest version of Office for Mac (2011) is affected. We have seen this vulnerability exploited in targeted 0day attacks in the wild. In this blog we’ll cover the following aspects:

    • Technical Details
    • Attack Pattern
    • Advice for Detection

    Technical Details

    In the Office PNG file parsing code, there is a vulnerability where the length field of a chunk is not correctly checked. The PNG specification (http://www.w3.org/TR/PNG/#5Chunk-layout) says “Although encoders and decoders should treat the length as unsigned, its value shall not exceed 2^31-1 bytes.” However, in the malicious PNG files, we found the length field of a chunk equal to 0xFFFFFFFF. The PNG parsing code correctly treated this field as unsigned (as specified in the PNG spec), but was not catching the case when the value was 0xFFFFFFFF, which if interpreted as an unsigned value, exceeds 2^31-1. Below is what the malicious chunk size looks like (highlighted in yellow):

    Shellcode analysis shows that the exploit for this vulnerability was a classic stack based buffer overflow, which wrote far past the end of a buffer on the stack, thereby overwriting control data on the program’s stack, eventually leading to high-jacking the program’s execution. Older versions of Office/Windows don’t have mitigations for these types of exploits, but newer versions of Office/Windows do. This is an example of how running current software can increase an organization’s security. We verified also that EMET 3.0 (and above) is able to stop the exploits observed so far, providing an additional mitigation against this specific attack.

    Attack Pattern

    The attacks we observed were extremely targeted in nature and were designed to avoid being investigated by security researchers. The malicious samples observed are Office documents (Office 2003 binary format) which do not include the malicious PNG file embedded directly in the document. Rather, the documents reference a malicious PNG file loaded from Internet and hosted on a remote server.

    Attackers also equipped their servers with scripts which avoid serving the PNG exploit multiple times, in an effort to keep this 0day more concealed. We believe that the limited attacks observed were geographically located mostly in Indonesia and Malaysia.

    Advice for Detection

    The common pattern for all these documents is the filename “space.gif” used by each malicious file to fetch the remote PNG file containing the exploit. In order to help security vendors and enterprises look for potential indicators and to deliver an effective protection, we are providing some of the URLs used to load the remote PNG exploit and hashes of the malicious Office binary format documents observed in these limited targeted attacks.

    hXXp://intent.nofrillspace.com/users/web11_focus/4307/space.gif
    hXXp://intent.nofrillspace.com/users/web11_focus/3807/space.gif
    hXXp://mister.nofrillspace.com/users/web8_dice/3791/space.gif
    hXXp://mister.nofrillspace.com/users/web8_dice/4226/space.gif
    hXXp://www.bridginglinks.com/somebody/4698/space.gif
    hXXp://www.police28122011.0fees.net/pages/013/space.gif
    hXXp://zhongguoren.hostoi.com/news/space.gif
    
    MD5 SHA1
    fde37e60cc4be73dada0fb1ad3d5f273 1bdc1a0bc995c1beb363b11b71c14324be8577c9
    2f1ab543b38a7ad61d5dbd72eb0524c4 2a33542038a85db4911d7b846573f6b251e16b2d
    7eb17991ed13960d57ed75c01f6f7fd5 d6a795e839f51c1a5aeabf5c10664936ebbef8ea
    70511e6e75aa38a4d92cd134caba16ef f362feedc046899a78c4480c32dda4ea82a3e8c0
    28e81ca00146165385c8916bf0a61046 f751cdfaef99c6184f45a563f3d81ff1ada25565
    35a6bbc6dda6a1b3a1679f166be11154 f7f1c39b42453f0b27b601f32c0af3cce99f79db

    Thanks to Andrew Lyons and Neel Mehta of Google Inc for the report, and to Elia Florio and Cristian Craioveanu for helping with this case.

    - Neil Sikka, MSRC Engineering
    @neilsikka

  • Assessing risk for the June 2013 security updates

    Today we released five security bulletins addressing 23 CVE’s. One bulletin has a maximum severity rating of Critical, and four 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 rating Likely first 30 days impact Platform mitigations and key notes
    MS13-047

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. 19 CVE’s being addressed.
    MS13-051

    (Office 2003)

    Victim opens malicious Office document. Important 1 Limited, targeted attacks seen exploiting single CVE addressed by this update. Affects Office 2003 and Office for Mac 2011. See this SRD blog post for more information about the attacks.
    MS13-049

    (Windows networking)

    Attacker establishes thousands of connections of a certain type to victim listening on a TCP/IP port, exhausting non-paged pool memory. This causes a denial of service condition where networking stack (or entire system) must be restarted. Important 3 No chance for direct code execution. Denial of service only. Can only be triggered from the local machine on Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. Rated Moderate on those platforms.
    MS13-050

    (Print spooler)

    Attacker who is already running code on a machine uses this vulnerability to elevate from low-privileged account to SYSTEM. Important 1 Likely to see reliable exploits developed for denial-of-service within next 30 days.  
    MS13-048

    (Windows kernel)

    Attacker who is already running code on a machine uses this vulnerability to bugcheck machine or leak kernel memory addresses. Important 3 No chance for direct code execution. Denial of service or information disclosure only.  

    - Jonathan Ness, MSRC Engineering