Software Vulnerability Exploitation Trends

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


Foreword Using security science to create more secure products and services

The Microsoft Security Engineering Center carries out some of the software industrys 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


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 vulnerabilitys actual risk. To this point,

Microsoft security updates always include a description of a

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


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


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 9all 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%


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%


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




0

1

2

3

4

5

6

7

8

CV

Es

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

CV

Es


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


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


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 applications 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 2012some 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 DEPs 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 enabledat 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

CV

Es

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


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

CV

Es

Mitigated by DEP Bypassed DEP


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 applications 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++ objects 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.


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.


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

XPs 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


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.80.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 VistaSP2

Windows 7 RTM Windows 7 SP1 Windows 8 RTM Windows Server2003 SP2

Windows Server2008 R2 SP1


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

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


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


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.

ForewordIntroductionExploitation trendsImprovements in Windows 8RecommendationsReferencesAppendix: Data Sources and Glossary

Software Vulnerability Exploitation Trends

Documents

Transcript of Software Vulnerability Exploitation Trends