The process of a successful stack based BOF-Part 1

n0limit his legend preceeded him but the real deal is way better then the legend! No, really this dude really helped me out in the process to making it work. When doing BOF bugs there is a HUGE difference between reading about it and putting it to practice. Another big thanks go out to KD he got me interested in this stuff again. I mean with all the web exploiting going on these days…you’d almost forget about the giant of all times. The infamous Buffer Overflow!

So what is this post all about?  This post is about me getting involved with a BOF to help a friend out. I was like oh BOF right I’ve read tons of papers about those and I’ve practiced a bit so it shouldn’t be that hard, or should it? When putting all the read papers into practice it turned out to be a bit harder then I had initially antipicated. So here is the BOF I’m talking about:

• http://www.go4expert.com/forums/showthread.php?t=11839#firstm

Before you carry on reading I recommend that you read a few of the following:

• http://insecure.org/stf/smashstack.html
• The  Shellcoders handbook
• http://www.securiteam.com/securityreviews/5OP0B006UQ.html

It’s all based on “vuln.c” and “exploit2.c”. I compiled both using visual studio 6 and to my big surprise they didn’t work on my XP SP3 :(. The truth be told they are not very difficult. So what happend when I run it?

This was also my first experience that theoretical knowledge doesn’t cut it in the field…I mean the pretty book layouts with debugged data was not beeing shown on my screen. So what now? My first reaction was like…I need to step through the process that’s crashed to be able to pin-point wth is going on. I then remembered one of korupt’s excellent posts:

• http://korupt.co.uk/?p=115

There he explains a malware trick to debug child processes. Well that is exactly what we need in this case, since our exploit code just creates a new process(actually calls the application with arguments). So what we need is to break on the new application as soon as it gets called. Here comes the good old hexeditor…I prefer hexediting in a old school style editor above olly just for the fun of it. So I used the HT Editor. I could have put a INT 3(0xCC) on PUSH EBP , but that would have been a tedious job while debugging the process…cause it takes a lot of instructions to get to the vulnerable part of the program. Instead I choose the old cracker’s approach find the code by strings. In olly perform a “Search For -> All Referenced Text Strings” this should give you a strings list including the string “Supply an argument, dude”. It lands you in a function and if you look carefully in olly you see that’s beeing referenced from somewhere else.

In the bottom left you see from where it’s beeing referenced(don’t forget I moved up with the cursos until I hit the asm line “CMP DWORD PTR SS:[ESP+4],2”) if you don’t do that and stay on the one with the string reference you will not see from where it’s beeing referenced. You can now choose you go further back or just take a second look at the asm, you will see that it compares something with 2. So if you remember the C source, this line is actually checking if there are enough arguments passed to the program. So after this the call to the vulnerable function should happen, which it does cause you can clearly see the call in the disassembled output(hint: it’s the second call, just analyze the jmp and you’ll know why). So I followed that call and decided to put my breakpoint on the PUSH ESI. So fire up HTE go the correct offset and change the opcode to 0xcc(in the screenshot the corresponding opcode is marked red).

So after you have saved your changes , you can run the exploit again (and if you have configured olly as Just in Time Debugging) which should pop-up olly right at the vulnerable function. STOP before you just press F7/F8/F9 remember that you have to put back the original instruction, in this case the PUSH ESI. So press space bar and do it.

Now we can happily press F7/F8/F9 and observe the stack and the overflow string to determine exactly why the hell it doesn’t work.

For the moment beeing this is it, cause it’s almost 3 AM over here. Tomorrow I will blog about the second and last part, analyzing the stack and fixing the exploit so it works as it was intended. In my personal experience and opinion the process of achieving your goal is much more important then achieving it IF your goal is to understand IT. So I hope to make it easier to understand buffer overflows, by providing the opportunity to read about the process of actually building/fixing a buffer overflow.