Writing a Simple Buffer Overflow Exploit

so yesterday I showed you some pitfalls that can happen during exploit development and I promise you I will share a full exploit development walkthrough of this small example challenge today so grab this code from the link below and then use GCC to compile it in this way and yeah I guess it's a dangerous function you shouldn't use it ever to develop this exploit that would be fun to a bit more look like a real challenge so I'm using so ket here which you can install with apt-get install so cut so it will set up a TCP socket and listen on port 133 7 and the other settings are not that important but you specify an exit so something that it will execute when somebody connects to that port then I'm using sed buff just to disable the buffering of the in and outputs of that program otherwise you wouldn't see like the input and output that doesn't really matter and then we execute the binary this means we can use netcat node to connect to this port oh and I guess I accidentally entered the capital a so I have been blocked and was reported to authorities so obviously broken off but if you don't enter a capital a the application works and you can enter another input so just a quick reminder from yesterday's video there is the buffer overflow caused by the gates which writes data in this limited buffer but we also have a format string vulnerability here we can test for format strings by basically entering format characters and see that whenever this data is used and outputted printed again if it contains weird numbers so for example here I'm using percentage P to basically print the address or something and you can already see yep that output was not simply reflected back at those percentage P suddenly became addresses and numbers and in main we have a loop around this vulnerable code so this means in the first loop we can use the format vulnerability to leak values or addresses from the stack which we can then use to defeat a SLR basically we just leave some addresses and then we know where the stuff is in memory and then in the second loop iteration we then can trigger the buffer overflow now knowing where our status now the exploit I'm developing here is pretty lame but if you are interested in how actual good people are developing exploits and you like to watch that I really highly recommend to you set at whose youtube channel or color Svendsen he's organizing so called Pony races this is a live event where four people basically raised for an exploitation challenge and you can watch them simultaneously and that are - together with his colleague is commenting this whole thing so it's really really fascinating to see the approaches they take and who gets further faster who finds the back first and all that kind of stuff it's really really interesting and obviously also fun and recently said - also asked how I do you name your exploit scripts and then people were saying things like salted pie or extra pie amateurs so I suggested the superior AST dot pi or sometimes even ast one dot PSD - dot pie or asdasd dot pie depending on how many exploits you are writing that day so here's my AST dot pi exploit script that we will be using now so let's create a socket and connect to local host so let's also install the patent extension for Visual Studio code so our code connects to the server localhost and then attempts to receive up to 1024 bytes so it prints the Bell context so you know already that we can leak some addresses with percentage P but the question is what actually did we leak here where does this point to so there are basically two things you want to do now first is a quick idea of what the address is and then you want to know exactly what web points to so then we want to find the process idea of our process now these processes here are related to so cat this is the actual binary that is running so this is our PID just keep in mind we have executed so cat with root so this process runs as root so that's why we need sudo if you want to access the proc file system of this process and specifically we want to access maps to get the memory map now the first address that we leak is in seven FF seven five so let me just copy this here over there so now we have it here at the bottom so the first address here the first adver seems to point into Lipsy so if you would want to leak an address off let's see so basically they feed a SLR or flip seat so you know where does memory then the first address you could use that but we look for a stack address so the next value here is 7f fe4 so yeah the next address lays between this start and end address so yes this address here is from the stack now that we know the process ID we can also attach gdb to it and then we can specifically look at that address so I am examining 16 G X G stands for giant I believe that's the output format or for 64-bit and then we want it in hex okay so there is no value there at all we can also print a bit more but we don't find anything recognizable so it points somewhere on the stack it definitely helps you to basically defeat a SLR and you will able to find where the stack is in memory but it is like not a super convenient value it doesn't seem to point to anything useful for us so this address has a certain meaning and we want to figure out what that meaning is now it could be a good idea to always look at these things in a certain context and we attach to this program now at some point in time after we have done some input or so and we could now investigate the memory but memory changes during the execution of the program so it makes sense to think about the context you want to be and when you are investigating the memory and so generally a good idea is to kind of look at the state of the memory and the state of the stack and all that stuff doing your investigation and very critical points in time and this could for example be at the return before the buffer overflow basically you want to know how does the memory look like before I get to my shellcode or it could for example be just before or after triggering the format string vulnerability because there may be these values have meaning um so that's at the breakpoint at one of them I guess we can set the breakpoint at the return where we would trigger the buffer overflow just because we need that later anyway so here this assemble main so here we see the vulnerable printf we could break here or we could break at the return it's not likely as much happening after printf and that return but it's still important that this is kind of the context we want to look at those values so let's set a breakpoint at the return now we enter again our leak now this is also kind of interesting we could quickly compare I add the values are still the same so we know there are no weird side effects or so and so now we hit the return let's investigate where this address points to so now looking at this memory there's also zero I don't know there's some random data down here to be honest not quite sure where it points to but we also know that we should have data on the stack because of the buffer overflow and I don't see this data here yet but it's also difficult to see our data so maybe let's add a couple of recognizable characters to our input so let's continue let's do like xxx x then we leak our output and a couple of wires interesting see now the second value changed and look here this this is this this is our X so it leaked our X's here so you can see that the length of the input seems to influence what some of these values are so let's check out where it points not to and we still can't see here anything but maybe let's go a little bit back up and see what was before it and look at that and look at that we see our input these are our wise and and look where the two three bs so this address that we are leaking seems to point at the end of our input so let's test our theory so let's use a three percentage pea with a comma-separated so that should be one two three four five six seven eight characters now this leaked address should point at the end of that input string so again at this address is just zero but now let's go back eight bytes and here it is if you actually print this as a string examine string you can see that it indeed points at almost at the start I forgot the null byte at the end so actually we have to subtract nine and nine is the start of our string so now we can use this string as a leak and subtract nine from it to find the start so we sent that input and don't forget the newline we need to send you know that we pray enter the new line and then we try to receive the response cuz fYI sometimes the receive is too fast here and the server didn't actually send you the output yet in these kind of cases you just need to build a loop and basically program yourself a little read until so you keep receiving until you receive what you need so try it out there we go we get our league output and we get asked to enter the next payload so let's extract that value here by the way I'm using here Python tool just because doing this kind of exploit development is a little bit nicer in Python to Python 3 is a little bit annoying with the bite ASCII string conversion stuff so we can split the response at the commas Oh see here I executed at once and we didn't read fast enough and on the second try we it worked so maybe let's add here a quick loop so here just a quick while loop it's not a good solution it's it's still kind of ugly but basically we say please keep receiving until our contains a comma and this is also why I deliberately used commas here because I can easily then recognize them again at the output and we can easily split the string there so I was just thinking a step ahead when when I was planning my I format string so now that means the second value is our leek so the second element is a string obviously so we can't convert it to an integer we can use int and we say six the base is 16 so it's a hex number awesome now we have an integer now from the integer we can subtract nine now we have the start of our buffer and then we can also add here like this cool output that we leaked like the start of a buffer excellent so now we finish the leek now we want to focus on our buffer overflow and we still have to figure out how much padding do we need until we overwrite the return point on the stack to do that you can generate a unique pattern a non-repeating like unique pattern and you can get some tools to do this but you know I'm such a pro that I can just generate my own pattern so let's copy our amazing general the pattern and we can copy it in our test from earlier okay so output seemed to have stopped and now we received the segmentation fault okay so we basically have seen this before that's to stand the test that you should be doing okay we crashed here so what was this instructional this was to return okay so we should look at this deck oh this looks like values we have all written okay so we do have a buff overflow here so we know we want to know the offset now I'm printing at RSP here the string so the return try to pop this value from the stack and then I said our IP to it and that's where the second fault was triggered this means also the first eight characters here are the return pointer on the stack so these values here are the first eight here let's just copy a couple of these bytes we go in here we search for it perfect we find it here remove all the rest at the end and so now how long is this you actually don't see it unfortunately it's like it's like right right there in the blue bar here right there it says two six four selected I'm just calling this the padding now let's create a payload so the super standard payload for these kind of basic exploitation challenges as always you have two padding to fill up the buffer until you have the return point on the stack then I'm using here a variable our IP and this is where we can set our IP to plus and then for example some shell code and basically we want to set our IP to point into our shell code so we need the variable already so our IP we have to set it to the shell code here our IP is definitely at the start of the buffer the address that we leaked and then calculated with the minus nine offset points at the start of our buffer so this basically points here at padding this means if we want to point this address now to the shell code we can simply add the length of the padding now it should point here basically where our IP starts itself and then we move it eight forward to compensate for our IP itself and now we should be at the shell code and now just a test shell code before we get real shell code and just sending 64 CCS this was also covered in previous hacks ember episode which is also an hour part of the a binary exploitation playlist this is the opcode for breakpoints so we showed you know see see what that does and then we simply sent this alright now another small debugging tip it's always good to test these things while you are attached to the process with gdb but the problem is right now you know we can't like just simply launch gdb because we use this network thing with so kids so we need to figure out the process IV of whatever so cat is spawning and so that we can attach with gdb then to this process and then run our exploit so a simple tip is just to basically pause your exploit script so I'm using here raw input which then basically waits for somebody to provide input to this Python script basically hitting Enter and only then it starts the the exploit process actually let's put it after the leak so we can see that the leak was successful all right let's run it okay so we leaked the buffer and now we asked do we want to exploit it now we have all the time in the world to check for the process again these are the socket processes this is the one we are interested in PID of calf would also give you the correct one now you might have multiple attempts at trying this out so maybe you want to do like gdb a period of calf and wean sudo all right so let's hit continue and now let's trigger the exploit ah I'm an idiot okay so this is an integer r.i.p i completely forgot that now we need to convert this integer to a raw byte string that we can then send over for that of us of course I'm using Python struct again and please check out here the format characters that exist in other of the older videos that were 32-bit binary we were using capital I for this conversion but that is defined to have the size of 4 bytes because that's a 32-bit integer but instead of 32-bit we now have 64-bit addresses so we need eight bytes and so in this case we want to use here something that has eight by and here's an unsigned version of that so it's capital Q so we pack this integer here into a 64 bit or 8 byte raw byte string let's try this again we execute this it's attached to it again there we go we continue now I don't know what it did we can look here yeah look at this we triggered a breakpoint trap sick trap you know what this means this means this exploit worked first try we chose the correct address to overwrite the return point on the stack and we were successfully pointing it to the start of our shellcode where we have placed the cccc which is which triggered and this output here we can look here at our IP and you can see here our CCC outputs so perfect now we can place the out just our shortcode and we should get a show right so I'm going here just on shell storm so let's look for Linux 64-bit there we go and we want something like Venus H also let's have a look at this one here looks good so this should just execute Ben Sh so there we go we commented out our previous test shellcode and replaced it with our new shortcode and then I've also added this snippet here which I think I've used before in some CTF write-ups and I think I've even mentioned where I got this from I learned this trick from jihad live CTF way before I even started my channel basically the videos that motivated me to stop my channel anyway you basically used the Talmud clip to create an interactive shell long story short when you are able to spawn for example a shell you can then keep still interacting with the socket by using your keyboard anyway and let's execute this anyway let's execute this dig start off buffer we get some weird output let's see if it worked and we have root so our shell code could execute it first try no debugging whatsoever BAM anyway now I need to do the change for the pitfall that I mentioned in the yesterday's video so in this case I want to place the shell code right before our IP and now we need to obviously account for the length of shellcodes and we need to remove this so we can simply use this comprehension here so we start from the start of the padding until and now from the back we subtract the length of the shellcode and now the petting should still be fine and we should still hit our IP for test purposes to make it easier let me also add a CC at the start of the payload this should help us testing it and then we should also recalculate our IP because we are not pointing here after our IP anymore now we need to point here at the start of our short code which means we need to also subtract again 8 for the our IP and then subtract for the shellcode so let's move this down here I'm just visualized I keep the whole calculation so this right now points after our IP this means if we want to point here this out of the shellcode we subtract 8 now we are before the our IP and now we subtract the length of shellcode and we should be at the start of our short code all right and and then let's run it so now it's asking for our input basically wants to hit us enter now we have time to attach to the process and let's hope this works we got a sick trap trace breakpoint this means it executed the CC at the start of our shellcode so let's have a quick look at that let's step slowly forward and see if our shellcode works segmentation fault alright and now we basically come to the part that you have seen yesterday where this was the setup for the weird pitfall that you will find yourself in and then you need to debug it and figure it out so if you haven't seen yesterday's video check that out [Music] you [Music]

Channel: LiveOverflow

Views: 144,707

Keywords: Live Overflow, liveoverflow, hacking tutorial, how to hack, exploit tutorial, buffer overflow, gdb, python, pwn, pwnable, basic buffer overflow, binary exploitation, memory corruption, exploit development, writing exploit, exploiting, shellcode, shellstorm, /bin/sh, return pointer, overwrite stack, pattern generation

Id: oS2O75H57qU

Length: 19min 41sec (1181 seconds)

Published: Tue Dec 17 2019