Realistic Server Hack Using Buffer Overflow - hack a server daemon to gain access

[offtopic]
Thanks in advance for willing to explain me this, I couldn't find anything on google about it. Anyway, I think I'm not going to think to much about this today since I am going on vacation tomorrow and I don't want to end up thinking this entire thing over when I'm supposed to give my head a rest .
[/offtopic]

Comment/Reply (w/o sign-up)

The reason i made the buffer so small was to add an extra hurdle to the challenge.
I believe one way around it is to store the shellcode in an environment variable.

The origonal chalenge here, is to simply "Make the server do somthing it shouldnt"

So you dont nessecerily need to spawn a prompt to succeed.

Jipman managed to overflow the EBP register, and jump execution to a different part of the main() function.

I believe 20 bytes is plently of buffer to insert shellcode to cause the program to exit cleanly with EXIT_SUCESS.

Although a shell exploit is possable, i will be very very very very impressed if you succeed. That is way beyond the scope of the challenge.

good luck

Comment/Reply (w/o sign-up)

Since jipman asked about running a command line I'll explain it. It's good to have the Win32 Reference handy (I think the file is called win32.hlp, I'll confirm that when I'm back on Windows).

I'll start off with the program we would use to figure out what's needed to spawn a command line (under Win2K/XP)


/* C Programming */
/* func.c */
#include <windows.h>

void winexec(void)
{
WinExec("cmd", SW_SHOW); // SW_SHOW is constant for 0x5
}

void exitprocess(void)
{
exit(1);
}

int main(void)
{
return 0;
}

I would compile this as gcc -S -o func.s func.c

That way we get the output dumped in func.s as opcode, we can then use nasm to rewrite the functions if needs be.

When we compile that program to executable and run it, nothing happens (that's the point). Basically the key thing here is our functions, we use gdb to (disassemble) disas winexec to show us what's happening and exitprocess to show how we can exit successfully from the program, I used exit(1) because we don't want to use NULL and I'll explain why when shellcoding.

So that's a possible way of spawning a shell, just sending it cmd, but we could do more than send cmd we could "cmd /c start some_malicious_program" or start mspaint (which could be seen malicious ).

We can use OllyDbg too, infact I will recommend it over gdb for this as OllyDbg can also tell us what's happening, and makes it far easier than converting AT&T Syntax to Intel Syntax. (OllyDbg is also great for making game trainers due to it's ability to change memory addresses during runtime, but that's another tutorial )

We refer to the win32 reference book to discover what arguments need to be passed, and must remember that the stack works backwards, so our last argument must be push first and so on. We also need to know what to store in our registers for when we call WinExec or ExitProcess.

Now we don't even need to do this, if we knew what to pass and how the command is ran we wouldn't need to write the program in C and then disassemble it, this is just the easier way to do it and also provides an insight into how the program works.

Another thing I will have to tell you is finding the memory address for WinExec and ExitProcess (they exist in memory because all programs require it including the OS, it's also dynamic or shared, meaning multiple programs can use it at once).

If you have Win32Dasm then I suggest opening /system32/kernel32.dll and looking for WinExec and ExitProcess address and writing it down for later use. Otherwise I will show you how to write a program yourself in C++ to show you how to grab the addresses. There are more dll/APIs that we could write shellcode for, but since we're using WinExec and ExitProcess they both are from kernel32.dll. If you know Win32 APIs then you might know of some other locations that are interesting to know.

The reason we need these addresses is if you look at the call opcodes, it's not telling you much, but I can tell that the opcode when we write it will be call <memory_address> and it will be related to WinExec and ExitProcess. We ignore the calls for Main and Alloc, as that's part of our program, we aren't writing a runnable program (one that can be executed with no errors), just writing program code to load up in memory for the exploit to run.

Sorry that I ran on, there's a few vital things in here, but I'll write it properly when I'm on Windows. Hopefully have the majority of it done for this weekend, it's quite hard shuffling work and shuffling hobbies.

Cheers,


MC

Comment/Reply (w/o sign-up)

Thanks for the insight of Knoppix, I have 3.3, 3.4 and recently got 3.9 so I will also write a linux guide.

The thing with this program is, we do only have 20 bytes, which is not enough for our code.

What method I was going to suggest is known as egg/egghunt, we load the program in memory (our egg waiting to be hatched), our egghunt program finds this location (memory address for it) and we use the overflow to point to our program in which it will run the code inside our egg, now whether we try and return back into the program or just exit successfully is up to you.

I've also discovered some counter measures in Windows XP SP2, known as sandboxing as well as other techniques that don't apply to my processor, newer CPUs than P3 may have this protection, so you should probably know about that, I'm having a rough time overcoming this too, but I've asked a good mate of mine to help me with this now, since he's still doing exploit development (under Windows) and has methods to work around this, apparently he's going to let me in on a few 0 (zero) day exploits, not that I'm interested or anything

So give me time to write a guide, during this I may just write mini guides just to help you get ahead of my slow pace.


Cheers,


MC

Comment/Reply (w/o sign-up)

write a C++ program uses a system call to exectue anouther program, this is very similar to the UNIX way, somthing like a execve(NULL,"/bin/sh",NULL); and compile it statically.

then compile it, and dissasemble it with whatever the windows version of objdump is.

then you just need to tweak a few addresses, etc etc.

load the modified binary code into th buffer, (with as much NOP padding as possable) overflow the return address with a educated guess of what the address of the stack is + the address withing the stack that the buffer lives in. and if you guess right, the code will run, and whatever program you put in the shellcode will run.

The theory behind this is quite simple, but doing it requires a good knoledge of ELF binarys (or win32 for windows) and machine code.

ALSO, before i attmepted this challenge, i never noticed how different Intel assembly was to AMD assembly.

i compiled 3 different binary's to start with, just to look at the difference..

g++ -m64 -march=athlon -ggdb -O0 ./main.cpp -o Athlon64_debug_noOptimise.bin
g++ -m32 -march=athlonXP -ggdb -O0 ./main.cpp -o AthlonXP_32bit_debug_noOptimise.bin
g++ -m32 -march=pentium -ggdb -O0 ./main.cpp -o pentium_debug_noOptimise.bin

the biggest difference i noticed was how the different CPU's passed parameters to functions.

Comment/Reply (w/o sign-up)