3. Definition & Scope
Exploit mitigation: “a feature of the operating system
which enhance the difficulty of exploiting a
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.
4. Intended audience
Not experts in exploitation
You would like to get some insights on how exploit
mitigation technologies work and what are their
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
5. Part i – Introduction to binary exploitation
6. 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)
7. Normal control flow of an application
8. In Memory
Region 3Region 2Region 1
Memory is divided in regions.
9. Memory regions
Each region has:
A start address
Access control properties: read, write, execute
Within each applications we also find the following
The stack – to story static data
The heap – to store dynamic data
10. Concept of exploiting a memory corruption
shellcodeFunction 2 has a fault
which allows attackers to
modify the control flow of
Function 2 will jump into the attackers
Shellcode instead of Function 3.
11. 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
12. Exploiting a vulnerability: 3 requirements
13. Part ii – Exploit mitigation technologies
14. Exploit mitigation mechanisms
An overview at the history
Analyzing specific mechanisms
Applications compiled with Visual Studio (Microsoft’s
A certain number of flags need to be on:
16. Exploit mitigations
Two (2) main categories of mitigations
The ones that try to stop common know exploitation
The ones that try to detect a memory corruption
17. /GS cookie
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.
18. SEH Overwrite attack
One popular technique to bypass /GS was to overwrite the ‘SEH pointer’ located a
the return address in memory. Then attackers would crash the application, resultin
that pointer being used by the exception handler. Hence then taking control of the
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
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
20. Structured Exception Handler Overwrite
1. Anti-exploitation mechanism introduced in windows Vista to prevent SEH
overwrite attacks similar to the stack cookie
2. Set by default in Win 7
3. Checks that the random value located after the SEH pointer has not
been modified before using the pointer.
21. Data Execution Prevention (DEP)
(read / write)
(R / X)
(R / X)
i. Attackers have to find a location where to store their shellcode.
ii. The known memory regions they use have been marked Non-Executable
iii. Hence, their shellcode cannot be executed by the application anymore
22. Address Space Layout Randomization
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
Image taken from the paper ‘Bypassing Browser Memory Protections’
24. Part iii – Vulnerability Context
25. The properties of a vulnerability
The context in which a particular vulnerability is
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
26. 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.
27. Example: the ANI vulnerability
First public exploitable
vulnerability on Windows
Discovered by Alex
Vulnerable function not
protected by /GS
ASLR’s entropy too small,
hence could be brute
DEP not yet implemented
in Internet Explorer 7 at
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
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
No public technologies to perform that type of scoping yet
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
Exploit mitigations also impact on bug fixing
Hence the importance of knowing which sections of an
application is less likely to be effectively protected or not.
30. Contexts or attack patterns that allow to
bypass anti-exploitation mechanisms
Inject shellcode is Executable memory regions
Return into libc / returned oriented programming
Disable DEP manually on the system
Requires a bug which leaks information about the memory
layout (i.e. a memory address)
31. Contexts or attack patterns that allow to
bypass anti-exploitation mechanisms
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
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)
32. The future of exploitation?
Applications known to offer contexts to bypass
Browsers and their plugins (i.e. Flash, Acrobat)
Applications known not to be protected by all
Kernel mode applications
Operating systems not as protected as Windows
Other kind of devices not protected with mitigations:
33. Part iv – Miscellaneous
34. Lifetime of an attack pattern: /GS & SEH
/GS: Introduced in 2003
Bypass: overwrite the SEH handler.
Safe SEH: Introduced in Windows XP SP2 (August
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.
35. Lifetime of an attack pattern: /GS & SEH
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
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.
36. Lifetime of an attack pattern: return
oriented programming (ROP)
1997: Solar Designer published the first ret2libc
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.
37. 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
38. Enhanced Mitigation Evaluation Toolkit
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+
Null page allocation
Heap spray allocation
39. Shellcode isn’t necessary a shell
40. Part vi – Conclusion
Exploitation on the Windows platform is considerably
harder but memory corruption vulnerabilities are not
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.
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
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?
The ANI bug video:
Paper ‘Bypassing Browser Memory Protections’:
Mark Dowd, Alex Sotirov
There’s a party at ring0 and you’re invited:
45. Part v – Web related stuff
The following content was presented at OWASP. Excluded
46. 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.
Ineffective against stored XSS
47. 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
48. Stopping automated tools
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
49. 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
Tomcat + Java + Spring + Hibernate
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
Java is a language with strong types: cannot insert a string in an
integer like with PHP.
Access-control bypasses / insecure object references
Know vulnerability in the MVC
Malicious file upload
No anti-scanning mitigations
51. 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*:
52. Web: conclusion
Web exploitation can be as context-dependant as
Web anti-exploitation mechanisms are not as mature
as binary anti-exploitation
Too many technologies (web servers, database servers)