and solar designer wrote first generic heap exploit on windows netscape exploit

==============================================
at that times because of really low OS memory protections and also low application specific protections (can also called CPU and compilers problem !) , a poor input validation and an insecure memory copy was enough to corrupting memory (mostly in stack area) and overwriting a function return address and getting control of instruction pointer (IP , EIP) and then by storing malicious code (called shellcode) and using a pointer (mostly stack pointer (ESP)) execution flow can be change and pointer to attacker malicious (or educational ;) ) code.

so OS developers and security guys had to think about memory protections and casper dik in nov 1996 wrote a kernel run-time patch to implement non-executable-stacks for Solaris 2.4 to 2.5.1 http://seclists.org/bugtraq/1996/Nov/57

and later solar designer released same thing to remove executable permission for stack on the linux here

and around ~2000 solar designer made return-to-libc attacks to return in executable page and functions in memory for bypassing non-executable memory. the basic idea was after controlling executing flow return to some function like system() and executing a single command or …. but there was a problem and the attacker was limit in payload selection and can’t use advanced payloads .

so around ~2000 we had :

basic / intermediate stack overflows

basic heap overflows

basic / intermediate format strings (killed so soon !)

basic memory protections

basic bypass memory protections

also some other type of memory corruptions (not so general)

=========================================

part II : history of windows exploitation from windows 2000 to windows 7

i wanna start from windows 2000 final version of NT family because i think older windows are not interesting enough to talk about .

exploit developers golden age : microsoft was is supporting and making money from windows 2k and unfortunately forgot protect you from buffer overflow attacks . so old and classic attacks works like a charm and just maybe in some case we saw very complex and smart vulnerabilities but exploitation by itself was not that hard (maybe just some application specific filters / protections )

so because of that poor protection we saw great worms like :

blaster worm one of historic worms ever that used a RPC vuln for attack and fixed in http://www.microsoft.com/technet/security/bulletin/MS03-026.mspx

and maybe you can remember : “billy gates why do you make this possible ? Stop making moneyand fix your software!! “

and this cool picture :

slammer worm a great and fast worm that used an SQL Server buffer overflow for attack. that fixed after 6 month !!! in :

http://www.microsoft.com/technet/security/bulletin/MS02-039.mspx

sasser worm another great worm that used lsass remote overflow vulnerability and fixed in: http://www.microsoft.com/technet/security/bulletin/MS04-011.mspx

but there is a question these worms targeted windows XP and 2003 as well too ? yes !

because microsoft did that great job in windows XP service pack 0 and 1 as well as windows 2003 service pack 0.

3- Nish Bhalla’s series on Writing Stack Based Overflows on Windows in 2005

http://www.packetstormsecurity.org/papers/win/

if i want to have brief description of them they all are talking about finding a reliable return address in a reliable Dynamic Linked Library (MOST in OS DLL’s kernel32.dll ntdll.dll shell32.dll user32.dll and … ) and then after overwriting a function return address by sending big value to not good checked input variable and getting program execution flow redirect that flow to address in DLL that address is mostly JMP / call / PUSH ESP (stack pointer) or EBP (base pointer) because most of time in classic stack overflow attacker store her / his malicious code in the stack and a JMP / CALL / PUSH ESP RET will lead his / her to jump to start of shellcode .thats all!

if i want to have brief description of them they all are talking about exploiting unlink macro and using write4 (where + what) and actually ability of writing 4byte (32bit ) of selected address in memory by using specific function pointers like :

UnhandledExceptionFilter

VectoredExceptionHandling

RtlEnterCriticalSection

TEB Exception Handler

Application specific function pointer

…..

kernel based Windows overflows (not so classic)

because of Inexorability of this type of attacks i want to share all of most notable history in this area here : (note that i will back to heap and stack with protections after in it)

=================

First noticeable whitepaper that stated how to attack kernel based vulns on

in that paper Justin talked about new type of kernel attacks and about i2OMGMT bug that founded by ruben.

11- later in 2008 Kostya Kortchinsky did a presentation called Real World Kernel Pool Exploitation

http://sebug.net/paper/Meeting-Documents/syscanhk/KernelPool.pdf

in that presentation kostya talked about how he wrote exploit for ms08-001 (Microsoft marked it as not-exploitable !)

12- later in 2008 Cesar Cerrudo wrote Token Kidnapping and a super reliable exploit for windows 2k3 and 2k8

artice :

http://www.argeniss.com/research/TokenKidnapping.pdf

poc 2k3:

http://www.argeniss.com/research/Churrasco.zip

poc 2k8:

http://www.argeniss.com/research/Churrasco2.zip

13- again later in 2008 mxtone wrote a paper called Analyzing local privilege escalations in win32k
http://www.uninformed.org/?v=10&a=2&t=pdf

in that paper he analyzed vulnerabilities and exploitation vector of win32k driver .

14- in ucon 2009 Stephen A. Ridley did a presentation called Intro to Windows Kernel Security Development
download it here

15- Tavis Ormandy, Julien Tinnes and great presentation called There’s a party at ring0 and you’re invited
http://www.cr0.org/paper/to-jt-party-at-ring0.pdf

16- in January 2010 Matthew “j00ru” Jurczyk and Gynvael Coldwind, Hispasec wrote a detailed paper called GDT and LDT in Windows kernel vulnerability exploitation.
http://vexillium.org/dl.php?call_gate_exploitation.pdf
in that paper they describes some possible ways of exploiting kernel-mode write-what-where vulnerabilities in a stable manner

17- later they did a presentation called Case Study of Recent Windows Vulnerabilities in HITB 2010

Windows memory protections !

OK so now we are going back to user-land this time with memory protections !

due to lots of generic exploitation methods as well as lots of worms ! Microsoft decided to use of memory protections in hardware and software layer. so from windows XP SP2 (Windows XP Tablet PC Edition 2005) , Windows Server 2003 Service Pack 1 (OS level) and from visual studio 2003 (compiler level) added lots of memory protections functionality.

here i’m going to have brief history of them and then i will introduce great researchers and their research against memory protections .

1- Data Execution Prevention (DEP)

DEP is a security feature included in modern Microsoft Windows operating systems that is intended to prevent an application or service from executing code from a non-executable memory region. This helps prevent certain exploits that store code via a buffer overflow, for example.

hardware-enforced DEP for CPUs that can mark memory pages as non-executable, and software-enforced DEP with a limited prevention for CPUs that do not have hardware support.

in windows XP SP2 and windows 2003 sp1 and sp2 you can get access on DEP setting by editing boot.ini in noexecute section.

there is four options :

1- OptIn : DEP only will work for all of windows services as well as necessary programs.

2- OptOut: DEP will work for all of windows services as well as all of 3d-party installed program but you can add some process as exception from controll panel.

3- AlwaysOn : fully protected by DEP no exception is acceptable.

4- AlwaysOff : Go to hell DEP , turns DEP off .

most of CPUs those are made after 2004 (AMD , Intel) can support hardware DEP.

read more on DEP : http://support.microsoft.com/kb/875352

/GS (Buffer Security Check)

GS (a.k.a stack cookie) is a compiler option that added from visual studio 2003 and will detects some buffer overruns that overwrite the return address, a common technique for exploiting code that does not enforce buffer size restrictions. This is achieved by injecting security checks into the compiled code.

so by using /GS flag compiler will add __security_init_cookie() function to your program and each time you want to overwrite a function return address you actually overwrite cookie as well and so comparison of cookie will fall so process will be terminate and you can’t use your return address.

for more detail read : http://msdn.microsoft.com/en-us/library/Aa290051

/SAFESEH

a linked option also system functionality added in visual studio 2005. when a program is linked with /SAFESEH in header of file will be contain of a acceptable Exception Handler Table. so each time an exception occurs and attacker wants overwrite a record from exception handler the ntdll dispatcher will understand this and will terminate program execution.

for more detail read : http://msdn.microsoft.com/en-us/library/9a89h429(VS.80).aspx

ASLR

Windows Vista, 2008 server, and Windows 7 offer yet another built-int security technique (like PAX), which randomizes the base addresses of executables, dll’s, stack and heap in a process’s address space (in fact, it will load the system images into 1 out of 256 random slots, it will randomize the stack for each thread, and it will randomize the heap as well).

in simple explanation if you want use an address in system in one of system dll’s after your target system got restart your address is changed and not valid anymore so exploitation will fail again.

for more detail read : here

SEHOP

used in most modern windows operation systems like 2008 and 7 . the idea beyond this new mitigation comes from matt miller article called Preventing the Exploitation of SEH Overwrites. for detailed explanation of this protection just read flowing link :

this paper actually was first detailed paper about abusing SEH (structured exception handler) and the generic way to bypass /GS and also write not lots of public exploit are using this method for exploitation so it also can called one of most important research in windows exploitation history.

i think that was one of most important heap related research in history of windows exploitation a great and gentle introduction to overwrite a chunk on lookaside list for bypassing safe unlinking and also give lots of great information about windows heap manager internals .

this article was first great and public article about using egg-hunter shellcode and it’s about when we have limited memory space for our shellcode and we can store our big and main shellcode some-where in memory. this can be also called practical introduction to search shellcodes .

7- later in 2004 skylined wrote on IE exploit and used a technology called Heap Spray

http://www.exploit-db.com/exploits/612

heap spray is one of most important technologies even in modern exploitation and it’s about code that sprays the heap attempts to put a certain sequence of bytes at a predetermined location in the memory of a target process by having it allocate (large) blocks on the process’ heap and fill the bytes in these blocks with the right values. They commonly take advantage from the fact that these heap blocks will roughly be in the same location every time the heap spray is run.

for a few years heap spray was just used in java script and mostly in browsers but today modern attackers are using anything possible to allocate more heap for sparing . like action script , silver light , bmp files and … and not just in browsers ! from my point of view heap spray is like cheating in modern exploitation !

yay ! they finally did it . hardware enforced DEP bypassed by using a return to libc style attack . in simple explanation the problem was in not CPU the problem and weakness was in windows related API that was used for setting DEP for various process. and the API was NtSetInformationProcess. but there was some simple problem in that article like they forget talk about it we need to to have EBP always writable.

note that before ruben we can find lots of great research about this topic but ruben makes it different . he made a tool that called kartoffel which is a great driver fuzzer for finding IOCTL vulnerabilities in drivers. but kartoffel was not main reason to make it different.

after he wrote kartofell and published lots of detailed advisories in various vendor drivers , windows driver exploitation got speed and changed to one of focusable area in exploitation .

notable improvements to skylined heap spray technology . heap spray was good but blind and not so reliable is some case. Heap Feng Shui is great research about doing advanced FU in heap (heap manipulation) it will lead you to have more control on heap.

not a so new technology. it’s just our old code reuse ! but with great official introduction he call it Return-Oriented-Programming (now known as ROP ). this technology is great to bypass permanent DEP (vista / 7 / 2008) (because you can’t use return-to-libc style attack anymore)

also he wrote a cool immunity debugger PyCommand called PveFindAddr i think this python script is necessary for speed-up exploit development for newbie or expert exploit developers and i found it so useful , it have some cool features like finding instructions for code reuse and ROP also finding state of memory protections and finding best return address in your situation.

this is not complete lits of exploitation related book / articles list i just listed those had at least one windows specific chapter .

PART III : Future of exploitation

Starring : T.B.A

1- exploitation is not and will not die.

2- just will change and being more harder also won’t be ” just for fun” like before.

3- writing reliable exploits will take time and time == money and now exploit development is acceptable specific job in security area !

4- fame == money as well (also is lovely by itself) . so you will see other great researches in various security fields ;)

5- if you read all of resources exist in post you can be a great exploit developer ; )

PS1 : during writing this post due to lots of links and peoples on it maybe i forgot some notable people / article you can alert me about them just by shahin [at] abysssec.com

PS2 : i wrote this post so fast (and took long time !) i will edit my Misspellings and grammatical in good time.

i,m really sorry for our late in posting we really working on lots of things … before starting about our subject i should tell you about our advisories and exploits we are not really full-disclosure believers but still we will post some more exploits and advisories at :

http://www.exploit-db.com/author/abysssec

so stay tuned.

OK let’s start ….

=========================================

before start if you are not familiar with PE : The Portable Executable (PE) format is a file format for executables, object code, and DLLs, used in 32-bit and 64-bit versions of Windows operating systems. The term “portable” refers to the format’s versatility in numerous environments of operating system software architecture.

for more information : http://en.wikipedia.org/wiki/Portable_Executable

- now the first question is what is a signature ?

a signature actually is what that means but in computer world and more specific in reverse engineering and binary auditing world a signature is a sequence of unique instructions (actually their representation op-codes) in target binary.

for better understanding please watch figure 1

figure 1 – a c++ compiled binary opened in immunity debugger

reminiscence : an opcode (operation code) is the portion of a machine language instruction that specifies the operation to be performed.

in above figure it have tree red rectangular :

first rectangular are RVA (relative virtual address) of instructions

second rectangular are OP-Codes (will be execute)

third rectangular are readable assembly instructions

so we will search for a sequence of unique op-codes (so sequence of instructions) in our target binary and those byte will be signature of our binary. simple enough eh ?

- what and who need to use a signature ?

most of anti-virus (and other anti-things)

and almost all of PE Detection tools

so now you can imagine how an anti-virus company can detect a malware and how PE-Detection tools (witch areused for detecting signature in compiled binary and determine compiler / packer / compressor and … ) works .

- next question is why we need care about signatures:

before starting any fuzzing / reversing / auditing project we need to about our target binary

identify binaries those have not any signatures

with them we can speed up our reversing and we can find available tools against our target binary

-how we can find signatures in binaries ?

we should search for static and constant location (static instructions) in our file but how we can find them? for answer to this question please watch PE file layout again :

figure 2 – PE file layout

we can search for signatures in a few areas :

around program entry point (where program instructions will start execution …)

from offset (from top to bottom)

each executable file have some other locations can be good for generating signature those are :

around import table (where functions will be import)

start and end of sections (optional section specially)

name of optional / static sections

….

so we can just open the executable under debugger and copy a few OP-Codes from entry point and we are done ? of course not ! because in lots of situations entry point could be change refer to various factors like :

initializing addresses / variables with state of program

if we are in fighting against a packer / compressor / cryptor / there are several technologies they can use for hiding / changing instructions …

note : these changes are more on not “just compiled binaries” it means those have a packer / protector and ….

so how we can find reliable signatures ?

we need to research about variant program situations and then we can understand which bytes/instructions are constant and which are not then we can ignore dynamic bytes and rely to static bytes.

before a real case study i just want explain how packer/protectors works :

a packer will do what it sounds : packing a program. think about winzip it will comperes the program and actually will decrease size of program .

elementary packers just will compress the portable executable and will change entry point to decompression section for better understanding just watch below figure.

figure 3 How typical packer runtime works

1. Original data is located somewhere in the packer code data section
2. Original data is uncompressed to the originally linked location
3. Control is transferred to original code entry point (OEP)

Ok now you know how a basic packer works but today modern packers are not just compressor they will use a lots of anti-debugging technologies against debugger / disassembler to make reverser life harder. this technologies are out of scope of this post.

Ok for example if we want to make a signature for a new packer / protector we need to pack / protect variant executable (it’s better to test on different compiler / size) and then watch which byte of files are changed and which one are static !

you can use binary copy option in immunity debugger for starting our test

figure 4 binary copy

this program is packed with a really simple and good packer named FSG.

and my first signature will be :

87 25 5C AD 41 00 61 94 55 A4 B6 80 FF 13 73 F9 33 C9 FF 13 73 16 33

so now i need to pack more files and check my selected Op-codes to know which one are changed and then we will replace changed op codes with ?? . after a few try we will get a signature like :

87 25 ?? ?? ?? ?? 61 94 55 A4 B6 80 FF 13 73 F9 33 C9 FF 13 73 16 33

so if i search for these bytes i can find i can find them in any program those are packed with FSG v2 !

this example is really really simple for advanced packer we need really test more bytes to be sure our signature is good enough but from my experience length between 30-70 byte from entry point are good enough.

if you be smart you will select good instructions like sections those have 16-bit registers and instructions those are not used all times. so an example of really good signature can be below figure (taken from symantec slides) :

figure 5 ( a really good signature )

OK. now you can make you own signatures just by spending a few time on each target . there are several tools can be use for detecting signatures if executable most popular of them are :

PEiD

RDG Packer Detector

PE Detective

but all of them have a same problem not so update signatures ! so if you have a program that is packed by a really new packer or just a few byte take changed from their signature most of them will fail (intelligent signature detection is out of scope of this post) . so what we can do ? we should have our own database for our job .

so i collect all of existing signature database (those i found) in internet and i removed stupid and duplicated signature from the list those are :

BoB at Team PEiD signature database

Panda Security customized signature database

Diablo2002 signature database

ARteam members signature database

SnD members signature database

Fly signature database

and …

after i combined all of their signature databases i changed a few of important signature to be more general and i added some new signature to my list and my final list right now have around 5064 unique and 4268 from entry point signature.

PEiD can parse external signatures and it’s nice but i liked to have detection in my debugger so i searched for a signature detection library in python (i like python) and with a quick search i found nice Pefile coded by Ero Carrera can handle all of our requirement in working with PE file not only handling signatures you can download it at :

http://code.google.com/p/pefile/

so i decide to use this library to write a pycommand for immunity debugger fortunately i found a copy of a pefile in immunity debugger lib ! so all i have to do is writing a few line of code that can read my database and test it against my binary and tell me the output .
so here is my complete script also have a option for auto-update .

for using this script you just need copy PeDetect.py in you PyCommand directory in immunity debugger python then copy Database.TXT in DATA folder in immunity debugger. after this you just need run it from immunity debugger command bar using !PeDetect you can see the output of this script against some files…

figure 6 – output of PeDetect against not packed file

figure 7 – output against packed file

also this have an argument !PeDetect -u for updating your signature to our latest database. notice that my script will use md5checksum so your changes meaning it won’t be same as my database and your database will be update automatically.

figure 8 – update command

PS : after i wrote this i saw another PyCommand named scanpe wrote by BoB at PeiD it’s really good and have PE scan option but have not update update so no more new signatures …

The Portable Executable (PE) format is a file format for executables, object code, and DLLs, used in 32-bit and 64-bit versions of Windows operating systems. The term “portable” refers to the format’s versatility in numerous environments of operating system software architecture.