Fun With Dr. BrownSpencer McIntyre

Cleveland B-Sides

July 19th, 2014

Introduction

• Who am I?

• Spencer McIntyre

• Security Researcher @SecureState

• Metasploit Project Member

• Why we’re here:

• Introducing Dr. Emmett Brown

• We’re going to talk about Microsoft’s EMET

EMET Overview

• The Enhanced Mitigation Experience Toolkit

• Microsoft’s response for making unknown vulnerabilities more difficult to exploit

• EMET does not “fix” vulnerabilities, it makes them difficult to exploit reliably

• Crashes are easy but ain’t nobody got time for that

• Latest versions right now 4.1 (Production) 5.0 TP 2 (Technical Preview)

How Does EMET Make Exploitation Difficult?

• Protections are divided into 3 categories (Memory, ROP, & Other)

• Key protections:

• DEP

• MandatoryASLR

• NullPage

• StackPivot

• Export Address Filtering (EAF)

• 7 Others in EMET 4.1

Application Configuration

• Consult the EMET User’s Guide for details

DEP & ASLR• Every application should use

DEP & ASLR

• Can be configured by both the OS (with or without EMET) or by applications

• Almost all Windows native modules are ASLRed since Windows 7+

• Have to be careful about third party applications

Brief History of Bypass Techniques

• ASLR and DEP bypass techniques are not EMET specific

• Predate EMET

• “Jump” over hooks

• Can make the exploit become Windows version specific

• November 17th, 2010 SkyLined posts a whitepaper on “Bypassing Export address table Address Filter (EAF)” targeting EMET 2.0

EMET Start Up• EMET.dll is loaded into the protected

process

• Even when no protections are enabled

• The EMET.dll loads the configuration from the registry

• EMET Configuration is copied to RW segment

• Can be changed at run time by the application

• First noticed in EMET version 4.0

Picking A Vulnerability

• Desirable Qualities

• Large amount of payload space (>750 bytes)

• No bad characters

• Non-ASLRed executable module (at least, DLLs are a bonus)

• CVE-2013-2492

• Stack Base Buffer Overflow in Firebird Database

• Meets all requirements

• Remotely exploitable for SYSTEM shell with default configuration

What Protections Work?

• Protections target specific vulnerabilities

• Not all protections are always applicable (Example: Null Page)

• Protections for CVE-2013-2492 (DEP & ASLR are already bypassed via ROP)

• Caller

• EAF

• Deep Hooks

• Banned Functions

What Are We Going To Do?

Patch The Action Via ROP

• EMET is ASLRed

• GetModuleHandleA() is not a protected function

• ROP chain resolves the EMET base address dynamically

• Change offset from EMET base address to change the configuration

• Two locations for completely disabling

• &EMET+0x0079074 (EMET 4.0 & 4.1)

• &EMET+0x007e07c (EMET 4.0 & 4.1)

Configuration Value References

EMET Disabling ROP Chain

• 19 Gadget EMET Disabling ROP Chain

• Main steps are:

1. Reslove EMET base address via GetModuleHandleA or similar

2. Calculate offset via constants

3. Modify the values of the offsets

The Result

• After patched, trigger all the protections!

• No shellcode modification necessary

• Metasploit payloads can be used

• Energy required to exploit?

• Less than 1.21 gigawatts

Demo Time

EMET 5.0 Tech Preview 1

VULNERABLE

EMET 5.0 Tech Preview 1

• Still vulnerable

• Encoded Pointer is Optional

• What do we do? Disable it!

EMET 5.0 Tech Preview 2

Fixed

EMET 5.0 TP2 Fix

• Configuration no longer stored in .data

• Stored in space allocated at run time

• Pointer to configuration is stored in .data

• Protected with EncodePointer/DecodePointer

• Permissions are set to Read Only

• Resolving EncoderPointer via ROP would pose a risk

• Existence in IAT of non ASLRed module

• Overwrite configuration location as in 5.0 TP1 bypass

Closing Thoughts

• Main executables (.exe’s) without ASLR are bad

• Really bad, not even EMET can fix that

• EMET’s Deep Hooks is a great setting

• Metasploit’s PrependMigrate is also a great setting

• When the going gets tough execute a Powershell command

• This technique is not a silver bullet

• The vulnerability and affected software needs to meet some criteria

Timeline• October 27, 2009: Initial release of EMET 1.0.2 (then Enhanced Mitigation Evaluation

Toolkit)

• June 17, 2013: EMET 4.0 released

• October 28, 2013: SecureState notifies Microsoft's Security Response Team of the flaw in EMET 4.0. Microsoft responds requesting technical details

• October 29, 2013: SecureState provides Microsoft's Security Response Team with technical details for the bypass

• November 5, 2013: Microsoft acknowledges technical details from SecureState

• November 12, 2013: EMET 4.1 released (still vulnerable to the bypass)

• November 15, 2013: Microsoft's EMET team contacts SecureState to discuss the bypass

• February 25, 2014: EMET 5.0 Technical Preview released, SecureState credited for collaboration

• April 30, 2014: EMET 4.1 Update 1 and EMET 5.0 Technical Preview 2 released

• SecureState's bypass is patched in EMET 5 Tech Preview 2.

• July 1st, 2014: Offensive Security posts a blog “Disarming Enhanced Mitigation Experience Toolkit (EMET)” Outlining this vulnerability

Questions?

References

• Skypher: http://www.exploit-db.com/wp-content/themes/exploit/docs/15579.pdf

• 0xdabbad00: http://0xdabbad00.com/wp-content/uploads/2013/11/emet_4_1_uncovered.pdf

• Exodus Intel: https://www.exodusintel.com/files/Aaron_Portnoy-Bypassing_All_Of_The_Things.pdf

• Offensive Security Blog: http://www.offensive-security.com/vulndev/disarming-enhanced-mitigation-experience-toolkit-emet/

• http://bromiumlabs.files.wordpress.com/2014/02/bypassing-emet-4-1.pdf

Thanks For Your Time

• Thanks to Jake Garlie for Research Assistance

• Spencer McIntyre

• @zeroSteiner