practical reversing vi - exploit development [advanced]

PRACTICAL REVERSING VI - EXPLOIT DEVELOPMENT [ADVANCED]

Amit Malik

www.SecurityXploded.com

Reverse Engineering & Malware Analysis Training

http://www.securityxploded.com/

Disclaimer

The Content, Demonstration, Source Code and Programs presented here is "AS IS" without any warranty or conditions of any kind. Also the views/ideas/knowledge expressed here are solely of the trainer’s only and nothing to do with the company or the organization in which the trainer is currently working.

However in no circumstances neither the trainer nor SecurityXploded is responsible for any damage or loss caused due to use or misuse of the information presented here.


Acknowledgement

Special thanks to Null & Garage4Hackers community for their extended

support and cooperation.

Thanks to all the Trainers who have devoted their precious time and

countless hours to make it happen.

Thanks to ThoughtWorks for the beautiful and bigger venue.


Reversing & Malware Analysis Training

This presentation is a part of our Reverse Engineering & Malware

Analysis training program. Currently it is delivered only during our local

meet for FREE of cost.

For complete details of this course, visit our Security Training page.


http://securityxploded.com/security-training.php

Who am I #1

Amit Malik (sometimes DouBle_Zer0,DZZ) Member SecurityXploded & Garage4Hackers

Security Researcher @ McAfee Labs

RE, Exploit Analysis/Development, Malware Analysis

Email: [email protected]


Agenda

The material in this presentation is a bit complicated so I

will be using the zig-zag approach.Recap

Protections (GS and SAFESEH)

Client side exploits and Heap Spray

Protections (DEP)

Protections (ASLR)

If time permits then few words on the following:Heap buffer overflows


Recap In previous session we covered:

Stack based buffer overflow○ EIP overwrite (saved return address)

○ SEH Overwrite

We also discussed “why we need pop pop ret or other similar

instruction in SEH overflow”

Now Question: Which one is more reliable or considered to be

more reliable in terms of exploitation ?

Consider we have overwritten EIP and SEH successfully.


Protections Enforced by OS and Processor

ASLR

DEP

GS Cookies SAFESEH

SEHOP

Forced ASLR


*Safe unlinking, Heap cookies etc. are also protection methods added into the OS.

Protections for stack based buffer overflow (Primary)

Fortunately or Unfortunately both protection schemes are

based on compiler/Linker options.

* SEHOP is a different protection scheme based on run time SEH chain validation, It is not based

on compiler options however can be enabled or disabled through registry.

GS Cookie

EIP Overwrite ?

SafeSEH (SEHop*)

SEH Overwrite ?


GS Cookie (/GS)

Put some random value (cookie – 32 bit) on stack

before return address.

While returning, compare the value of saved

cookie, if not same then we have an overwrite.

Generate “ Security Exception (if any)”, terminate

the Application.


/GS Cookie Cont...Function Start:

Function end:

Cookie check function (see “function end” in below picture.)


/GS Cookie Bypass

Generate exception before cookie checkCode dependent – if some overwritten variables are used before

function return.

Overwrite stack up to the end, further overwrite will generate

exception

Back to the question which exploitation (EIP or SEH) is

more reliable ?SEH method is considered to be a bit more safe and reliable

regardless of this bypassing technique.


/GS Cookie Bypass Cont..Leverage the implementation. Did you see something ?


SafeSEH Compiler [Linker] /SAFESEH option

Static list of known good exception handlers for the binary.

Checks every time when a handler is called against the static list, if

not in the list then handler is invalid and takes preventive measures.

Load configuration directory stores meta information about safe

exception handlers.

If any module is not compiled with /SAFESEH then no check is

done to ensure the integrity of the handler for that module.


/SAFESEH Bypassing

If any loaded module in the vulnerable binary is not /SAFESEH

compiled then no check is done to ensure the integrity of the handler

for that module, so we can use any p/p/r address from that module.

Use the address that is outside the address range of loaded modules.

Importance of forward and backward jump.

nseh

seh

payload

payload

nseh

seh

Forward jump

Backward jump


DEP (Data Execution Prevention)

Two types:Software DEP (forget it)

Hardware DEP (NX/XD enabled processors) – we will be

talking about it in the rest of the session.

We can’t execute the code from non executable

area anymore.

We are directly dealing with processer in this case.


DEP (HW) Bypass

ROP (Return Oriented Programming)Use the system/existing code

How stack works ?

Main themeEither make non executable area executable

Or allocate new area with executable permissions

How ?

○ Well, use ROP


Stack Heap Flipping (Stack Pivoting)

I think this deserve a dedicated slide

Depending on the conditions we may have large ROP payload while

space on stack may be less or may be our entire payload is on heap.

Flip the heap on to the stack so that we can get larger room.

Instructions like XCHG ESP[REG], REG[ESP] can be used.

We can also jump inside the valid instructions to change their meaning.

Example: jump one byte inside “setz al” instruction ( From Adobe

U3D exploit in wild)


DEP (HW) Bypass (DEMO)

MethodsHeapCreate

VirtualAlloc

VirtualProtect

WriteProcessMemory (DEMO – simple, easy,

demonstrate the entire concept – XpSp3)

Often times the small code chunks in ROP are

termed as “gadgets”


DEP (HW) Bypass (DEMO)

http://vimeo.com/49069964



ASLR

Address Space Layout Randomization

Involves randomly positioning the memory areas

like base address of the binary, position of stack

and heap.

Compiler[linker] /DYNAMICBASE option


ASLR Bypass

Search for Non-ASLR loaded libraries in the

vulnerable application or if possible load one. JRE ?

Memory leaks

Brute force

Heavily depends on vulnerability conditions


Client Side Exploits

Exploits that targets client applications like browsers,

plugins, media players, readers etc.

Much more dangerous then any other form of exploits

Huge impact and landscape

Provides solid infection vector

Big malicious infrastructure.Botnets, DDOS, Spam etc.


Heap Spray

A technique used in client side exploits

IT’S NOT A VULNERABILITY or CLASS OF VUL.

It’s a technique used for code execution.

Think about the followings again:

EIP overwrite

SEH overwrite

• What we used in the above and why we used that ?

Heap spray provides very simple method for code execution.


Heap Spray Cont...

Fortunately or unfortunately client side scripting languages like javascript,

vbscript etc. provides methods to allocate and deallocate memory on the client.

Which means we can make invalid memory addresses valid.

Valid address invalid address range

(allocated area)

0x200... 0x400.. 0x500..

Valid address invalid address range(allocated area)

0x200... 0x300.. 0x500..

Before Allocation

After Allocation (0x300.. To 0x400.. Is valid now)


Heap Spray Cont..

Allocate memory and fill with nop + shellcode

Overwrite the EIP or SEH with any address within

the newly allocated area (the nop region).

Here EIP overwrite or SEH overwrite can be by

any means.Stack buffer overflow, Heap buffer overflow, memory

corruption, use after free etc..


Heap Spray (DEMO – IEPeers Vulnerability (IE6, IE7)




Heap Spray (Stability Comments)

Use intelligent guesses

Stability depends on the exploitation conditions

Fragmented heap, choose little higher addresses.

Large number of allocations, choose little lower

addresses


Reference

Complete Reference Guide for Reversing & Malware Analysis Training


http://securityxploded.com/malware-analysis-training-reference.php

http://securityxploded.com/malware-analysis-training-reference.php

Thank You !


http://www.securityxploded.com/

practical reversing vi - exploit development [advanced]

Documents