Identifying another exploit mitigation and find bypass. stack0: part 2 - bin 0x22

Key Takeaways

you should now be familiar with stack level Zero from protostar and especially our quick look at what happens when you compile this code on a modern system specifically with the St cookies in this video I want to develop a working exploit for it and believe me there are a few mountains we have to overcome let's get everybody quickly on track we have a simple buffer overflow vulnerability originally the goal was to overflow into another variable to change the outcome of an if case but this is not possible anymore because the buffer is now placed after the variable not before so to execute the if case we want we could maybe overflow the return point on the stack and simply redirect the code execution there but an issue that we face is the St cookie which contains three random bytes that are checked before the function returns so in in order to overflow the return pointer we would have to guess the cookie this means we have to write an exploit which executes the target over and over again millions of times always guessing a that cookie and eventually we should get lucky but before we write that code let's first develop the exploit as if we know the cookie value this input really must be correct in order for it to work once we gets the correct cookie value so we have to debug this heavily let's start by opening the binary in GDB with pay extension which makes it look nicer and let's just enter a lot of characters in order to observe what happens oops stack smashing detected we obviously want to ignore that for now so let's set a breakpoint just before it would continue to stack check fail and then set EIP to where it would have jumped to if the cookie was correct with a simple commands directive we can automate this every time this break point is hit and then continue segmentation fault that's what we would expect awesome oh segmentation fault at the return not a stack fault because we redirected code execution to faulty memory look at the stack register ESP points to invalid memory so when the return instruction wants to look up the return point on the deck it tries to follow where ESP points to and that is obviously accessing invalid memory then Dam how did we override and modify the stack pointer let's look again at the disassembly down here just before the return so value referenced by the base pointer so value on the stack is moved into ECX and then EC xus Force calculated and that becomes the new stack pointer and when we look at the beginning of this function we can see that the stack pointer minus 4 is stored in ECX and pushed onto the St de so the stack pointer is also saved on the stack I think that's another mitigation attempt because before we are able to control the return pointer we first have to control the stack pointer at first this doesn't seem to be an issue because this just means we have to write a valid stack pointer and point it into the buff we control and then the return will take the return pointer we control and the buff our ESP points to when we win but the issue is this modern system also has now a aslr we can see that if we reenable aslr in the debugger and run it a few times observe the ESP value it's always different I admit it's not fully random but it's more bytes we would have to guess and to hit the cookie and the Val stack address is starting to look really bad let's say we would know the base memory of the stick would that help us there's even more here let's rerun the program again and this time let's see where ESP points to and compare it to where the STI actually starts in memory and when you do this a few times you can quickly see that ESP varies quite a lot from where the stti really starts in fact there's a huge gap with a random size of just zeros between the start of the stck we use in the code where ESP points to and the environment variables that are actually the beginning of the stack memory area I think this is another way to randomize values because aslr would only randomize the upper parts of an address and this way also the lower bites become unpredictable the game of exploitation has clearly changed there are more hurdles so does this mean now it's game over it's not exploitable anymore we can't do it with a single input overflow well there is a way but we have to get creative it's not as easy anymore okay so so we know there is a cookie on the stick and we believe it's brot forceable so let's assume we found the correct cookie how do we go from there we know that a valid deck pointer is stored after the cookie right the value of ESP was saved at the beginning and restored here at the end again which means we can abuse that we don't have to override the whole pointer what if it just corrupt the first spite so the lowest part of the address which means that the stack point pointer stays valid but suddenly points into slightly different stack memory and maybe we can make it slightly Point into the buffer we control which is just a bit lower than the stored ESP value here so then we restore this slightly off value return can now follow the address as it points into valid stack memory and take the address there to return into and if it points into our buffer now we can control where we want to return to and we could return into the if case that prints our goal we can achieve that by writing enough data to the buffer so that we fill up just short of the stored stack pointer and because strings end with a zero byte in C a null bite will be written to the lowest part of the stor E P value thus make it a bit smaller and when we are lucky it points into our buffer let's figure out the length so when we run it with the long input we see that ESP got overwritten with ssss one bite is four lower than the others thus became an O which was caused by the e xus 4 so this means we want to stop right before that and when we run it now we see that ESP ends now in FC so it worked because we predicted the lowest part in this deck is overwritten with zero and because of ECX - 4 so 0 - 4 we end up with FC but as you can see we didn't get lucky ESP points not into our buffer so let's rerun it a few times and do the same and at some point we will get lucky and now ESP points to our buffer and we now return we actually return into 404d 44d which is mmmm it worked actually the randomization of the zero padding on this deck makes this work because at some point the lowest randomized value of the address will be just right so that the zero is the right amount of change so ESP points into our buffer but you also see it's not 100% reliable we have to guess the cookie correct and then hope that the ESP randomization is also nice to us but that's fairly common so I hope that it's common enough to still make it feasible so now all that we have to do is put it together let's write a quick python script we import stru to convert the address to a 4 byte string the lampda help bar function for that and then we simply make our exploit string fill the buffer with mostly the add we want to return to and we hope we can make ESP point2 into this area and then comes the cookie value which we later have to write some brute forcing Logic for after that comes the four more bytes and that's it then we print it looks good you see the raw bites are output with hex dump so we write it to a fire and let's set a breakpoint at the cookie check to make sure that the cookie is in the right place and then we can use the file as input in GDB first breakpoint was the cookie check and we can see we all wrote the cookie with cook now when I press continue the other breakpoint from way before will hit and skip the cookie check and reach a return oh and look at that we got lucky with ESP and ESP actually points into our buffer when we now continue we return into the if case that prints the modified string and there it is amazing so the exploit theore ically works all that is left is the cookie brute forcing unfortunately that deserves its own episode again it's just programming but doing it you can learn a lot about Linux and I don't want to squeeze it in here again try to do that part yourself you could really learn a lot [Music]