Damn Exploitable Android App - Abusing Info Leaks to bypass ASLR

Before diving into the ASLR bypass technique, it's essential to grasp the concept of format string vulnerabilities. A format string vulnerability arises when a program uses user-supplied input as a format string parameter for functions like printf, sprintf, fprintf, etc., without proper validation. This can lead to unintended data leaks and even remote code execution.

Examining the snprintf function, the parameters have been assigned to local variables spanning from 'param_3' to 'local_14'. Eventually, 'local_14' is assigned to 'pcVar1', which inadvertently results in a memory leak due to a format string vulnerability.

Please follow our Damn Exploitable Android App - Lab Setup article for the lab step-up click here

Prior to attempting exploitation, it is crucial to verify that the target application you intend to analyse is currently running.

Forward the vulnerable service to your Virtual machine.

By analysing the leaked data using VVMap in GDB, you will be able to determine the library to which the addresses belong.

To locate the address within the libraries, which are usually randomised, you can utilize the 'vmmap' command in GDB. By doing so, you can identify the library associated with the leaked address and obtain its base address. Subsequently, you can calculate the offset using the leaked address.

Since the remote target addresses are randomized by ASLR (Address Space Layout Randomization), as an attacker to locate data and execute code become very difficult. To bypass ASLR we can use "memory leaks/info leaks". These small leaks of memory data can help us to calculate the base addresses of important libraries or memory pages of a remote target and bypass ASLR.  

The main goal typically is to find and the base address of libc.so library which contains the stand C library with all necessary function to build our exploit, like  the "system" function call are in this library. In some cases, we need an address of a memory page where the data we send to the target is located, for example a Stack or Heap address. We can use the same technique to find the memory page base. 

The reason we can calculate addresses is because libraries library have a fixed size for a given version. This allows us to calculate the base address of libraries as long as we can leak a single address which is in the address range of the library.

The image below shows in a simplified way how to calculate the offset between the leaked address and the actual base address. Using this offset we can know always find the base address even if the addresses are randomized.

In the image we can see the libc base:
Libc Base = 0x0000000000100

To find the offset or better said the distance between our leaked address and Libc Base we can subtract image base from leaked_address.

offset = leaked_address – image base

offset = leaked_address – image base

Now that we know the offset, we can always find the base address by subtracting the offset from our leaked address which will always gives us the image base again. 

libcbase = leaked_address - offset
0x000000000100 = 0x000000000700 - 0x000000000600

Since the data we send to the target is located on the stack,  we will need to find the remote target stack address. This will require us to leak a stack address and find the stack base. This will allow us to store useful payloads in memory and get pointers back to them. This will be useful when we call "system" with our chosen payload.

Put a breakpoint on snprintf function. 

Connect to the application and send %x.

nc 127.0.0.1 6000

Observe that our breakpoint is hit in gdb

We can now dump the stack and find use an address that is in range of our current stack address.

Observe the 25th position contains an address which look to be in the range of our stack.

Verify the address's validity and confirm that it belongs to the stack by utilizing the 'vmmap' command in GDB to inspect its associated memory mapping.

Since we know that the 25th position contains our desired value to be leaked we can use exact leak with position specifier and to leak the correct value with need to add +1 with the position.

Verify the leaked address by running vmmap against the address

Next, we will analyze the stack to identify the libc address. We will need a libc to execute the "system" function in libc. 

This involves dumping the stack and examining its contents to locate the relevant libc address.

We can now search for the address that is in range of libc by using the first 3 digits the address to search through our stack dump. 

There will be multiple hits, during the article we choose the last one in the search list.

Verify to see if the address belongs to libc by executing vmmap against the address in gdb

Now, we must determine the position to leak the libc address. To calculate this position, you can use the following formula.

0x9B400534 - 0x9b400018 = 0x51C

We can now add that to our exploit. 

Execute the exploit and observe the leaked addresses.

At this stage, our next step is to calculate the offset for the stack top. We will use the techniques learned previously to find the libc base.

To find the offset to our desired stack location we can substract stack_top from lead_stack_address.

To discover the base address of the libc library, you must execute the command 'vmmap libc.so' within GDB. This will provide you with the necessary information to proceed with your analysis.

Upon executing the exploit, we can observe the calculated stack top and libc base, which are crucial pieces of information for completing our exploit.

The combination of format string vulnerabilities and ASLR bypass can be a powerful technique for attackers to compromise systems and exfiltrate sensitive information. By understanding these concepts and staying vigilant against potential vulnerabilities, software developers and security professionals can work together to fortify their systems against such attacks.