The Heap: How to exploit a Heap Overflow - bin 0x15

Key Takeaways

in the last video we learned some Basics about how the Heap works and now we want to apply this to Heap level one from exploit exercises protostar to solve it actually I want to try something we do some role playing let's first be the security researcher who wants to find a bug to exploit in this binary afterwards we play developer trying to understand the exploit to fix the issue so we put put on our black hoodie and get started first we open the binary Heap one in GDB and execute it we get a sec fault and it also shows us that the SEC fault was caused by string copy because it tried to copy a string from the address zero to this other address here and zero is obviously not valid memory so it crashes we know how Linux binaries work so we make an educated guess that this application might require some input and we try the arguments run with a AAA again another sick fault but the attentive viewer will notice that the address is now different so this is a different string copy which again can't copy from address zero so we guess that it requires another argument and this time the program runs through without errors now we try to find a bug so the simplest thing to do is we just throw some long inputs at the program and see if something happens so for the first argument I choose to do a pattern with letters and for the second argument I do numbers just so I could identify them if something would occur we run that and we get a different SEC fa again because of string copy but this time the destination address looks invalid not the source address it tried to copy the string with the numbers which we know is the second argument to the address 4 64646 which is the hex code for fffff so whatever happened we somehow overrode an address that is used as a destination of string copy and this means we can now use the first argument to fully control where we want to write and we can fully choose what to write with the second argument now we have a lot of freedom what we can overwrite for example we can overwrite the return point on the stack to reir code execution or we can overwrite an entry of the global offset table which I explained in a previous video to achieve the same let's do the lot one it's usually more reliable than the stack which likes to move around a lot so let's check what kind of function is called after the evil string copy we can peek into the source code and see that there's a print F and we could assume that we want to write print F on the global offet table but that is deceiving that's not the case let's better stick to the assembly first of all we have to find the location from where we were calling the string copy we can use back trays for that which will look at the stack in the St return pointers to figure out where we are as a side note if you found a back that smashes the stack then the back Trace can not make much sense of it anymore so it doesn't always work and here we can see that currently we are in string copy but we were coming from this address so let's set the disassembly flavor to say Intel syntax and disassemble this address this will now disassemble the whole function this address belongs to our address ended in 5A so we are here after the string copy and as you can see there is a call to puts next which is by the way not print if like in the source code that's because the compiler replaced the printer with puts for optimization reasons okay so let's overwrite the global offset table entry for puts as shown in the Go video we can figure out the address of puts by first disassembling the function trampoline and the procedure linkage table which would now jump to an address stored at this address so this means this is the address of the puts Global offset table entry so this is the target we want to write to thus we place it in the first argument GDB run but we use back tis in the first argument to execute bin Echo as you know Echo simply outputs whatever you pass to this arguments and we can use that to get characters with hex values we can't type for example the hex value 8 so Echo minus NE minus n because we don't want that Echo plac a new line at the end of the output and and minus E because we want Echo to convert hex escaped numbers into raw characters just to make sure everything works we Echo the whole test string up to the fs again now Echo inside the back text Will execute and the output of that will be placed inside of the quotes as the first argument and when we run this we get the same SE fold as before so all is fine next step is obviously to replace these FS with the address of the puts Global offset table entry and when we now run it we get a sec fold somewhere else this time because of 303330 which is asky 400 and when we look at the registers with info registers we can see that we successfully got control of EIP which means we can now redirect code anywhere we want in this case we want to call winner winner has this address here so we place that into the second ARG ment instead of ar2 but using Echo and back Texs we execute it and we get winner which also works great outside of GDB in summary we can say this we identified a bug by guessing and playing around with it through GDB we learned that somehow we can control the destination of a string copy and we learned we even control what we want to copy and we abuse that to overwrite the function address of puts to redirect code execution to the winner function all without knowing why this even happened and not even knowing that the he was involved at all being a good security researcher we create a write up an advisory for this providing our proof of concept exploit as well as some additional information that might help the developer now let's change sides and become the developer we take off our hoodie and we put on our gray hoodie because that's what developers wear so we just got this email from this dude who found a bu in our program he even provided a proof of concept exploit with it now we want to figure out why and how this happened so we can fix it in the advisory it says that it has to do something with string copy so we read the manual about string copy and have this oh moment when we realize we didn't even read the documentation that would have told us what a bad idea that was so now we could fix that for example using string and copy or use Ester to check the length before we copy it and then exit but because we are a good developer we try to learn from this advisory and try to understand how the exploit exactly works in the last video the Heap malog introduction video we already thought about how the Heap should look like from this program so let's see how it looks in reality to do this let's set a breakpoint after each MOG and string copy we disassemble Main and look for all those calls and that break points afterwards then we run it with the proof of concept exploit arguments and we hit the first breakpoint so now the first Melo happened and the result of Mello is in E so e contains the address on the Heap where we have enough space for the internet struct i1 and we can look at this address and we can see it's simply zero with info prop mappings we can see the memory segments and there's also the Heap and we can have a look at that oh maybe it's a good idea to add this Heap output as a GDB hook as well so we see it automatically at each break point so Define hook stop x64 word en Hax uh the address and so if we now continue we should set the priority of i1 to1 and then Malo for the name let's have a closer look at the Heap so as you learned the i1 able points here so this is where the struct starts and you can see the first attribute which is the priority set to one and before that we have the Heap metadata the chunk header which contains the length of this chunk including the last bit set to one which means that the previous block is not free it's in use and what we see is what we expected we see here two allocate chunks for eight bytes including the headers they are 16 bytes another cool thing we can do is Define a variable i1 in GDB and set it to the address of this object and we can even add the type of this variable with struct internet and now we can print this variable i1 and GDB can display us the attributes priority and name and we can see that priority is one and name is still zero because we have allocated memory for the name but not yet assigned it to the i1 attribute name if we continue to the next breakpoint the address of the name got assigned and the I2 object got allocated and the result of Malo is again an eex that's the address of the I2 object so we can also Define the variable I2 in GDB and we print that we can see that it's still empty now if we continue the priority of I2 should be set to two which we can verify by looking at the Heap memory as well when we print the I2 object and also all of our mogs are done now and if we compare that what we expected in the earlier video we can see that it fits perfectly there's only one thing we didn't talk about yet and that's this big value after all the chunks at the end well this area down here is all free memory and in exploitation terms this is often referred to as the Wilderness this number is the remaining size of the Heap this whole thing is basically a huge Heap chunk and that number is the length and a while ago I made a three-part video about The cookbook Challenge from a CTF and that exploit abuses this number to redirect code execution it's super awesome you should watch it anyway right now the name of i1 is still Mt string but this is about to change with the next breakpoint because we are about to execute the first string copy which copies this super long first argument continue the first thing we notice is here in the Heap memory those SK characters appear and it looks like they have overwritten a lot of stuff on the Heap what earlier was supposed to be the chunk had a metadata like the size is now 4444 now let's have a look at the objects i1 and I2 so i1 looks fine i1 has still Priority One and the name with the string that was passed to it how about I2 ah that looks priority is now a super huge number in fact that's just 454545 in decimal that's the ease and the address where the name is stored is not pointing somewhere completely else and now the next string copy will take I2 name which is pointing to some bad memory and try to copy there the second argument really freaking awesome so this challenge showed one aspect of he exploits it doesn't attack the Heap algorithm itself it attacks the application which uses objects on the Heap that we can modify because we have overwritten stuff in those modified objects then bend the execution flow cool huh [Music] [Applause] [Music]