Software Vulnerability Exploitation Trends
Exploring the impact of software mitigations on patterns of vulnerability exploitation
1 Vulnerability Exploitation Trends
Software Vulnerability Exploitation Trends
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 © 2013 Microsoft Corporation. All rights reserved.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Authors
Swamy Shivaganga Nagaraju – Microsoft Security Response Center Cristian Craioveanu – Microsoft Security Response Center
Elia Florio – Microsoft Security Response Center
Matt Miller – Microsoft Security Engineering Center
Vulnerability Exploitation Trends 2
Table of contents
Foreword ... 3
Introduction ... 4
Exploitation trends ... 5
Improvements in Windows 8 ... 13
Recommendations ... 17
References ... 18
Appendix: Data Sources and Glossary ... 19
3 Vulnerability Exploitation Trends
Foreword
Using security science to create more secure products and services
The Microsoft Security Engineering Center carries out some of the software industry’s most advanced security science research.
Leveraging insights we glean from the Microsoft Security Response Center, the team examines new techniques that are used to attack Microsoft products and services – and third-party applications running on Microsoft platforms. They use this
understanding on how the attacks succeed to design countermeasures to defeat them.
The output of this research feeds back into the Microsoft Security Development Lifecycle, a mandatory part of the development process that every Microsoft product or service must implement. The result is that each new version of an operating system, browser or application is harder to attack than previous versions, making it more difficult and costly for criminals to develop malicious attacks. The more expensive it is to develop an attack, the less likely it is that the attack will be created and used.
This whitepaper examines the effectiveness of this approach. The paper analyzes software vulnerabilities addressed through Microsoft security updates that were exploited, and provides recommendations that can help to minimize risk of attack. Two findings are clear – first, the innovations introduced by security science have forced attackers to change the attack methods they use, often requiring the development of more expensive multi-stage attacks. Second, new attacks continue to be developed for older, less secure versions of products and services.
A special note to those still running Windows XP - the paper also examines the security features in Windows XP Service Pack 3 and compares them with the features in Windows 8, our most secure operating system to date. Only a quarter of Windows 8 protections are available in any form in Windows XP Service Pack 3. This means that the attack techniques that have been developed in the ensuing eight years can still be deployed against Windows XP, even though those techniques are mitigated by the updated security features in Windows 8. Running Windows XP on network-connected systems carries additional risk; the fact that Windows XP will no longer be supported at all after April 8, 2014 means that this risk will only increase over time.
The Microsoft Security Engineering Center continues their work examining new attack techniques as they are developed, which will ensure the security of Microsoft products and services keeps pace with ever-improving attack techniques.
Matt Thomlinson General Manager
Microsoft Trustworthy Computing Security
Vulnerability Exploitation Trends 4
Introduction
One of the security challenges that both individuals and organizations face is gauging the risks that are associated with vulnerabilities in the operating systems and applications that they use. Although such vulnerabilities always have some level of potential risk, this risk only becomes actualized when an attacker develops a functioning exploit. The existence of an exploit is what allows a malicious attacker to take advantage of a vulnerability and potentially compromise affected computers. From a risk management perspective, the likelihood of an exploit being developed can be an important factor in providing a more precise estimation of a vulnerability’s actual risk. To this point, Microsoft security updates always include a description of a vulnerability’s expected worst-case impact and, beginning in 2008, an Exploitability Index1 (XI) rating that measures the likelihood of a vulnerability actually being exploited.
A key factor that influences the likelihood that a vulnerability will be exploited is how difficult and costly it will be for an attacker to develop a reliable exploit. Over the past decade, Microsoft has introduced numerous defense-in-depth security features into Windows and other products that have been specifically designed to increase the cost and complexity of developing exploits. These security features, which are detailed in the white paper
“Mitigating Software Vulnerabilities,”2 are particularly noteworthy because they offer protection even when the details of a
vulnerability are not yet known to a vendor or a vulnerability has not yet been addressed through a security update.
1 http://technet.microsoft.com/en-us/security/cc998259.aspx
This white paper explores the impact of improvements that Microsoft has made over time to address software vulnerabilities.
This analysis is based on a survey of Microsoft vulnerabilities that have been addressed through security updates over the past seven years (2006 – 2012) and are known to have been exploited.
The survey focuses on assessing trends in the types of
vulnerabilities that have been exploited, the product versions that have been targeted, and the exploitation techniques that have been used by attackers. It also highlights security improvements in Windows 8 that help mitigate techniques that are currently being used by attackers. The findings of this survey were used to create a set of recommendations on how to effectively minimize risk associated with software vulnerabilities.
2 www.microsoft.com/en-
us/download/details.aspx?id=26788
A KEY FACTOR THAT
INFLUENCES THE LIKELIHOOD THAT A VULNERABILITY WILL BE EXPLOITED IS HOW
DIFFICULT AND COSTLY IT
WILL BE FOR AN ATTACKER
TO DEVELOP A RELIABLE
EXPLOIT.
5 Vulnerability Exploitation Trends
Exploitation trends
This section explores historical exploitation trends for Microsoft vulnerabilities that have been
addressed through security updates within the past seven years (2006 – 2012). Evidence about which
vulnerabilities have been exploited was gathered from public and private
reports as well as Microsoft
antimalware telemetry feeds. Although this data is believed to be thorough and complete, it is possible that
vulnerabilities may have been exploited without being detected.
However, the scale of any such
exploitation is expected to have been small because no discernible evidence exists.
Unless otherwise stated, this analysis focuses on remote code execution (RCE) vulnerabilities because these vulnerabilities are often the most severe.
KEY FINDINGS
The key findings that were made through this analysis of historical exploitation trends are:
The number of RCE vulnerabilities that are known to be exploited per year appears to be decreasing.
Vulnerabilities are most often exploited only after a security update is available, although recent years have shown an upward trend in the percentage of vulnerabilities that are exploited before a security update is available.
Windows 7 and Internet Explorer 9 are being increasingly targeted by exploits.
Stack corruption vulnerabilities were historically the most commonly exploited vulnerability class, but now they are rarely exploited.
Use after free vulnerabilities are currently the most commonly exploited vulnerability class.
Exploits increasingly rely on techniques that can be used to bypass the Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR).
Vulnerability Exploitation Trends 6
Scale
To help set the context for assessing exploitation trends, it is helpful to start by considering the scale at which vulnerabilities are actually known to have been exploited.
The following figure represents the number of common vulnerabilities and exposures (CVEs) that were classified as RCE CVEs over the last seven years. This data shows that
approximately 29% of the CVEs addressed during this period had evidence of being exploited, ranging from 18% in 2008 to 41% in 2011. The data also suggests that 2011 was a turning point in the upward trend of vulnerabilities being exploited and that 2012 showed a significant decline in the number of known exploits. As subsequent sections will show, this decline coincides with the increasing adoption of Windows 7, Office 2010, and Internet Explorer 9—all of which benefit from stronger defenses.
Figure 1. CVEs that were exploited and resolved through security updates
The general timeframe within which vulnerabilities are known to be exploited is also an important factor when managing risk. The following figure shows that, with the exception of 2006 and 2007, most RCE issues only had evidence of being exploited after a security update was available. This information emphasizes the point that staying current with security updates is an effective
way to minimize risk. However, recent years have shown an upward trend in the percentage of vulnerabilities that are exploited before a security update is available. This increase means that it is also important to have mitigations in place that are able to complicate exploitation without requiring prior knowledge of a specific vulnerability.
2006 2007 2008 2009 2010 2011 2012
Known exploit 28 21 21 33 66 49 27
No known exploit 66 78 94 94 113 70 75
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
7 Vulnerability Exploitation Trends
Figure 2. Percentages of CVEs that were exploited before vs. after security updates were available
The Windows Vista lull
In 2007 and 2008, there was an apparent lull in the number of CVEs that were known to have been exploited. This lull occurred despite the fact that the total number of RCE vulnerabilities that were addressed through security updates actually increased compared to 2006. One explanation for this lull is that the release of Windows Vista may have forced a period of attacker
innovation, because Windows Vista included many security improvements that were designed to break exploitation techniques that attackers relied on at the time. Most notably, Windows Vista was the first version of Windows to support address space layout randomization (ASLR) as well as a significantly hardened heap implementation.
Targets
The product versions that are affected by a vulnerability are what define the set of at-risk targets that an attacker could attempt to exploit. In practice, exploits often target only a small subset of the affected product versions, for multiple reasons; one key factor is that the runtime environment of an application tends to be different between product versions. These differences can make it difficult to build an exploit that functions and is reliable against the complete set of potential targets. Accordingly, exploit writers typically target affected versions that are seen as high yield, such as those versions that are used by the largest portions of the population.
Of the exploit data that was analyzed, only 34% of the CVEs had at least one exploit for which the intended targets were known.
The following figure shows the versions of Windows that were targeted for this subset. Notably, a downward trend is evident over the last seven years in the number of exploits that targeted Windows 2000, which no longer appeared as a target in 2012.
The number of exploits that targeted Windows XP and Windows Vista has also begun trending downward in the past three years, which corresponds to the increase in exploits that target Windows 7.
2006 2007 2008 2009 2010 2011 2012
Exploited before update 16 12 5 11 14 16 12
Exploited after update 12 9 16 22 52 33 15
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Vulnerability Exploitation Trends 8 Figure 4. The number of CVEs for which exploits were written that targeted specific Internet Explorer versions
2006 2007 2008 2009 2010 2011 2012
Internet Explorer 6 7 3 3 6 6 4 3
Internet Explorer 7 2 1 1 6 5 5 4
Internet Explorer 8 0 0 0 0 5 7 5
Internet Explorer 9 0 0 0 0 0 0 3
0 1 2 3 4 5 6 7 8
CVEs
Figure 3. The number of CVEs for which exploits were written that targeted specific Windows versions
For exploits that targeted vulnerabilities reachable through Internet Explorer, the following figure shows how Internet Explorer 6, 7, and 8 appear to be trending downward as targets whereas Internet Explorer 9 started being explicitly targeted in 2012. As a point of reference, the release dates for each version of Internet Explorer were as follows:
Internet Explorer 6. August, 2001
Internet Explorer 7. October, 2006
Internet Explorer 8. March, 2009
Internet Explorer 9. March, 2011
2006 2007 2008 2009 2010 2011 2012
Windows 2000 14 6 5 5 1 1 0
Windows XP 14 2 9 11 13 8 6
Windows Vista 1 1 1 5 5 4 3
Windows 7 0 0 0 0 5 9 7
-1 1 3 5 7 9 11 13 15
CVEs
9 Vulnerability Exploitation Trends
Vulnerabilities
The root cause of a vulnerability plays a key role in defining the set of exploitation techniques that an attacker can use when developing an exploit. As a result, the level of difficulty in developing an exploit is heavily dependent on the type of vulnerability that is being exploited. In terms of risk management, the root cause of a vulnerability can be an important factor in influencing the likelihood that an exploit will be developed. As the following two figures illustrate, there have been some noteworthy shifts in the classes of vulnerabilities that are known to have been exploited.
The first clear shift can be seen through the decline in the percentage of exploits for stack corruption vulnerabilities, such as stack-based buffer overruns. (See the “Glossary” section at the end of this paper for a definition of stack corruption
vulnerabilities.) This vulnerability class has historically been the most likely to be exploited, but since 2009 it has been steadily
declining. Two factors that could be contributing to this decline are the increasing prevalence of exploit mitigations for stack corruption issues (such as /GS and SafeSEH) and the increasing effectiveness of static analysis tools designed to detect such vulnerabilities.
A second shift can be seen in the increasing number of use after free vulnerabilities that have been exploited. This vulnerability class includes issues that arise because of incorrect management of object lifetimes (see the “Glossary” section at the end of this paper for a definition of use after free vulnerabilities.) One reason for this increase is that client-side vulnerabilities have become a prime focus for attackers and object lifetime issues are a common vulnerability class encountered in applications such as web browsers.
Figure 5. The distribution of CVE vulnerability classes for CVEs that are known to have been exploited 0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
2006 2007 2008 2009 2010 2011 2012
Stack Corruption Heap Corruption Use After Free Type Confusion Command Execution Unsafe DLL Load Uninitialized Use Invalid Free
Memory Read Other XSS Cryptography
Unsafe Control Transfer
Vulnerability Exploitation Trends 10 Figure 6. The distribution of CVE vulnerability classes for which exploits were written
that targeted specific versions of Windows over the past seven years
Techniques
Attackers have developed a variety of exploitation techniques over time that can potentially enable them to exploit
vulnerabilities under differing circumstances. These techniques encompass the fundamental methods of leveraging a particular class of vulnerability as a means of running malicious code. In recent years, additional techniques have been identified for bypassing exploit mitigations such as DEP and ASLR under certain conditions. From a risk management perspective, the ability for an attacker to employ certain exploitation techniques
can be another factor that influences the likelihood that an exploit will be developed for a vulnerability.
Of the exploit data that was analyzed, approximately 28% of the CVEs had an exploit for which the exploitation techniques were readily identifiable. The different exploitation techniques that were used by these exploits is shown in the following figure.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Windows 2000 Windows XP Windows Vista Windows 7
Stack Corruption Use After Free Heap Corruption Command Execution Type Confusion XSS
Unsafe DLL Load Uninitialized Use Invalid Free Other Unsafe Control Transfer
11 Vulnerability Exploitation Trends
Figure 7. The number of CVEs that were exploited using specific exploitation techniques
As this data suggests, the increasing prevalence of DEP and ASLR has forced attackers to identify techniques that can be used to exploit vulnerabilities even when these features are enabled.
These techniques have led to an increasing number of exploits that attempt to bypass ASLR by relying on images that have not opted into ASLR or by leveraging a vulnerability to disclose information about the layout of an application’s address space.
Similarly, the use of return-oriented programming (ROP) has become common in exploits that seek to bypass DEP. The increasing use of ROP was a focal problem for the winning solutions that were submitted to the Microsoft BlueHat Prize competition in 2012—some of which were integrated into the Microsoft Enhanced Mitigation Experience Toolkit (EMET) 3.5 technical preview.
The data in the preceding figure also shows that attackers leveraged .NET user controls between 2008 and 2010 as a method of bypassing both DEP and ASLR in Internet Explorer, but this technique was mitigated with the release of Internet Explorer 8 in 2009 and therefore is no longer useful to attackers who try to exploit Internet Explorer 8 and more recent versions. The data on which classes of vulnerabilities have been exploited showed a clear downward trend in the number of stack corruption
vulnerabilities that are being exploited. This trend is further reflected by the decrease in the number of exploits that rely on stack-based exploitation techniques such as return address and SEH overwrites.
Would enabling certain mitigations have broken exploits seen in the past?
Another way to view the techniques used by attackers is to identify exploits that would no longer function correctly if a mitigation were enabled. The chart in the following figure shows the number of CVEs that had exploits that would have been mitigated if DEP were enabled compared to the number of CVEs that had exploits that bypassed DEP. With the exception of the lull in 2007 and 2008, there appears to be a clear downward trend in DEP’s ability to retroactively break exploits. This trend is not because DEP is no longer effective; rather, it is an indication that attackers have been forced to adapt to environments in which DEP is already enabled—at increased cost and complexity. The evidence is the increasing number of CVEs that had exploits that bypassed DEP.
0 1 2 3 4 5 6 7 8
2006 2007 2008 2009 2010 2011 2012
CVEs
Bypass ASLR (info disclosure) Bypass ASLR (non-ASLR image) Bypass DEP (.NET control) Bypass DEP (ROP)
Heap Spray Stack Return Address Overwrite Stack SEH Overwrite
Vulnerability Exploitation Trends 12 Figure 8. The number of CVEs for which exploits were written that could have been mitigated by
enabling DEP as compared to the number of CVEs that had exploits that bypassed DEP 0
2 4 6 8 10 12 14
2006 2007 2008 2009 2010 2011 2012
CVEs
Mitigated by DEP Bypassed DEP
13 Vulnerability Exploitation Trends
Improvements in Windows 8
Windows 8 contains numerous security improvements that are specifically designed to increase the cost and complexity of exploiting vulnerabilities.
This section highlights some of the security improvements in Windows 8 by showing the impact they are
designed to have on current trends in vulnerability exploitation.
Enhanced /GS
Stack corruption vulnerabilities are rarely exploited in Microsoft products today, thanks in part to the /GS stack buffer overrun protection and SafeSEH features of the Microsoft Visual C++
compiler. Despite this positive trend, there have still been cases during the past seven years in which stack corruption
vulnerabilities were successfully exploited. In Visual C++ 2010, the heuristics that /GS uses when deciding whether to enable protection for a function were extended to cover a broader set of cases. For example, the new heuristics now protect functions that have a plain old data structure (POD) of a certain size or that have a fixed-size local array of a non-pointer type. These enhanced heuristics provide protection for past vulnerabilities that were not previously protected by /GS. Because Windows 8 has been built with these enhancements to /GS, it will be even more difficult for attackers to develop an exploit for stack corruption vulnerabilities that may exist in Windows 8.
Heap hardening
Heap corruption vulnerabilities are one of the most commonly exploited vulnerability classes. In most cases, attackers attempt to exploit these vulnerabilities by corrupting the state of application data that is stored on an application’s heap. For example, an attacker might use a heap buffer overrun to corrupt the virtual table of a C++ object that is later called through, which would allow them to take control of program execution.
In Windows 8, new security features have been added to the heap that were specifically designed to make it more difficult to corrupt application data on the heap. Exploits that are written for
heap corruption vulnerabilities often require precise control of where objects are allocated on the heap with respect to one another. By randomizing the order in which objects are allocated, Windows 8 makes it more difficult for an attacker to reliably position objects within the heap. In addition, Windows 8 also inserts no-access guard pages between certain regions within the heap. These pages help to ensure that an application will
terminate if an exploit causes a program to read or write to them.
Both of these features are enabled by default in Windows 8, so all applications are able to benefit from them.
VTGuard (Virtual Table Guard)
Use after free vulnerabilities are currently the most exploited vulnerability class in Internet Explorer. To exploit these
vulnerabilities, attackers generally rely on creating a fake instance of a C++ object that has a fake virtual function table whose content is controlled by the attacker. In this way, an attacker is able to force an application to execute attacker-specified code when a virtual method call is made.
To help mitigate this, Internet Explorer 10 takes advantage of a compiler security feature known as VTGuard. This feature acts as a probabilistic mitigation for vulnerabilities that can be used to corrupt a C++ object’s virtual table pointer. VTGuard works by adding a secret value as an element of the virtual table for a protected C++ class. The compiler also inserts logic prior to each virtual method call for the protected class. At runtime, this logic verifies that the virtual table for the current C++ object has the expected secret value. If the secret cannot be confirmed, the application is safely terminated.
Vulnerability Exploitation Trends 14
Force ASLR
The most common exploitation technique that is currently used to bypass ASLR involves taking advantage of a dynamic-link library (DLL) that has not actually opted into ASLR. By coercing an application into loading such a DLL, an attacker can cause known executable code to be placed at a known fixed location in the address space of an application. This placement can enable an attacker to make use of other techniques to bypass DEP.
To prevent attackers from using this technique, Windows 8 introduced support for a feature known as Force ASLR. When Force ASLR is enabled for an application, all relocatable DLLs will be mapped at a randomly selected base address regardless of whether or not they have opted into ASLR. Because Internet Explorer and Office were often targeted by exploits that relied on non-ASLR DLLs, Internet Explorer 10 and Office 2013 have both enabled Force ASLR as well.
For versions of Windows prior to Windows 8, the Microsoft Enhanced Mitigation Experience Toolkit (EMET) can be used to enable Force ASLR.
High Entropy ASLR
Heap spraying has consistently been one of the most popular techniques used by exploits over the past seven years. Exploit writers generally use heap spraying to place attacker-controlled code or data at a desired location in memory. This placement is typically accomplished by coercing an application into allocating large quantities of data and thereby filling a large portion of the address space.
In Windows 8, 64-bit applications that enable support for High Entropy ASLR are generically protected against traditional heap- spraying techniques because High Entropy ASLR uses 24 bits of entropy when selecting the base address for heap regions.
Approximately 1 terabyte of variance is available for allocation of heap regions, which means that an attacker would need to allocate more memory than a commodity PC typically has to reliably control the content of memory at a known address. Like the Force ASLR feature, the 64-bit versions of Internet Explorer 10 and Office 2013 have both enabled High Entropy ASLR.
15 Vulnerability Exploitation Trends
Comparing Windows XP to Windows 8
The threat landscape has changed dramatically since Windows XP was first released 12 years ago. In the years that followed Windows XP’s initial release, multiple internet worms were created that exploited vulnerabilities in remote services provided by Windows (Code Red, Blaster, Sasser). Microsoft responded to these attacks by releasing Windows XP Service Pack 2 in August 2004 which enabled the Windows firewall by default and also introduced support for Data Execution Prevention (DEP). These platform security features played a key role in helping to address the major threats at that time. Windows XP Service Pack 3 was released in April 2008. This is the final Service Pack for Windows XP, and will not be supported after April 8th 2014. After that date there will be no more security updates released for any version of Windows XP.
As of 2013, the predominate threats that individuals and organizations face are now much different. Rather than actively targeting remote services, attackers primarily focus on exploiting vulnerabilities in client applications such as web browsers and document readers. In addition, attackers have refined their tools and techniques over the past decade to make them more effective at exploiting vulnerabilities. As a result, the security features that are built into Windows XP are no longer sufficient to defend against modern threats.
To illustrate this point, the table below compares the mitigation features supported by Internet Explorer 8 on Windows XP Service Pack 3 with the features supported by Internet Explorer 10 on Windows 8. As this table shows, Internet Explorer 10 on Windows 8 benefits from an extensive number of platform security improvements that simply are not available to Internet Explorer 8 on Windows XP.
Windows XP SP3
Internet Explorer 8 Windows 8 Internet Explorer 10
SEHOP No Yes
Protected Mode No Yes
Enhanced Protected Mode (EPM) No Yes
Virtual Table Guard No Yes
ASLR Limited Extensive
Stack randomization No Yes
Heap randomization No Yes
Image randomization No Yes
Force image randomization No Yes
Bottom-up randomization No Yes
Top-down randomization No Yes
High entropy randomization No Yes
PEB/TEB randomization Yes Yes
Heap hardening Limited Extensive
Header encoding No Yes
Terminate on corruption No Yes
Guard pages No Yes
Allocation randomization No Yes
Safe unlinking Yes Yes
Header checksums Yes Yes
/GS Yes Yes
Enhanced /GS No Yes
SafeSEH Yes Yes
Vulnerability Exploitation Trends 16
Malware infection rates on different operating system versions
The security features that are available with different versions of the Windows operating system and the differences in the way people and organizations use each version affect the malicious software infection rates for the different versions and service packs. The Microsoft Security Intelligence Report (SIR) shows the normalized malicious software infection rates for several different versions of Windows. This infection rate data is gathered from the Malicious Software Removal Tool (MSRT) which executes on more than 600 million Windows systems around the world each month. The data gathered is normalized to allow comparison between the various different operating system versions and service packs, and displayed as a metric called CCM (Computers Cleaned per Mille) which represents the number of computers cleaned for every 1,000 executions of the MSRT. The data in the latest version of the SIR shows a dramatic difference in malicious software infection rates between Windows XP Service Pack 3 and later versions of Windows, especially Windows 8.
Figure 9. Infection rate (CCM) by operating system and service pack in the fourth quarter of 2012 11.3
Too little data
3.5
4.6 4.8
3.7 4.5
3.3
0.8 0.2
4
Too little data
Too little data
2.5
0.0 2.0 4.0 6.0 8.0 10.0 12.0
32-bit 64-bit 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit Windows XP SP3 Windows Vista
SP2
Windows 7 RTM Windows 7 SP1 Windows 8 RTM Windows Server 2003 SP2
Windows Server 2008 R2 SP1
17 Vulnerability Exploitation Trends
Recommendations
The likelihood that a vulnerability will be successfully exploited depends on many factors, including the type of vulnerability being exploited, the product versions being targeted, an attacker’s ability to make use of the necessary exploitation techniques, and the amount of time required to build a reliable exploit. The following
recommendations show how these factors can be influenced to help reduce the likelihood of exploitation and thereby minimize risk.
Stay current on security updates
Most vulnerabilities only showed signs of being exploited after a security update had been made available. Installing security updates as soon as they are available can help minimize risk.
Use the newest application versions
Windows 8, Internet Explorer 10, and Office 2013 all take advantage of improved security features that more effectively mitigate techniques that are currently being used to exploit vulnerabilities.
Use the Enhanced Mitigation Experience Toolkit (EMET)
EMET can be used to protect applications that run on all supported versions of Windows. The features included in EMET are specifically designed to break exploitation techniques that are currently used by attackers.
Vulnerability Exploitation Trends 18
References
Microsoft Exploitability Index
http://technet.microsoft.com/en-us/security/cc998259.aspx Mitigating Software Vulnerabilities
http://www.microsoft.com/en-us/download/details.aspx?id=26788 The Enhanced Mitigation Experience Toolkit
http://www.microsoft.com/emet
19 Vulnerability Exploitation Trends
Appendix: Data Sources and Glossary
Data sources
This survey used the following data sources:
Publicly available, commercially available, and privately reported exploits, including proofs of concept, exploit descriptions, and complete exploit modules.
Antimalware telemetry for exploits observed in the wild.
The data sources surveyed did not universally provide
information about targeted product versions or techniques used by exploits. As such, this portion of the analysis is limited to exploits in which this information was readily available.
The antimalware telemetry data that was used in this survey is signature-based and therefore does not constitute proof that a given vulnerability was actually being exploited. Despite this fact, the inclusion of this data provides a more accurate upper bound on which vulnerabilities were actually exploited.
Glossary
ASLR. An acronym for address space layout randomization, a platform security feature that randomizes the location of code and data in the address space of a process. The first version of Microsoft Windows to support ASLR was Windows Vista in 2007.
DEP. An acronym for Data Execution Prevention, a platform security feature that prevents data from being executed as code.
Exploit. Malicious code that attempts to take advantage of a vulnerability in computer applications or operating systems.
Exploitability Index. An index of information created by Microsoft that provides information about the potential exploitability of software vulnerabilities that have been rated as Important or Critical. Microsoft publishes this information for customers who wish to use it for risk analysis purposes.
RCE exploit. RCE is an acronym for remote code execution. An RCE exploit is one that enables an attacker to execute arbitrary code of their choosing remotely, without having physical access to the targeted computer.
Stack corruption vulnerabilities. Exploitable vulnerabilities that allow the general purpose data structure known as the “stack” to be corrupted. The stack is that portion of computer memory that is used for storing local variables, function parameters, and other saved register values.
Uninitialized memory use vulnerabilities. Exploitable
vulnerabilities that occur when a program accesses memory that has not been properly initialized. If exploited, these vulnerabilities could allow remote code execution (RCE).
Use after free vulnerabilities. Exploitable vulnerabilities that occur when an object is accessed after it has been freed.
Attackers might use such vulnerabilities to cause programs to use their own values, crash programs, or achieve remote code execution (RCE).
Vulnerability. A weakness in a product that could allow an attacker to compromise the integrity, availability, or confidentiality of that product.
