Bytecode Reuse Attack (Part 4)

As last blog post on bytecode - based exploitation on Android, the next step following bytecode injection is discussed, namely: bytecode reuse.

To answer the question about why an attacker needs bytecode reuse, although there already is bytecode injection, remember the arms race in (binary) exploitation. In a nutshell, a new exploitation technique triggers a reaction in form of at least one security mechanism that (partially) mitigates the new technique. If only bytecode injection was researched, then the best response would be the development of a new security mechanism that prevents nterp from executing arbitrary data. In other words, nterp would be restricted to executable code, i.e. bytecode. To be honest, every developer would respond with such a fix, myself included! However, bytecode injection is not the full potential of bytecode - based exploitation.

Bytecode Injection (Part 3)

With all the basics out of the way, this blog post shows the first bytecode - based exploitation technique on Android: bytecode injection! This opens the door to many interesting exploits, where injected bytecode can function as a one - in - all solution or an intermediate stage.

In order to fully understand this technique, it is recommended to read the introductory blog posts first! As of writing, there is no public information on this topic except for the Android source code.

Fundamentals for Bytecode Exploitation (Part 2)

Exploiting a vulnerability always requires a certain knowledge about the operating system, including how processes are launched, what libraries are used and how control - flow “works”. While the latter could be considered coming from the architecture, this is not always the case on Android, because the Android RunTime (ART) provides ways to call bytecode methods and redirect bytecode control - flow. Hence, ART dictates how bytecode control - flow works, not directly the underlying CPU. Understanding the above mechanisms is the minimal requirement for understanding bytecode - based exploitation. Based on that, more sophisticated analysis techniques can be built specifically for Android bytecode, to make bytecode - based exploitation feasible.

Introduction to Android Bytecode Exploitation (Part 1)

Android resides among the most popular operating systems for mobile devices, which causes Android to also be among the most popular targets for exploitation. While Android is frequently updated to fix the latest CVEs, malicious actors already search for new vulnerabilities, as gaining control over millions of computationally powerful devices is very appealing. The market shares underpin that Android is by far the most lucrative platform for malicious actors targeting mobile platforms.

Attempting Timing Attacks against Scudo

In this second blog post we will take a different approach for attacking Scudo , i.e. we will try to the measure execution times for calls to malloc and hope to be able to derive a portion of the internal state of the allocator (i.e. perform side channel attacks). The version of Scudo considered in this blog post is 161cca266a9d0b6deb5f1fd2de8ad543649a7fa1 .

There will be almost only negative results (which means I unfortunately could not make it work), except for one. The main conclusion we can draw from this post is that Scudo is not designed to mitigate timing attacks! This follows from trying to leak a piece of information and then accidentally leaking a different and unclassified piece.

Binary Exploitation for Scudo Heap Allocator on Android

In this series of blog posts, we will investigate how an attacker may leverage the internals of the Scudo Allocator in order to obtain an advantage on an Android OS. To that end, necessary prerequisites will be discussed and analysed for their likelihood. The focus will primarily be on malloc and free , although realloc and other functions may also be of interest. According to source code , the Scudo version considered in this blog is 161cca266a9d0b6deb5f1fd2de8ad543649a7fa1.

Exploitation of Use - After - Free Modules

In this post we will be discussing how to exploit a Use - After - Free bug in both UseAfterFreeExecModule and UseAfterFreeWriteModule. As the names of the modules suggest, they differ in terms of the impact the bug has. To that end, in UseAfterFreeExecModule we will be able to control a function pointer, whereas in UseAfterFreeWriteModule we are given a Write - What - Where condition.

Exploitation of EasyStackBufferOverflowModule

This article describes exploitation of the EasyStackBufferOverflowModule. During exploitation, various Android - specific caveats are discussed.

Assumptions

We will assume that we have successfully grabbed a copy of the .apk file of damnvulnerableapp. Also, we will not discuss how to unpack an .apk file, but rather assume that we have access to libEasyStackBufferOverflowModule.so and the EasyStackBufferOverflowModule class. If it is unclear how to get access to these components when only given an .apk file, read the previous blog posts first!

Android Binary Exploitation

In this post, we will examine security mechanisms that Android 12 employs in order to make binary exploitation a bit harder. Also, we will discuss how to get to certain information like shared - object files that are necessary for successful exploitation. The latter will be generalized to getting limited source code access to an app given a corresponding .apk file.

Environment

Before diving into details, the technical setup has to be clarified. All of the following observations on security mechanisms were encountered on a x86_64 Pixel 3 emulator running Android 12 (build number is SE1A.220203.002.A1 ). When referencing source code from Android Open Source Project (AOSP), it will be w.r.t. Android 12.0.0_r31 . The build variant for damnvulnerableapp is currently only debug. Also there is no GooglePlay enabled as we require root on the device for debugging purposes only.