Frida exploring the exploitation of Heap algorithms
OTUS expert – Alexander Kolesnikov shared with us a useful article, which he wrote specifically for the students of the course Reverse-Engineering. Basic
We invite you see the demo day of the course, within which our teachers spoke in detail about the course program and answered questions.
Reverse engineering to get an algorithm is always tempting, but reverse engineering to create something new is even cooler. In this article we will try to use the tool Frida, in order to make the process of analyzing a vulnerable application a little easier and create an exploit for this application a little easier.
All examples in the article will deal with heap attacks in the Linux operating system, so we reserve ourselves with patience and popcorn.
Heap
Heap or heap is an area of memory that is used to dynamically allocate memory for large objects. Usually, this area is accessed through a function call malloc… The function deals with memory allocation requests and essentially runs the target of algorithms that provide memory in the most optimal way and in the most optimal amount. Memory algorithms are modified with each new version of the kernel, so there is no single algorithm for actions to allocate memory.
For quite a long time, the study of the heap and the algorithms for the operation of its functionality were scattered across many articles. Each of the approaches directly depended on the version of the operating system or software. Usually, the main criterion for using a particular operating technique is the version of libc that the application uses. The following attacks exist:
heap grooming attack
fastbin attack
tcache attack
unlink
largebin
unsortedbin attack
The list is far from complete and is presented here to demonstrate how many heap attacks exist that can be exploited during exploitation of vulnerabilities. All of these attacks are based on studying the behavior of memory allocation algorithms on the heap. In fact, all attacks are simply the supply of values for the algorithm, which will allow you to find out in front of where and what will be stored in memory. As for the limitations of the applicability of attacks, as mentioned above, you need to look at the libc version. How to correlate attacks and versions – we will leave this exercise for independent study of the readers.
Frida
In the frida toolbox, we need at least 2 tools: frida-trace and MemoryMonitor. We will use them as needed, in most cases one tool will be enough. We will conduct the study first using examples that will demonstrate the operation of an attack or a mechanism, and then we will solve a task from already completed CTFs.
Heap grooming
An attack that works with at least libc 2.23. The attack consists in the fact that you can allocate the same pieces of memory, free them, and when similar pieces are requested, they will be provided by the heap in reverse order. The limitation of this attack is that the number of these pieces is limited. In our buildings, this number does not exceed 7. For a demo of this technique, we will use the following code:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
unsigned long int *mem0, *mem1, *mem2;
mem0 = malloc(0x10);
mem1 = malloc(0x10);
mem2 = malloc(0x10);
printf("Allocated memory on:nptr0: %pnptr1: %pnptr2: %pnn", mem0, mem1, mem2);
free(mem0);
free(mem1);
free(mem2);
printf("mem0 after free and alloc again: %pn", malloc(0x10));
printf("mem1 after free and alloc again: %pn", malloc(0x10));
printf("mem2 after free and alloc again: %pnn", malloc(0x10));
}No additional options are required to compile the code. And so the output from the compiled version will be as follows:
In the test case, of course, everything is super, data by addresses are displayed and we can see them, but what if the application does not printf? Let’s try to make such printf at the expense frida-trace… Let’s run the command:
Frida-trace -f test -i “malloc”
After the first run, you need to modify handler… It is located in the directory “handlers”From where the frida-trace tool was launched. And the malloc.js file needs in the section OnLeave write a line as shown on the screen:
Now to the real problem. As an example, we will use the pico CTF task “Are you root”. Let’s launch the investigated application via frida-trace:
We did not open the application in the disassembler, but we can already say that a heap is used for the login function. Judging by the values that are allocated on the heap, the values are stored sequentially login; Auth level… Why is that? After entering the login details, we see a sequential call to malloc with sizes 0x10 and 0x7. Since the minimum amount of data that is allocated on the heap can be more, the second value is placed in a piece of size 0x10, just the rest of the space will not contain useful data, as a result we have 2 cells – with addresses 0x1514eb0 and 0x1514ed0. Writing the rest of the exploit code becomes trivial.
TCACHE
A feature of this attack is the fact that on the heap, all parts of the memory that were freed fall into a special list tcachewhich saves them for reuse. The attack assumes that if we release the data and it gets into tcache, then in the future we can use the address from tcache for modifications:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
unsigned long int *mem0, *mem1;
int target;
mem0 = malloc(0x10);
mem1 = malloc(0x10);
target = 0xdead;
printf("mem0: %pn", mem0);
printf("mem1: %pn", mem1);
printf("int: %pnn", &target);
free(mem0);
free(mem1);
printf("Next pointer for mem1: %pnn", (unsigned long int *)mem1);
*mem1 = (unsigned long int)⌖
printf("Next pointer for mem1: %pnn", (unsigned long int )mem1);
printf("Malloc Allocated: %pnn", malloc(0x10));
printf("Malloc Allocated: %pnn", malloc(0x10));
}Let’s compile and see what frida-trace can show with the modifications we made last time:
Despite the seeming unreality of the attack, we see that it is really possible to allocate memory at the address that is used to store the value of the variable on the stack. This is evidenced by the last address that was returned by the function malloc… It is only worth mentioning that such tricks are possible only if the application contains a Use-After-Free vulnerability. Let’s try to study the task with Plaid CTF “cpp”. Let’s modify the script for tracing:
Now you can collect data about the part of the code that calls the function malloc… After that, we see the following output:
Now it will be easier to determine where the function is called from and where there is a potential vulnerability.
conclusions
Writing exploits is always the hard way. Sometimes reverse engineering research in this area can be compared to observing dynamic processes from a photograph. The photo is not always taken on time, some data becomes outdated and this slows down the study. In this article, we tried to improve the method by creating animation.
Learn more about the course “Reverse-Engineering. Basic”
Read more:
No secrets or Frida for Windows
