In this post, we are going to take a look at another way to defeat DEP protection in the Linux binary. As you know in Linux, DEP used for making the stack to be non-executable by this approach we cannot insert a shellcode inside the stack and reserve for another alternative such as ret2libc. Let's say that we still need to execute shellcode, so how the hell that we able to make the stack become executable again?
simple there is a technique called ret2mprotect() that are able to satisfy our need and it is very simple to implement.
but before we go into the POC let's try to understand the approach of ret2mprotect().
Like ret2libc(), ret2mprotect() also needs to overwrite the EIP of the program to redirect the program execution into a certain function but we don't redirect it to system() function but to mprotect() function.
Go to your terminal and type "man mprotect"
this function lets us change the protection that is set into a specific region of memory we can use this to make the stack region to be executable again.
1st param => start of the stack region
2nd param => how big is the size of the region
3rd param => permission that you want to set, we need to set it to 0x7
Let's say we want to pwn this following piece of code:
#include <stdio.h>
int bof();
int main(){
bof();
return 0;
}
int bof() {
char buffer[128];
gets(buffer);
return 0;
}
compile this with the following specification:
~# gcc -m32 -fno-stack-protector -no-pie <name of the file>
and turn off the ASLR, since we only care about the DEP right now:
~# echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
Load it to gdb and make sure the NX protection is on:
(ignore the name of the file)
Let's find out how many offsets we need to overwrite the EIP. Create a long pattern and put it into the program
Ok, so we need at least 140 bytes of offset to overwrite the EIP. Next is to search the location of the mprotect() function and stack region
ok so from the information we got from this two figure we can set our param of mprotect like this:
1st param => 0xffffe000
2nd param => 0xffffe000 - 0xfffdd000 (0x21000)
3rd param => 0x7 (number for make it executable)
now lets try to construct a python script that will do exploitation:
I choose the shellcode location to be before overwriting the EIP which is 0xffffcd80 and don't forget to put bunch of nops before the shellcode to increase the chance of hitting the shellcode.
Also, I create the shellcode by myself and It's up to you want to get it from the shellcode website or not
Let's run the payload at the gdb, to see if our implementation is correct or not
If you trace the call of the payload here you can see that we actually change the permission of the stack region
If you continue the execution it will spawn a shell
Run the exploit again without gdb and you will get a 90% chance that the exploit will not work since the stack might change and not as exactly as what we saw in the GDB. To overcome we need to analyze the core file, load it to gdb and analyze it.
to enable core dump you need to do a view adjustment with your host.
~# ulimit -c unlimited
(become root and type:)
~# echo "core" > /proc/sys/kernel/core_pattern
ok so run the exploit again and this time it will have a core file that contains a crash
take a look at the warning before the "gdb-peda" it shows where the error occurred and when we look at the stack we can see that the location that we put into our script is missed quite far from our shellcode
so we need to adjust the shellcode location to jump to so I'm just gonna pick the address 0xffffcddc since that is in the middle of nops
update the script like the above figure and run the exploit with cat utility to keep open the stdin so our shell is not close immediately.
WALAAAA! we defeat the NX protection :)
That's all folks! hope you enjoy this post
references:
https://reboare.github.io/hackthebox/calamity.html
Comments
Post a Comment