Previously in the arm exploitation series, we take a look at how we can perform buffer overflow and format string attack in ARM binary, both of them prove to be powerful enough to take control of program execution if it correctly utilizes, furthermore it can also bypass anti-exploit mechanism.
But both of the attack methods are conducted in stack region of memory and today lets try to explore the other attack mechanism in ARM binary which is heap exploit.
I already introduced how to get a start in the heap exploitation binary, in this post and this post so I will not cover it again. This post is meant to give an idea of how heap exploitation happens in arm binary and how we can leverage this exploit to be able to take control of the program workflow and drop a shell.
For the POC, I will take the source code from protostar heap0 challenge, compiled it in raspberry pi qemu and try to exploit it
source: https://exploit.education/protostar/heap-zero/
just like in the protostar challenge we will try to turn off all the anti-exploit mechanisms. We will try to bypass the anti-exploit mechanism in heap exploit later in the next post, from now on let's try to make it simple so you get the concept first.
from the figure below, let's try to put three breakpoints in the program the first two breakpoints will stop at the call function of malloc() in the program whereas the third one will stop at the strcpy() function in the program.
The first breakpoint will take use to the first malloc which is used to reserved memory in the heap for "data" struct which contains the variable "name" with type string
we can see that the first and only parameter was passed with value 0x40(equivalent to 64 in decimal) that act as a size reservation in heap
Once the heap finish allocating the memory it will store the return value which is the location of the allocated memory in register R0
You can check the result by typing "vmmap" and dump the memory location of the heap. Same as the second breakpoint which is the second malloc for allocating "fp" structure variable, the first parameter used to define how big is the memory allocation in the heap
now on to the third breakpoint, we can see that the strcpy function used to copy the value of our supplied argument and stored it to the heap.
the first param (R0) will be the destination where the first malloc happen and the second param (R1) will be the source which is our input
once it has done try to check the heap memory now, we can see it know contain our input and from we know a strcpy function doesn't have a bound limitation in the input with this we can overflow the heap memory and take control of the execution.
how we can take control of the execution? since there are not instruction pointer in the heap memory
notice that before strcpy function there is:
f->fp = nowinner; this is used to store the nowinner location to fp struct variable in the heap we can see the program put it at (0x21050) and then the program called it again after the strcpy function
f->fp();
so it becomes clear all we need to do is to overwrite the location of nowinner() function in the heap memory and replace it with our new location.
I get it!
most of you will probably just gonna overwrite the nowinner function value in the heap memory with the winner() function location. Well i'm not saying is wrong but we are hacker lets try to do more than just changing the direction of the program instruction.
let's try to combine shellcode so by the end of the exploit we got a shell and take control of the program :)
first, let's try to determine how much we need to overwrite the function call in heap.
okay so we need 0x48(72) of bytes to overwrite the address and we are going to redirect the execution to the beginning of our input which is located in 0x2100c and you don't have to worry about with ASLR since it will now affect memory location in heap.
the first few bytes of our input will contain a shellcode and rest will be just padding to overwrite the function address. Now we can create python script to generate our payload like this:
the shellcode I used will be from the previous post that I make couple of weeks ago.
run the exploit as the argument of the program and as you can see we got shell :), cool!
the first figure shows you the heap condition after the payload is inserted to the heap memory we can see that at 0x21050 we overwrite it with a new address which is pointing to the beginning of our shellcode and the second figure show the result of the exploit if it runs outside the GDB and apparently it still works
so that's all folks I hope you have a great weekend and see you around at the next post.
Comments
Post a Comment