Let’s move on to the next level of Protostar. This is similar to the previous challenge.
Let’s take a look at the code and see what differences are present.
So same stuff, but a different restriction on the return address… interesting. Let’s take a look at what the address points to.
As we can see from the map above, we’re restricted from returning to libc. This is apparent from the “0xb00000000” check in the C code.
So how can we counter this? After digging a bit, I came across ret2code. Basically you make use of addresses of the binary itself.
From the map above it’s clear that we can do so. But what do we do? That is the question. From the previous write up we know that we can
fake a stack frame and gain a root shell. Can we do that here somehow?
It is possible only if we can evade the check. If we do evade the check we can then reuse our ret2libc attack. Makes sense.
One way could be to immediately return from the function to completely avoid the check. This seems like a viable strategy.
There are many such ROP chains(of instructions) which can be used to craft our exploits. These instructions are also known as
ROP gadgets(pretty cool eh?).
Here’s what a standard calling convention looks like taken from here.:
The instructions we’re particularly interested in are the “pop x” and “ret” at the end of the above section.
Using those two instructions we can exit from a fucntion. Thinking of it we don’t even need the “pop x”.
This simplifies our task. If we did have to use “pop” to restore the previous stack frame(which is not required in this case).
That’s why a “ret” is sufficient.
Let’s get started, first let’s find the IP offset. Using our trustworthy pattern…
So we know our padding is 80 bytes. Now lets get the address of ret from the binary…
Let’s make use of the first address. Now we need the base address of libc which we have from the above proc map.
So that’s at “0xb7e97000”. Now let’s get the addresses of system and exit.
Notice how the functions are at within the restricted addresses. But this doesn’t matter since we’re avoiding the check.
That’s why our ret2libc attack works again. One final thing we require is the shell string, which we can get the same way we did last time.
Keep in mind that this is the offset and not the location of the shell string, we’ll have to add this offset to libc’s address to get the actual
address. Using all this, let’s craft our exploit.
A quick and diry exploit, nothing fancy. Let’s run it…
Easy peasy. Those are all of the stack exploits. If you’ve come so far, then good job, you now have basic understanding of why bufferoverflows are bad.
A word of caution…these techniques dont work anymore…at least not this easily. You have protections like DEP and ASLR which are put in place to prevent these kinds of attacks.
P.S.: If you like this blog please do feel free to share it with your friends :).