Building a Safer, More Trusted Internet Through Information Sharing

Microsoft Security Response Center Progress Report

July 2011 June 2012
A report from the Microsoft Security Response Center (MSRC) on the progress of various initiatives that share information to foster deeper industry collaboration, increase community-based defenses, and better protect customers. This report also includes an update on the Microsoft BlueHat Prize.

microsoft.com/msrc

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. Copyright 2012 Microsoft Corporation. All rights reserved. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

MSRC PROGRESS REPORT 2012

Authors and contributors

Microsoft Security Response Center Elias Bachaalan Bill Barlowe Suha Can Chengyun Chu Mark Oram Chris Rae Mike Reavey Jeremy Tinder Microsoft Trustworthy Computing Communications Dustin Childs Ken Malcolmson Georgeo Pulikkathara Tim Rains

MICROSOFT SECURITY RESPONSE CENTER

Table of Contents
Foreword .................................................................................................................................................. 4 Microsoft Security Bulletin statistics .............................................................................................. 5 MS11-100: Behind the scenes with an out-of-band security bulletin......................... 7 Microsoft Active Protections Program ....................................................................................... 12 More than just information sharing .......................................................................................13 Microsoft Active Protections Program partner feedback ..............................................14 Microsoft Exploitability Index ........................................................................................................ 16 Microsoft Exploitability Index statistics .................................................................................18 Microsoft Vulnerability Research .................................................................................................. 20 MSVR advisories .............................................................................................................................20 MSVR program statistics .............................................................................................................22 Coordinated Vulnerability Disclosure ....................................................................................23 Microsoft BlueHat Prize contest ................................................................................................... 26 The Enhanced Mitigation Experience Toolkit (EMET) .....................................................27 Conclusion............................................................................................................................................. 30

MSRC PROGRESS REPORT 2012

Foreword
Welcome to the Microsoft Security Response Center (MSRC) annual progress report, which covers the 12 months ending in June 2012. This report provides an update on key MSRC programs and projects, and provides analysis of some of the work that the MSRC and its ecosystem partners have done over the past year. For example, weve helped address 96 vulnerabilities affecting 39 different vendors using coordinated vulnerability disclosure and our Microsoft Vulnerability Research Program. And through the use of the Exploitability Index, customers can make better risk decisions and potentially reduce the number of security updates that require rapid deployment by up to 76 percent. One of the MSRCs most exciting activities this year was the announcement of the inaugural BlueHat Prize. The Prize challenged security researchers to design a novel runtime mitigation technology designed to prevent the exploitation of memory safety vulnerabilities. By the time the contest closed in April 2012, we received 20 qualifying entries (and answered a lot of questions from researchers and potential participants). It was great to see such innovative thinking taking place in the field of software security research. When we announce the winner at Black Hat USA 2012, one of the finalists will walk away with a check for US $200,000! Although the submissions and the responses have been impressive, we didnt stop at a contest. This week we are releasing a new beta version of the freely available Enhanced Mitigation Experience Toolkit (EMET) tool that will incorporate some of the technology designed by one of our BlueHat Prize finalists. The fact that the BlueHat Prize has gone from initial announcement to real protection for customers within a single calendar year shows the positive impact that is possible through collaboration within the security community. Also in this report is a look at how the MSRC responds when a serious security threat appears. If youve ever wondered what happens behind the scenes in one of these events, heres your chance to find out. Mike Reavey Senior Director, Microsoft Security Response Center

MICROSOFT SECURITY RESPONSE CENTER

Microsoft Security Bulletin Statistics

The most publicly visible work that the Microsoft Security Response Center (MSRC) performs is coordinating the development, testing, and release of Microsoft security updates that address vulnerabilities in Microsoft software. This section describes some of the key vulnerability trends involving Microsoft software during the 12 months from July 2011 through June 2012. It provides some forward-looking thoughts on future trends, and highlights tools and processes that organizations can use to help minimize the potential for disruption caused by security update deployment. Vulnerabilities are weaknesses in software that enable an attacker to compromise the integrity, availability, or confidentiality of that software or the data it processes. Some of the most severe vulnerabilities enable attackers to run code of their choice, potentially compromising the computer system. The disclosure of a vulnerability is the revelation of a vulnerability to the software vendor, or to the public at large. Disclosures can come from various sources, including software vendors, security software vendors, independent security researchers, and those who create malicious software (also known as malware). It is impossible to completely prevent vulnerabilities from being introduced during the development of large-scale software projects. As long as human beings write software code, no software will be perfect and mistakes that lead to imperfections in software will be made. Some imperfections (or bugs) simply prevent the software from functioning exactly as intended, but other bugs may present vulnerabilities. Not all vulnerabilities are equal; some vulnerabilities wont be exploitable because specific mitigations prevent attackers from using them. Nevertheless, some percentage of the vulnerabilities that exist in a given piece of software could be exploitable.1 Many software developers address vulnerabilities by releasing security updates. Microsoft has evolved mature and proven processes to help ensure that highquality security updates are developed, tested, and released in a timely and
1

www.microsoft.com/security/msrc/whatwedo/updates.aspx

MSRC PROGRESS REPORT 2012

predictable manner. See the white paper Software Vulnerability Management at Microsoft for more details on these processes. During the 12 months ending June 2012, Microsoft released a total of 90 security bulletins to address 203 individual vulnerabilities. Software vulnerabilities are enumerated and documented in the Common Vulnerabilities and Exposures (CVE) list,2 a standardized repository of vulnerability information. There was one out-of-band security bulletin released during this period: MS11100, published on December 29, 2011. For more information, see MS11-100: Behind the scenes with an out-of-band security bulletin on page 7.
Figure 1. Bulletins issued and CVEs addressed, 1H071H123
180 160 140 120 100 80 60 40 20 0 1H07 2H07 1H08 2H08 1H09 2H09 1H10 2H10 1H11 2H11 1H12 35 34 78 58 36 42 27 47 41 97 85 65 52 48 42 104 153 130

CVEs and Security Bulletins Issued

114

110 93 Bulletins CVEs

51

Lower numbers of vulnerabilities that could lead to remote code execution Vulnerabilities that could lead to remote code execution are potentially the most dangerous type of vulnerability, because of the level of control they might be able
cve.mitre.org The nomenclature used to refer to different reporting periods is nHyy, where nH refers to either the first (1) or second (2) half of the year, and yy denotes the year. For example, 2H11 represents the period covering the second half of 2011 (July 1 through December 31), and 1H12 represents the period covering the first half of 2012 (January 1 through June 30).
2 3

MICROSOFT SECURITY RESPONSE CENTER

to provide an attacker over a vulnerable computer. Security bulletins that address these vulnerabilities are typically issued with a severity level of Critical. Of the vulnerabilities addressed by Microsoft from July 2011 to June 2012, 50.0 percent could allow remote code execution by an attacker, down from 62.8 percent during the previous 12-month period.
Figure 2. Percent of vulnerabilities affecting Microsoft products with potential remote code execution, July 2007June 2012
80%

Percent of Vulnerabilities Affecting Microsoft Products

70% 60%

50%
40% 30% 20% 10%

0%
Jul 2007 - Jun 2008 Jul 2008 - Jun 2009 Jul 2009 - Jun 2010 Jul 2010 - Jun 2011 Jul 2011 - Jun 2012

MS11-100: Behind the scenes with an out-of-band security bulletin

Most Microsoft security bulletins are released on the second Tuesday of each month, a consistent and predictable schedule designed to help IT departments plan security update rollouts in advance and deploy them with minimal disruption. On rare occasions, when the serious nature of a vulnerability justifies departing from this schedule, Microsoft releases an out-of-band security bulletin to address the vulnerability in advance of the next scheduled update. The decision to release a security update out-of-band is made as part of the Software Security Incident Response Process (SSIRP). SSIRP is the standard

MSRC PROGRESS REPORT 2012

Microsoft process for developing, testing, deploying, and communicating information about a security update in an emergency.4 A typical SSIRP is a flurry of focused activity, as engineers at Microsofts corporate headquarters and across the globe work around the clock to provide customers with the necessary information, guidance, mitigation steps, and tools to react appropriately to a threat. In this section, Jeremy Tinder, a program manager with the MSRC, describes the experience of working on the SSIRP that led to the publication of Microsoft Security Bulletin MS11-100 out-of-band on December 29, 2011.
It was 8:03 P.M. the day after Christmas and I was winding down for the night after enjoying the first holiday with my baby girl. My phone buzzed. I checked my mail and saw a meeting invitation from my manager, Dave Midturi. Subject: SSIRP Bulletin Draft Location: Your Office Time: December 27th, All Day Hey Jeremy, I hate to do this but I am going to need a lot of help tomorrow and the day after drafting a crazy bulletin from scratch. Thanks, Dave I was on call this holiday, and it had been fairly quiet for the most part. We rotate this duty over the various holidays; I was off for Christmas last year so I decided to volunteer this year in exchange for taking Thanksgiving off. I had been monitoring my email all weekend in case something critical came in over the holiday. This shouldnt be too bad, I thought, pondering the email. Ramping up on the case and writing the bulletin wont take too long. Little did I realize that I also needed to draft a security advisory and write the CVEs from three other cases in the next two days.

See www.microsoft.com/security/msrc/whatwedo/responding.aspx for more information about the SSIRP.

MICROSOFT SECURITY RESPONSE CENTER

I arrived at work the next day, December 27, just before 7:00 A.M. in order to get a head start on getting up to speed. When Dave arrived, he briefed me on the situation. A security researcher was going to discuss the details of a security vulnerability (later designated CVE-2011-3414) at a security conference the next day. This vulnerability concerned a flaw in the way several popular web frameworks (including ASP.NET, PHP, and Java, among others) processed certain specially crafted requests. By submitting a large number of these requests to a vulnerable web server, an attacker could quickly overwhelm the servers processor, causing performance to degrade to the point of creating a denial-of-service (DoS) condition. This DoS vulnerability could easily be used to disrupt some very large ecommerce sites if it were to be exploited. Given the risk the vulnerability posed to our customers and the timing of the holiday season, it was clear that we needed to act swiftly and put out protections as quickly as we could. The .NET team had already been working around the clock through the holiday weekend on a security update that would address the vulnerability. It was time to bring the release team together to expedite the publication of the update, and I was jumping in feet first. I had a lot of catching up to do and not much time in which to do it. I spent the rest of the morning poring over the notes the .NET team had produced thus far during their investigation of the vulnerability and development of the update. We would be meeting with the .NET team later in the day, and I wanted to learn as much as I could about the root cause, affected software, mitigations, and workarounds so I would know which questions to ask. Thai food was delivered in the early afternoon for everyone working on the SSIRP, which allowed me to take a quick break and refuel. I met up with the .NET team and some other MSRC folks, and we spent the next five hours in a meeting room reviewing the security advisory in preparation for release. Microsoft Security Advisories give us a way to communicate important security information to customers in cases in which a bulletin-class security update is not possible or not warranted. In this case, we needed to publish a security advisory in advance of the upcoming bulletin to help our customers mitigate or work around the danger while we were still working on the security update.

MSRC PROGRESS REPORT 2012

By 6:00 P.M., the security advisory was just about done. The only outstanding action item was to decide when to release it. We scheduled a meeting 45 minutes out to discuss the details, allowing time for everyone involved with the release to travel to the work room from various other buildings around the Microsoft campus. In the meantime, pizza was being ordered, and I had time to freshen up. I needed to clear my head after being hard at it for almost 12 hours, so I decided to get in a short 30-minute run and a shower while everyone gathered. It was just what I needed. After a few slices of pizza and a bottle of water, I was ready to go for another half-day. In the course of the next four hours, the plan changed about four times as details emerged in real time, requiring me to adjust the advisory here and there as we identified the best plan to protect customers. We decided that the advisory (designated Microsoft Security Advisory 2659883) would be published the next morning at 5:30 A.M., timed to coincide with the presentation that the security researcher would be giving. We called it quits for the night at 10:00 P.M. or so, and I drove the 60 minutes back to my house to catch a couple hours of sleep. I was back into the office at 6:30 the next morning, Wednesday, December 28. With the advisory published, I had a lot of work to do on the text of the security bulletin itself. Microsoft Security Bulletins are more extensive than security advisories. They include in-depth information about the vulnerabilities addressed, affected products, and the accompanying security update packages, as well as FAQ entries for any known issues that customers may need to understand. Security bulletins often address multiple vulnerabilities that affect the same products or components. In this particular case, we decided that the bulletin we were putting together would address three other ASP.NET vulnerabilities, in addition to the hashtable vulnerability we were working on. The update code for CVEs 2011-3415, 2011-3416, and 2011-3417 was already in the release pipeline and being tested, so adding the hashtable vulnerability to this release vehicle would be the quickest way for us to ship this update in order to protect customers. My job would be to document these additional vulnerabilities for the bulletin.

10

MICROSOFT SECURITY RESPONSE CENTER

I burned through the morning hours with little notice of the things happening around me. My only break was when Chinese food was delivered to the conference room. By 4:00 P.M. I had a first draft of the bulletin to share with the team. After receiving feedback, we spent the next several hours incorporating it into the bulletin and working with our technical writers to clean up some of the language. Late in the evening I had a bulletin I was satisfied with. By this time, Dave and I were the only two left in the conference room. Everyone else had left for the night, and we had worked late enough that the energy-saving lights had automatically turned off. I normally get to work before the lights turn on for the day but this was the first time I had ever arrived before they turned on and left after they turned off. As I was sending my last email and preparing to shut down, I realized that it was 11:55 P.M. and I had been working for more than 17 hours straight. I was exhausted, and driving home at this time of the night was not going to work, especially for a guy that normally goes to bed at 9:30 P.M. every day and wakes up at 4:30 in the morning. I looked over at Dave and said, Dude, Im staying here tonight. There is no way Im going to make it home tonight. Ive got a call with a security researcher tomorrow morning at 8 anyway so I cant really sleep in. Dave was nice enough to call the hotel located across the street and reserve a room for me. I checked in at 12:30 A.M., took a quick shower and went to bed. The next day, December 29, I stopped by the hotel front desk at about 7:00 A.M. to check out, and met the same clerk who had checked me in the night before. Didnt you just check in? he asked, looking at me quizzically. That was a quick night. All in all, it was a pretty exciting week. We pulled some insane hours living in the meeting room (and let me tell you, it needed a good cleaning when we were done!), but the work we did made a major difference, which made it all worth it.

MSRC PROGRESS REPORT 2012

11

Microsoft Active Protections Program

Officially launched in October 2008, the Microsoft Active Protections Program (MAPP)5 supplies Microsoft vulnerability information to security software providers before each Microsoft monthly security update, as well as before out-ofband security updates and advisories. By obtaining security vulnerability information early, partners gain additional time to build software protections for their customers before Microsoft releases security updates to the public. Prior to MAPPs launch, security software providers received vulnerability information at the same time as exploit code writers (approximately 10 A.M. Pacific Time on the second Tuesday of each month, when Microsoft releases its monthly security updates). Because it takes time for customers to deploy security updates, this security update release marked the start of a race between individuals with malicious intent and security software providersa race in which one side hurries to develop attacks while the other side rushes to provide interim customer protections until security updates can be applied. Results reported by Sourcefire, a world leader in real-time adaptive network security, show that before MAPP, approximately eight hours were needed to reverse engineer vulnerability information, develop proof-of-concept (PoC) exploit code, and build protective detection code for the exploit. Eight hours is also about the amount of time a focused attacker needs to generate malicious exploit code after a vulnerability is disclosed. With advance access to vulnerability information through MAPP, Sourcefire reports that their protective process now only takes two hours, and that their developers only have to write the detection code because everything else is provided. The result is that protections are typically released hours ahead of any exploit code, which means that customers are better protected well ahead of even the most focused attackers.

For more information, including a list of MAPP partners, see www.microsoft.com/security/msrc/collaboration/mapp.aspx

5

12

MICROSOFT SECURITY RESPONSE CENTER

Feedback from MAPP partners shows that the number of users who benefit from partner signatures ranges from tens of thousands for smaller specialist companies to hundreds of millions for mass-market vendors. MAPP partners6 represent global markets for antivirus and intrusion detection and prevention systems, and include a mix of medium to large companies that provide active software security protections7 for consumers and enterprises around the world. Partners include companies based in North America, Europe, the Middle East, and Asia. Microsoft security professionals regularly communicate with MAPP members to understand whether the information it is providing helps them achieve their goal of protecting their customers. Information from these discussions is continuously evaluated to ensure the program is meeting its main goal of helping to protect the mutual customers of Microsoft and security providers.

More than just information sharing

Microsoft operates the MAPP program free of charge for security vendors that meet the companys minimum requirements regarding the number of customers they represent and their capability to offer protection. Program applicants are carefully vetted for compliance with the program criteria before being allowed to join.8 Each month, Microsoft security engineers work diligently to create information for MAPP partners that helps them detect the exploitation of security vulnerabilities in Microsoft products. This data includes, but is not always limited to: A detailed technical write-up on the vulnerability. A step-by-step process that partners can follow to parse an affected file format, or network protocol, that identifies which elements need to have particular values, or exceed specific boundaries, to trigger the security vulnerability. Information on how to detect the vulnerability, or exploitation thereof (such as event log entries, or stack traces).

For the most current list of all MAPP partners, see www.microsoft.com/security/msrc/collaboration/mapppartners.aspx. 7 For information on the term active software security protections, see www.microsoft.com/security/msrc/collaboration/mappfaq.aspx. 8 See www.microsoft.com/security/msrc/collaboration/mapp/criteria.aspx for the MAPP program criteria and to submit an application questionnaire.
6

MSRC PROGRESS REPORT 2012

13

A PoC file that contains the specific condition that will trigger the vulnerability, but is not malicious itself. Partners can use this file to test detection signatures they develop.

Microsoft provides this information to participating vendors shortly in advance of the release of a security update. The timeframe is based on partners' ability to release effective protections and also seeks to limit the risk of the information being inadvertently disclosed. After receiving this information, MAPP partners can consult with Microsoft engineers to discuss detailed steps they can take to detect exploitation of a vulnerability. Microsoft also follows up with partner vendors to better understand which vulnerabilities attackers are exploiting in the wild, and how Microsoft can improve the guidance it offers partners and the public to account for specific exploitation methods.

Microsoft Active Protections Program partner feedback

Partners report that the Microsoft Active Protections Program saves them considerable time and effort, and that these savings are passed on to customers by way of more timely and effective software protections. Some feedback Microsoft has received over the last year includes: Our strong partnership with MAPP enhances our capacity to deliver timely solutions to our customers. It gives us the advantage of being in the front row seats in battling future threats and exploits. I applaud MAPP for their continuing initiatives for improvement, and for developing new projects for its partners. Raul Alvarez Senior Malware Analyst Fortinet Technologies Inc

14

MICROSOFT SECURITY RESPONSE CENTER

With Microsoft's MAPP program they continue to set the pace of what other large software companies should be doing from a product security perspective. Working with partners like us to provide additional details to help protect our mutual customers is just one of the great things about the MAPP program. This last year has seen a continued increase of advanced attacks and partnerships between industry continue to be one of the better ways to share information and get ahead of these threats. Marc Maiffret CTO BeyondTrust (formerly eEye Digital Security) Thanks to MAPP, we can now implement detection for new remote exploits within days instead of weeks, which is well before the bad guys are using these new exploits. Bas van Sisseren Head of Research Quarantainenet Labs MAPP provides our researchers with thorough information and shortens our research time. This allows us to provide reliable and accurate protection to our customers quickly and efficiently. With the time saved, we are able to focus on other critical non-Microsoft related vulnerabilities. Karl Lynn Juniper Networks MAPP data provides deep insight into a threat/vulnerability enabling Freescale's VortiQa IPS team to build protection against these threats and provide the same to our customers within a short time in a reliable and accurate manner without false alarms. Srini Addepalli Chief Software Architect Freescale

MSRC PROGRESS REPORT 2012

15

Microsoft Exploitability Index

Through various communication channels, Microsoft provides customers with information about the availability of PoC exploit code or active attacks related to vulnerabilities addressed by Microsoft security updates. The Microsoft Exploitability Index9 was developed in response to customer requests for additional information to better evaluate risk; it provides new data on the likelihood of functioning exploit code being developed so customers have additional guidance to better prioritize the deployment of Microsoft security updates. 10 The main goal of the Exploitability Index is to help customers prioritize their security update deployments. This information enables customers to better identify the security updates that are most important to them and deploy them in a timely manner. For example, a customer might prioritize addressing an Important severity vulnerability that is likely to be exploited in the first 30 days after release of the security update over a Critical vulnerability that is unlikely to ever be exploited. Although most customers use the severity ratings to identify which updates are most worthy of their attention, the Exploitability Index offers additional technical detail that can help security and software deployment teams maximize the benefit of their security resources. This detail includes: The security bulletin ID The bulletin title The CVE ID associated with the specific vulnerability The exploit assessment for code execution on the latest release The aggregate exploitability assessment for code execution on older software releases

For more information on the Microsoft Exploitability Index, see technet.microsoft.com/security/cc998259. Alberts, Bas, A Bounds Check on the Microsoft Exploitability Index (Miami Beach, Fla.: Immunity, Inc., 2008), p.7.
9 10

16

MICROSOFT SECURITY RESPONSE CENTER

The Exploitability Index uses three levels to communicate to customers the likelihood of functioning exploit code being developed. In November 2011 Microsoft changed the level descriptions to simplify and clarify the assessments, and also added a Denial of Service Exploitability Assessment: 1 Exploit code likely. This rating means that MSRC analysis shows that exploit code could be created, allowing an attacker to consistently exploit the vulnerability. For example, an attacker could use the exploit to remotely execute code repeatedly, in a way that produces the same results each time. This exploitability would make the vulnerability an attractive target for attackers, and therefore more likely that exploit code would be created. This designation is also used for vulnerabilities that are already being actively exploited. Customers who review the security bulletin and determine its applicability to their own environment could treat such a vulnerability with a higher priority. 2 Exploit code would be difficult to build. This rating means that MSRC analysis shows that exploit code could be created, but that an attacker would likely have difficulty creating the code. Such difficulty might be the result of the need for expertise and sophisticated timing information, and/or varied results when targeting the affected product. For example, an exploit could cause remote code execution, but may only work one out of 10 times, or one out of 100 times, depending on the state of the computer being targeted and the quality of the exploit code. Although an attacker may increase the consistency of their results by having better understanding and control of the target environment, the unreliable nature of this vulnerability makes it a less attractive target for attackers. Customers who review the security bulletin and determine its applicability within their environment should treat this as a material update. If they are prioritizing against other highly exploitable vulnerabilities, they could rank this lower in their deployment priority. 3 Exploit code unlikely. This rating means that MSRC analysis shows that successfully functioning exploit code is unlikely to be released. It might be possible for exploit code to be released that could trigger the vulnerability and cause abnormal functionality, but it is unlikely that an attacker would be able to create an exploit that could fully exploit the vulnerability. Because vulnerabilities of this type require significant investment by attackers to be useful, the risk of exploit code being created and used within 30 days of a bulletin release is much lower. Therefore, customers who review the security bulletin to determine its applicability within their environment could prioritize this update below other vulnerabilities within a release.

MSRC PROGRESS REPORT 2012

17

The Denial of Service (DoS) exploitability assessment can reflect either of the following:
Figure 3. DoS exploitability assessment used by the Exploitability Index

DoS exploitability assessment

Short definition Exploitation of this vulnerability may cause the operating system or application to become temporarily unresponsive, until the attack is halted, or to exit unexpectedly but automatically recover. The target returns to the normal level of functionality shortly after the attack is finished. Exploitation of this vulnerability may cause the operating system or application to become permanently unresponsive, until it is restarted manually, or to exit unexpectedly without automatically recovering.

Temporary

Permanent

If a vulnerability could allow a permanent denial of service, it would require an administrator to start, restart, or reinstall all or parts of the system. It should be noted that any vulnerability that automatically restarts the system is also considered a permanent DoS. In addition, client applications that are typically intended for interactive use, such as Microsoft Office releases, would not get a DoS Exploitability Assessment. Its important to note that an Exploitability Index of 1 is not a guarantee that exploit code will be developed for that specific vulnerability. Events and other factors in the security ecosystem may make exploitation of a vulnerability financially unattractive or uninteresting. Over time, however, Exploitability Index ratings have been a reliable and effective guide to understanding whether or not a given vulnerability is likely to lead to exploits in the wild.

Microsoft Exploitability Index statistics

The 90 security bulletins Microsoft published from July 2011 to June 2012 resulted in 190 Exploitability Index ratings, as shown in the following table.

18

MICROSOFT SECURITY RESPONSE CENTER

Figure 4. Microsoft Exploitability Index ratings, July 2011June 2012

Exploitability Index rating 1 - Exploit code likely 2 - Exploit code would be difficult to build 3 - Exploit code unlikely Not applicable Total

Latest software release 104 12 34 40 190

Older software releases 122 14 20 34 190

Of the 190 ratings issued from July 2011 through June 2012, none were revised after release. An examination of different possible deployment scenarios illustrates how the Exploitability Index can help save organizations money and allow them to better allocate resources:
Figure 5. Security bulletin deployment events under different scenarios, June 2011June 2012

Deployment scenario Deploy all bulletins within 30 days Deploy only critical bulletins within 30 days after release Deploy only critical bulletins with an XI of 1 on release day Deploy only critical bulletins with an XI of 1 on release day, when all systems are on the most recent product release

Deployment events 90 26 24 21

For example, a customer that deployed all security bulletins within 30 days would have had to test and deploy a total of 90 bulletins from July 2011 to June 2012. By contrast, a customer that only deployed critical updates with an Exploitability Index rating of 1 and used the most recent Windows client and server versions exclusively would have deployed just 21 updates, a difference of more than 76 percent. Microsoft recommends that customers install all applicable security updates, including bulletins with an exploitability index of 3 or a severity rating of Moderate. Exploitation techniques change over time, and newly developed techniques can make it easier for an attacker to exploit vulnerabilities that had previously been more difficult to successfully exploit. Nevertheless, Microsoft recognizes that prioritization decisions will be made within each organization and that time and resources may often be limited. The Exploitability Index allows customers that face such limitations to better prioritize their update deployments.

MSRC PROGRESS REPORT 2012

19

Microsoft Vulnerability Research

In an age in which almost all types of computing devices can be interconnected with each other, the security and privacy of data is more important than ever. In addition, the potential consequences of security vulnerabilities can be much more severe and have a much greater impact on the Internet in general. MSVR was established to provide a mechanism for Microsoft software developers and security researchers to share their collective knowledge and experience with third-party software developers and the greater community. The success of MSVR has helped improve the security ecosystem as a whole, which benefits Microsoft, other software publishers, and the worldwide community of computer users.
Figure 6. The MSVR response process

MSVR advisories
As part of the CVD approach, the MSVR program issues advisories that provide details about software vulnerabilities that Microsoft had privately disclosed to third-party vendors. From July 2011 through June 2012, Microsoft issued 19 MSVR advisories, which are listed in the following figure.

20

MICROSOFT SECURITY RESPONSE CENTER

Figure 7. MSVR advisories issued from July 2011 to June 2012

Advisory Number MSVR11-007 MSVR11-008 MSVR11-009 MSVR11-010 MSVR11-011 MSVR11-012 MSVR11-013 MSVR11-014 MSVR11-015 MSVR11-016 MSVR12-001 MSVR12-002 MSVR12-003 MSVR12-004 MSVR12-005 MSVR12-006 MSVR12-007 MSVR12-008 MSVR12-009

Advisory Description Clickjacking Vulnerability in Facebook.com Could Allow Account Compromise Vulnerability in Google Picasa Could Allow Remote Code Execution Vulnerability in Apple Safari Could Allow Information Disclosure Vulnerability in WordPress Could Allow Cross-Domain Script Execution Vulnerability in FFmpeg Matroska Format Decoder Could Allow Remote Code Execution Vulnerability in FFmpeg Could Allow Remote Code Execution Vulnerability in Wireshark Could Allow Remote Code Execution Vulnerability in Wireshark Allows For Arbitrary Script Execution Vulnerability in Hex-Rays IDA Pro, IDAPython Plugin Could Allow Arbitrary Script Execution Vulnerability in NVIDIA Stereoscopic 3D Driver Could Allow Elevation of Privilege Vulnerabilities in XnViewer Could Allow Remote Code Execution Vulnerability in DotNetNuke Could Allow Arbitrary Script Execution Vulnerability in DotNetNuke Could Allow Arbitrary Script Execution JPEG 2000 Memory Overwrite Vulnerability in OpenJPEG Could Allow Arbitrary Code Execution Vulnerabilities in RealNetworks Helix Server Could Allow Arbitrary Script Execution Vulnerability in RealNetworks Helix Universal Media Server Could Allow Denial of Service Apple QuickTime MPEG Parsing Memory Corruption Vulnerability in Google Chrome Could Allow Local Code Execution Vulnerability in LongTail Video JW Player Could Allow Cross-Site Scripting

Date 7/19/2011 7/19/2011 8/16/2011 8/16/2011 9/20/2011 10/18/2011 10/18/2011 11/15/2011 12/21/2011 12/20/2011 1/17/2012 2/21/2012 2/21/2012 3/20/2012 4/17/2012 4/17/2012 5/17/2012 6/19/2012 6/19/2012

Microsoft does not reveal vulnerability details to the public before a vendoravailable for issues that are reported though the MSVR program unless there is significant evidence of active attacks in the wild. If attacks begin before the vendor has released their remediation, Microsoft will continue to coordinate release of consistent mitigation and workaround guidance with the vendor. This cooperative approach ensures that affected customers understand their risk and what to do to mitigate that risk, without revealing details that attackers could use to commit cybercrime.

MSRC PROGRESS REPORT 2012

21

This coordination takes place under Microsofts approach to coordinated vulnerability disclosure. CVD clarifies how Microsoft responds as a vendor that is affected by vulnerabilities in its products and services, as a finder of new vulnerabilities in third-party products and services, and as a coordinator of vulnerabilities that affect multiple vendors. MSVR advisories are posted at www.microsoft.com/technet/security/advisory/MSVRarchive.mspx. The format of an MSVR advisory is similar to that of a Microsoft security advisory: each MSVR advisory contains a top-level summary that states the reason for issuing the advisory, frequently asked questions, and a Suggested Actions section that describes any action that users may have to take to help protect themselves. MSVR advisories may be revised as required to reflect new information or guidance.

MSVR program statistics

Since July 2011, MSVR has identified and responsibly disclosed 96 different software vulnerabilities affecting a total of 39 vendors. 49 percent of third-party vulnerabilities found through MSVR since July 2011 were rated as Critical or Important.11 Of these third-party vulnerabilities, 37 percent have already been resolved. None of the vulnerabilities without updates have been observed in any attacks.

For more information, see the Microsoft Vulnerability Research page at www.microsoft.com/security/msrc/collaboration/research.aspx.

11

www.microsoft.com/technet/security/bulletin/rating.mspx

22

MICROSOFT SECURITY RESPONSE CENTER

Coordinated Vulnerability Disclosure

In July 2010, the MSRC announced the formulation of a set of practices to be used in disclosing information about software vulnerabilities in a way that benefits both vendors and consumers. Termed Coordinated Vulnerability Disclosure (CVD), these practices have since been adopted by Microsoft and other software vendors across the industry. Use of Coordinated Vulnerability Disclosure (CVD)12 increased to a new high during the period from July 2011 through June 2012. Of the vulnerabilities disclosed to Microsoft, 91 percent were reported using CVD, up from 84 percent during the previous 12-month period.
Figure 8. Vulnerability disclosures affecting Microsoft products, July 2006June 2012
100% 90%

Percent of All Vulnerability Disclosures

80%
70% 60%

50%
40% 30% 20% 10% 0%

Full Disclosure

CVD (incl. vulnerability broker)

Jul 07Jun 08

Jul 08Jun 09

Jul 09Jun 10

Jul 10Jun 11

Jul 11Jun 12

Under CVD, finders disclose newly discovered vulnerabilities in hardware, software, and services directly to the vendors of the affected product, to a national/regional CERT or other coordinator who will report to the vendor privately, or to a private service that will likewise report to the vendor privately.
See blogs.technet.com/b/ecostrat/archive/2010/07/22/coordinated-vulnerability-disclosure-bringing-balance-tothe-force.aspx for more information about Coordinated Vulnerability Disclosure.
12

MSRC PROGRESS REPORT 2012

23

The finder allows the vendor the opportunity to diagnose and offer fully tested updates, workarounds, or other corrective measures before any party discloses detailed vulnerability or exploit information to the public. The vendor continues to coordinate with the finder throughout the vulnerability investigation and provides the finder with updates on case progress. Upon release of an update, the vendor may recognize the finder in bulletins or advisories for finding and privately reporting the issue. If attacks are underway in the wild, and the vendor is still working on the update, both the finder and vendor work together as closely as possible to provide early public vulnerability disclosure to help protect customers. The aim is to provide timely and consistent guidance to help customers protect themselves. Information about vulnerabilities in third-party products comes to Microsoft Vulnerability Research (MSVR) in three primary ways: Internal Microsoft developers and test engineers. In the course of their day-to-day jobs, developers and test engineers find potential vulnerabilities in third-party software. These vulnerabilities are reported to the MSVR team, which then works with the affected vendor to fix the issue. Internal research projects. As time and resources permit, MSVR performs its own vulnerability analysis and research using internally developed toolsets and practices on third-party products that run on Microsoft operating systems but are not developed by Microsoft. External reports to the MSRC. External researchers report issues to the MSRC that they believe affect Microsoft products. On occasion, researchers determine that a reported issue affects third-party products instead of or in addition to Microsoft products. As with internally discovered vulnerabilities, these findings are reported to the MSVR team, which works with the affected vendors to address the issue.

After receiving information about a vulnerability in a third-party product, MSVR compiles a comprehensive set of information about the vulnerability to provide to the affected vendor. This information might include details about the test environment in which the vulnerability was observed, the severity and security impact of the vulnerability, crash dump information, PoC and/or exploit code, root cause analysis information, and other technical details about the vulnerability.

24

MICROSOFT SECURITY RESPONSE CENTER

When the analysis is complete, MSVR initiates communication with the vendors designated contact, using encrypted email if possible or other methods as appropriate. To minimize the risk of vulnerability information being misdirected while attempting to identify the vendor contact, MSVR will not send the vulnerability report in the initial email message. The initial message will be a simple introduction stating that MSVR is attempting to identify the correct contact to report a vulnerability in the vendors products or services. When the appropriate vendor contact is identified and confirms willingness to accept the vulnerability report, MSVR provides the vulnerability report. Microsoft understands that each software vendor is likely to have its own list of concerns about cooperating with other parties on vulnerability response, and that some software vendors may have misgivings about accepting MSVRs help. MSVR is pleased to work in a cooperative manner with any vendor to deal with a software vulnerability on the Windows platform. At the same time, MSVR urges every software vendor to address vulnerabilities in an open, responsive, and timely fashion, whether in cooperation with MSVR or not. Acting in this manner will help keep the Internet ecosystem safer for all users, and help vendors achieve a positive reputation in the security community as well.

MSRC PROGRESS REPORT 2012

25

Microsoft BlueHat Prize contest

On August 3, 2011, Microsoft announced a defensive computer security technology competition, the BlueHat Prize contest. This contest offers more than US $250,000 in cash and prizes and is designed to motivate the development of innovative solutions to address serious computer security threats and build collaboration among researchers throughout the computer security industry. The solution considered to be the most innovative runtime mitigation technology by the Microsoft BlueHat Prize board will win the grand prize of US $200,000. The competition closed at midnight Pacific Time on April 1, 2012, and the judging is now complete. Microsoft received 20 entries to the inaugural BlueHat Prize contest, a number that exceeded expectations. Submissions came from all over the world, and included many respected security researchers and academics. Microsoft announced the names of the three finalists on June 21, 2012, and will award the grand prize on July 26 at the Black Hat USA 2012 conference in Las Vegas, Nevada. All of the finalists chose to approach the problem of return-oriented programming (ROP), an exploit technique that pieces together segments of existing in-memory code to circumvent Data Execution Prevention (DEP) and similar mitigations. One Microsoft goal with the BlueHat Prize is to mitigate entire classes of exploits, and Microsoft was pleased to see entrants tackle this problem because ROP is a predominant technique used in modern exploits. The following, in alphabetical order by surname, are the three finalists: Jared DeMott. DeMott is a researcher who is well-known for teaching a course titled Application Security: For Hackers and Developers at security conferences. DeMott submitted a BlueHat Prize entry called /ROP that checks to ensure that target addresses of return instructions, which ROP exploits use, are safe. Ivan Fratric. Fratric earned a Ph.D. in computer science and is a researcher at the University of Zagreb in Croatia. Fratrics entry, named ROPGuard,

26

MICROSOFT SECURITY RESPONSE CENTER

defines a set of checks that can be used to detect when certain functions are being called in the context of malicious ROP code. Vasilis Pappas. Pappas is a Ph.D. student at Columbia University in New York City who actively researches information security. Pappas submission, called kBouncer, is a ROP mitigation technique that detects abnormal control transfers using common hardware features.

On July 25, 2012, Microsoft announced that a portion of one of the finalists entries would be integrated into the Enhanced Mitigation Experience Toolkit (EMET; see below). This integration means that customers can already benefit from protection offered by some of the technology revealed through the BlueHat Prize contest. Microsoft is very satisfied with the response of the research community and the innovative defensive solutions entered into the contest, and will be sharing further details of the entries after the winners are announced.

The Enhanced Mitigation Experience Toolkit (EMET)

We use only Windows on our desktops, and only with EMET.
Brad Spengler grsecurity.net

Recent versions of Windows, including Windows Vista and Windows 7, include security enhancements that make vulnerabilities significantly harder to exploit than in earlier versions of Windows. Similarly, recent releases of many popular software programs offer security features that make those releases much less vulnerable to successful exploitation. Microsoft recommends using the most recent versions of Windows and applications when practical to do so to take advantage of the built-in security functionality they offer. However, in some cases individuals and organizations cannot deploy recent software versions for a variety of reasons, or want to take advantage of modern security improvements in advance of a planned upgrade. For these customers, as well as for users of the latest software versions who want to take advantage of additional security improvements, Microsoft offers the Enhanced Mitigation Experience Toolkit (EMET) at no charge from the Microsoft Download Center (www.microsoft.com/download).

MSRC PROGRESS REPORT 2012

27

EMET is a free and reliable solution that can significantly improve your security level. Not using it at times like these would be a real waste.
Piotr Bania piotrbania.com

EMET provides system administrators with the ability to deploy security mitigation technologies such as Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), Structured Exception Handler Overwrite Protection (SEHOP), and others to selected installed applications. These technologies function as special protections and obstacles that an exploit author must defeat to exploit software vulnerabilities. These security mitigation technologies do not guarantee that vulnerabilities cannot be exploited. However, they make exploitation more difficult. EMET 3.0, the latest version, is compatible with supported versions of Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2. EMET 3.0 eases enterprise deployment via features such as Group Policy and SCCM support, event logging, configuration profile, and others. The technical preview version of EMET 3.5 incorporates new mitigation technologies from the Microsoft BlueHat Prize contest submissions, to mitigate return-oriented programming (ROP) attacks. (See page 26 for more information about the contest.) There are 4 new ROP mitigations that are aimed at detecting ROP attacks: stack pivot, caller checks, execution flow simulation, and special checks on critical functions. EMET prevents malware from exploiting vulnerabilities, period! There are many documented cases showing how EMET blocked new malware found in the wild. EMET is a must-have for your workstations. Didier Stevens Contraste Europe NV and author of HeapLocker To assess the effectiveness of EMET in addressing a number of commonly exploited vulnerabilities, Microsoft researchers collected a sample of 184 application exploits that had been sent to Microsoft from customers worldwide. All exploits targeted vulnerabilities in popular applications running on one or more versions of Windows. The researchers tested each exploit against Windows XP SP3 in an outof-the-box configuration, Windows XP SP3 with EMET deployed, and the releaseto-manufacturing (RTM) version of Windows 7 in an out-of-the-box configuration.

Figure 9 shows the results of these tests.

28

MICROSOFT SECURITY RESPONSE CENTER

Figure 9. The effectiveness of 184 exploits for popular applications on Windows XP, Windows XP with EMET 2.1 deployed, and Windows 7

200

181

Successful Exploits

160
120 80

40
0 Windows XP SP3

21

10 Windows 7

Windows XP SP3 + EMET

By a large margin, the highest success rates for the exploits tested involved Windows XP without EMET installed. All but three of the 184 exploits tested succeeded on Windows XP in this configuration. Deploying EMET drastically reduced the effectiveness of exploits on Windows XP. Only 21 of 184 exploits succeeded on Windows XP with EMET deployed. Ten of the 184 exploits tested succeeded on Windows 7 RTM. EMET breaks commodity malware and raises the cost of developing exploits for

more sophisticated attackers. System administrators should consider adding EMET to their environment as an additional exploit mitigation layer.
Brad Arkin Senior Director, Security, Adobe Products and Services

It should be recognized that the results of an exercise such as this one are influenced by the specific exploits being actively used in the wild at the time the exercise is conducted. Nevertheless, the data suggests that system administrators can significantly reduce their attack surface now by upgrading to the latest versions of their operating system and application software by deploying EMET, or both. For more information about EMET and to download the toolkit, visit support.microsoft.com/kb/2458544.

MSRC PROGRESS REPORT 2012

29

Conclusion
The global computing threat landscape is constantly evolving. The reality is that no one company, individual or technology can solve todays security challenges alone. It will take a collective effort. Microsoft has responded to this continuing shift by developing a series of programs and initiatives that involve responsible information sharing to help customers manage and overcome threats to computer security. The MAPP has partners reporting significant reductions in development time for delivering protection help to customers, which reduces the amount of time that computer systems are at risk. The Microsoft Exploitability Index is now firmly established as a valuable part of the Microsoft monthly security update release cycle, and it helps customers around the world prioritize their security update deployments and create more reliable and cost-effective system protection measures. Through the MSVR program, Microsoft has leveraged its considerable depth of expertise and tools with vendors to help raise the level of security in their products that run on the Windows platform. CVD is helping to protect customers around the world from attack while Microsoft and other organizations work to build, test, and release high-quality security updates.

As the criminal landscape also evolves, increased information sharing is key to advancing progress towards safer, more trusted computing experiences. This sharing involves continued work to develop better community-based defenses, increased help to resolve vulnerabilities in highly leveraged third-party code running on the Windows platform, and empowering customers with information that helps them make better risk assessments.

30

MICROSOFT SECURITY RESPONSE CENTER

One Microsoft Way Redmond, WA 98052-6399 microsoft.com/msrc

microsoft.com/msrc