A History of Microsoft Exploit Mitigations

Benjamin Mossé

Overview Definition and scope Introduction to binary exploitation Exploit mitigation mechanisms Vulnerability context Miscellaneous Conclusion

Definition & Scope Exploit mitigation: “a feature of the operating

system which enhance the difficulty of exploiting a vulnerability”.

Presentation of the current exploit mitigations and discussion of the impact those technologies have on several fields of IT security.

Windows-based systems only. High level oriented presentation.

Intended audience Not experts in exploitation You would like to get some insights on how

exploit mitigation technologies work and what are their limitations.

You work for an organization who still runs Internet Explorer 6; you’re thinking of migrating all your workstations to IE8 and would like to get a high level or semi-technical explanation of why from a security standpoint that’s a good idea.

Try to answer the “Is my Windows secure?” question

Part i – Introduction to binary exploitation

Introduction to exploitation Understand how memory works Understand the fundamentals of exploitation Understand some of the basics of how our

applications work at the system-level (assembly)

Normal control flow of an application

In Memory

Memory is divided in regions.

Memory regions Each region has:

A start address Access control properties: read, write, execute

Within each applications we also find the following regions: The stack – to story static data The heap – to store dynamic data

Concept of exploiting a memory corruption vulnerability

shellcodeFunction 2 has a faultwhich allows attackers to modify the control flow of the application.

Function 2 will jump into the attackersShellcode instead of Function 3.

A few word about the shellcode The shellcode is a small piece of code used as

a payload in the exploitation of a software vulnerability

It is also stored in a memory region (often the stack or the heap) Hence if the region the shellcode is in is not

executable, the shellcode won’t work

Exploiting a vulnerability: 3 requirements

Part ii – Exploit mitigation technologies

Exploit mitigation mechanisms Introduction An overview at the history Analyzing specific mechanisms

/GS cookie SafeSEH SEHOP DEP ASLR

Introduction Applications compiled with Visual Studio

(Microsoft’s compiler) A certain number of flags need to be on:

/DYNAMICBASE /GS /NXCOMPAT /SAFESEH

Exploit mitigations Two (2) main categories of mitigations The ones that try to stop common know

exploitation patterns: DEP ASLR SafeSEH

The ones that try to detect a memory corruption fault: /GS cookie Heap protections SEHOP

/GS cookie

Buffer overflow

Before using the return address the application detects if the stack cookie (random generated value) has been modified. If it has, the application will terminate itself.

SEH Overwrite attack

One popular technique to bypass /GS was to overwrite the ‘SEH pointer’ located after the return address in memory. Then attackers would crash the application, resulting in that pointer being used by the exception handler. Hence then taking control of theapplication flow.

Buffer overflow

SafeSEH Exploit mitigation against the SEH overwrite attack. Verifies the SEH pointer before using it.

The memory address cannot point to a memory region protected by SafeSEH.

This method relies on the principle that every memory regions have been set with that protection. Hence if only one region is not protected, the mitigation becomes ineffective.

Important note: for the SEH overwrite attack to work, attackers must generate a crash in the application. This is often done by trying to write data past the stack region.

Structured Exception Handler Overwrite Protection (SEHOP)

Buffer overflow

1. Anti-exploitation mechanism introduced in windows Vista to prevent SEH overwrite attacks similar to the stack cookie

2. Set by default in Win 73. Checks that the random value located after the SEH pointer has not

been modified before using the pointer.

Data Execution Prevention (DEP)

i. Attackers have to find a location where to store their shellcode.ii. The known memory regions they use have been marked Non-Executableiii. Hence, their shellcode cannot be executed by the application anymore

Address Space Layout Randomization (ASLR) Memory regions always start at a different

address Makes it harder to determine memory

locations: Where is my shellcode?

Hence the shellcode itself cannot use fixed memory addresses.

Timeline

Image taken from the paper ‘Bypassing Browser Memory Protections’

Part iii – Vulnerability Context

The properties of a vulnerability The context in which a particular vulnerability

is found. That specific context may allow attackers to

develop a working exploit which bypasses all exploit mitigations implemented on the operating system.

“The exploit works because the 7 moons are aligned”

Properties of a vulnerability

The vulnerability may be in a context where the exploit mitigations are either ineffective to prevent its exploitation or circumvented in certain scenario.

Example: the ANI vulnerability First public exploitable

vulnerability on Windows Vista

Discovered by Alex Sotirov

Vulnerable function not protected by /GS

ASLR’s entropy too small, hence could be brute forced

DEP not yet implemented in Internet Explorer 7 at the time

Implications? There will always be exploitable vulnerabilities. Exploit mitigation mechanisms have an impact

on how we search for vulnerabilities.

Old scoping method: find all inputs of an application and test them while hoping one will not be protected enough.

New scoping method: find all sections of an application which are not correctly protected by anti-exploitation mechanisms and try to find a bug in them.

No public technologies to perform that type of scoping yet

Implications? Before Windows Vista, we could generate reliable

exploits using automated tools because of the lack of certain anti-exploitation technologies by default.

Since Windows Vista, exploitation becomes vulnerability specific, hence automatically generating exploits is a lot harder.

Static source code analysis tools also need to be able to take into account anti-exploitation mechanisms.

Exploit mitigations also impact on bug fixing prioritization. Hence the importance of knowing which sections of an

application is less likely to be effectively protected or not.

Contexts or attack patterns that allow to bypass anti-exploitation mechanisms Bypassing DEP:

Inject shellcode is Executable memory regions Return into libc / returned oriented programming Disable DEP manually on the system

NtProtectVirtualMemory()

Bypassing ASLR Brute force Memory spraying Memory leaks

Requires a bug which leaks information about the memory layout (i.e. a memory address)

Contexts or attack patterns that allow to bypass anti-exploitation mechanisms Bypassing SEHOP

Re-create a valid fake SEH chain (not applicable with the latest version of SEHOP in Windows 7) Need to defeat ASLR first to perform that technique

Bypassing GS Find instances of variables in the code that are not

protected by GS Use the SEH pointer overwrite technique

Need to bypass SafeSEH (and SEHOP)

The future of exploitation? Applications known to offer contexts to bypass

memory protections Browsers and their plugins (i.e. Flash, Acrobat)

Applications known not to be protected by all memory protections Kernel mode applications

Operating systems not as protected as Windows Macintosh? Mobiles?

Other kind of devices not protected with mitigations: Routers, switches.

Part iv – Miscellaneous

Lifetime of an attack pattern: /GS & SEH Overwrite /GS: Introduced in 2003

Bypass: overwrite the SEH handler. Safe SEH: Introduced in Windows XP SP2

(August 24th, 2004) Bypass: overwrite the SEH handler with a pointer to

a module not protected by Safe SEH SEHOP: Introduced in Windows Vista SP1 and

Win Server 2008 but disabled by default Safe SEH bypass technique still effective by default

SEHOP: Enhanced and enabled by default in Windows 7 (October 22e, 2009) No bypass seen so far. The solution seems effective.

Lifetime of an attack pattern: /GS & SEH Overwrite Techniques to bypass the mitigations were

introduced in 2003. An effective solution to prevent those attack

patterns was deployed and enabled by default in 2009. The SEHOP deployed in Win 7 has not been

bypassed yet. For about 6 years attackers were able to use

that attack pattern to successfully exploit vulnerabilities. And they still are millions of systems running older

version of Windows. Those systems are still not protected.

Lifetime of an attack pattern: return oriented programming (ROP) 1997: Solar Designer published the first

ret2libc exploit Since numerous papers and tools have been

published on the subject. Used to bypass DEP. We are un 2010 and no bulletproof exploit

mitigations have been implemented against this known attack pattern. Attackers need to defeat ASLR to apply that

technique. Lots of research has been done on ROP lately.

As a result, we can probably assume we will see many more exploit using that technique in the near future. Automated tools to generate part of the exploit

etc.

Lifetime of an attack pattern: conclusion Between the date researchers discover a new

attack pattern which bypasses one or several exploit mitigations and the date a protection is implemented, attackers have several years to successfully compromise systems using the method.

Hence, maybe, the need for an independent security company to develop exploit mitigation tools is still relevant today?

Enhanced Mitigation Evaluation Toolkit (EMET) Command line utility to deploy mitigations on

applications that have been written before the mitigations were available or when the source code is not available.

XP, Vista, Windows 7, Windows Server 2003+ Supported mitigations:

DEP SEHOP Null page allocation Heap spray allocation

Shellcode isn’t necessary a shell

Part vi – Conclusion

Conclusion Exploitation on the Windows platform is

considerably harder but memory corruption vulnerabilities are not yet dead.

How do we efficiently identify portions of code that provide an exploitable context?

Is there new yet unknown vulnerability classes which are not protected by anti-exploitation technologies?

The community is focused on researching how to bypass memory protections; maybe it would be good to be reactive and research on how to improve them.

Conclusion It is going to be interesting to see Microsoft’s

future mitigations against the latest exploitation techniques: Researchers will probably come up with new

exploitation methods What will be the limitations of those new

mitigations? Will we be able to turn them to our advantage and come up with new exploitation techniques? (i.e. see the latest research on the IE8 XSS filter)

Will exploitation mitigations ever reach a level of maturity where we can state that memory corruption vulnerabilities are over?

Question?

References The ANI bug video:

http://www.youtube.com/watch?v=mwrhRP2PswA - Alex Sotirov

EMET: http://blogs.technet.com/srd/archive/2009/10/27/announcing-the-release-of-the-enhanced-mitigation-evaluation-toolkit.aspx

Paper ‘Bypassing Browser Memory Protections’: http://taossa.com/archive/bh08sotirovdowd.pdf - Mark Dowd, Alex Sotirov

Bypassing SEHOP: http://www.sysdream.com/articles/sehop_en.pdf

There’s a party at ring0 and you’re invited: http://www.cr0.org/paper/to-jt-party-at-ring0.pdf

Part v – Web related stuff

The following content was presented at OWASP. Excludedfrom Auscert.

Reflected Cross-site scripting (XSS) IIS6 XSS Filter + IE8 XSS Filter = END of

reflected cross-site scripting vulnerabilities Context of exploitation:

DOM Based XSS Through know techniques. Through browser bugs.

Reflected but injecting directly into javascript code Ineffective against stored XSS

PHP Magic quotes Attack mitigation against SQL injections that

automatically escapes all inputted data Contexts allowing bypass:

Injecting into an integer field SELECT * FROM blah WHERE id = $id

Attacker can successfully exploit the vulnerability in this context by converting any needed string to hexadecimal http://blah/page.php?id=-1 UNION SELECT

LOAD_FILE(0x1234456) INTO OUTFILE(0x0432432435435)

Possible mitigation: develop a patch for MySQL to prevent the use of hexadecimal strings and by default forbid many of the casting methods

Stopping automated tools Anti-spidering technology

Easy to create and implement Would stop many automated scanners out there

Randomizing 404 responses Do not return HTTP 404 Randomize the size and number of lines the page

returns Would stop many file and directory scanning tools

Both methods aren’t bullet proof but they do exactly what exploit mitigations do: stop known attack patterns.

Normalizing traffic Http Parameter Pollution (HPP):

Search.jsp?q=Britney spears&q=Hackers kick ass Implement scrubbing methods at the

language engine level or at the http server level. End of HPP Prevent against HTTP header manipulation

Frameworks Tomcat + Java + Spring + Hibernate Default mitigations:

No stored or reflected cross-site scripting: all outputted data is escaped by default.

No SQL injection: use of prepared statements by default. Also easy to pick up any mistakes with some greps on the code.

Security classes and functions (i.e. authentication) provided by the framework.

Java is a language with strong types: cannot insert a string in an integer like with PHP.

Weaknesses: Access-control bypasses / insecure object references Know vulnerability in the MVC Malicious file upload No anti-scanning mitigations Insecure configuration

Hardened by default Malicious file upload vulnerability:

By default disable any methods and functions that may allow an application to execute commands on the server. Getting popular in PHP (aka hardening php.ini) Not as popular with Java which is well known to provide

*features* allowing to upload *modules*: Tomcat manager Websphere

Web: conclusion Web exploitation can be as context-dependant

as binary exploitation Web anti-exploitation mechanisms are not as

mature as binary anti-exploitation Too many technologies (web servers, database

servers) and languages