Damn Exploitable Android App - Abusing Info Leaks to bypass ASLR

In this blog post we will explore a clever technique that leverages format string vulnerabilities to bypass ASLR by leaking crucial information about memory addresses and Exploit the Damn Exploitable Android App.
Aug 2

Upcoming Blog Posts:

- Setting up our mobile vulnerability research lab - Previous Page
- Dynamic analysis and Reverse Engineering 
- Abusing Info Leaks to bypass ASLR - Current Page
- Exploit Stack Overflow

Address Space Layout Randomization (ASLR) is a critical security feature implemented in modern operating systems to prevent attackers from exploiting memory corruption vulnerabilities effectively. By randomizing the memory layout, ASLR makes it challenging for attackers to predict memory locations and launch successful attacks.

Understanding Format String Vulnerabilities: 

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.

adb forward tcp:6000 tcp:6000

connect to vulnerable application and Sending %x to leak data

nc 127.0.0.1 6000
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.

Abusing Info Leaks

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 = 0x000000000700 – 0x000000000100

offset = leaked_address – image base

offset = 0x000000000700 – 0x000000000100
offset = 0x000000000600

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

Leaking a Stack Address

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.

To achieve that, disassembling the memory leak function is required.
“disas Java_com_example_mynativetest_MainActivity_leakMemory”
Put a breakpoint on snprintf function. 

“break *address”
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.

x/1000x $sp
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.

“vmmap 0x8e580120”
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.

Restart the application, establish a connection, and then send the data as required.

%26$x
Verify the leaked address by running vmmap against the address

Leaking a libc 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.

x/400x $sp
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

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

(Leaked_address_stack_position -stack_top_positon) / 4 + 2 =hex_position

Convert_to_decimal(hex_position)
0x9B400534 - 0x9b400018 = 0x51C

0x51C / 4 + 2 = 0x149 = decimal 329

Libc address position is 329 and now we can test position and leak the libc address.

Send: %329$x
We can now add that to our exploit. 
Execute the exploit and observe the leaked addresses.

Calculating Base Addresses

Calculate Stack Top

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.

offset = Leaked_stack_address – stack_top
offset= 0x94600140 – 0x94600018
offset = 0x128

Calculate Libc Base

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.
offset = leaked_address – image base
offset = 0xae3dc079 - 0xae37b000 
Offset = 0x61079
Upon executing the exploit, we can observe the calculated stack top and libc base, which are crucial pieces of information for completing our exploit.

Summary

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.


Next Article
:
- Exploit Stack Overflow

In addition, we've set up a device that can support the operation of the Damn Exploitable Android app. In our upcoming article titled "Exploitinf Stack Overflow," we will extensively explore the utilization of memory leaks to bypass ASLR through cleverly applied format string vulnerabilities. Additionally, we will delve into reading the target process's memory through a format string overflow attack, followed by executing the actual attack via a buffer overflow attack with knowledge of the memory space. Our primary goal is to identify critical areas of interest, with a particular focus on analyzing the native components of the application.

Stay tuned for this deep dive as we unravel possible targets to focus on, leveraging these tools to expose vulnerabilities and learn how to build an exploit for an Android Device running on an Armv7 Processor.

Want to learn how do this on our cutting edge platform and running for Android 13 running on Arm64 without setting up a lab?

Check out our training: https://www.mobilehackinglab.com/course/android-userland-fuzzing-and-exploitation