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.

BPF Memory Forensics with Volatility 3

Introduction and Motivation

Have you ever wondered how an eBPF rootkit looks like? Well, here’s one, have a good look:

Upon receiving a command and control (C2) request, this specimen can execute arbitrary commands on the infected machine, exfiltrate sensitive files, perform passive and active network discovery scans (like nmap), or provide a privilege escalation backdoor to a local shell. Of course, it’s also trying its best to hide itself from system administrators hunting it with different command line tools such as ps, lsof, tcpdump an others or even try tools like rkhunter or chkrootkit.

Investigating Binary Exploitation for JNI on Android

This post aims to be an introduction into a blog series about binary exploitation on Android. It tries to describe how the environment that runs vulnerable modules is set up and how the damnvulnerableapp supports the process of binary exploitation on Android.

Warning

The following app is intended to be vulnerable to specific attacks and can result in arbitrary code execution in the context of the app. Therefore, beware of this and do not use this app on a device/emulator that contains personal information whatsoever. Always launch the app in a controlled environment. No authentication is necessary to connect to the app and talk to vulnerable modules. Assuming the app is free of bugs, there is a guarantee that only one client can connect at a time.

Encryption - a curse and a blessing at the same time

Digital communication in today’s world has a particularly high status in our society. Financial transactions are conducted via online banking, private communication is increasingly limited to digital messenger services, and even health data is experiencing a shift to digital form. Due to the growth of such sensitive digital data, the need for secure transmission of such data has become increasingly important over the past decades. With the introduction of high-performance and digitally secure cryptographic methods, such as SSL/TLS, today’s digital communications are predominantly encrypted. Whereas back then, for example, an attacker could hang himself between the client and the server and read the data traffic without encryption, today all he sees is a jumble of letters. Encryption is truly a boon for protecting sensitive personal data, but it also has its drawbacks, as with almost everything. Encrypted communications negate the ability to analyze communications, which is very relevant when reverse engineering malware or researching vulnerabilities.

Make Frida Great Again

In order to analyse binaries on e.g. Android systems, one is offered a plethora of tools to use to figure out what a binary is doing, whether it is malicious or just buggy. One way to figure out the behaviour of a binary is to utilise the strength of dynamic analysis. Under linux, i.e. Android in particular, Frida is a tool that is used for automated instrumentation of binaries, to inspect memory, function calls etc.

Intro

This blog post reflects our exploration of the Dirty Pipe Vulnerability in the Linux kernel. The bug was discovered by Max Kellermann and described here . If you haven’t read the original publication yet, we’d suggest that you read it first (maybe also twice ;)). While Kellermann’s post is a great resource that contains all the relevant information to understand the bug, it assumes some familiarity with the Linux kernel. To fully understand what’s going on we’d like to shed some light on specific kernel internals. The aim of this post is to share our knowledge and to provide a resource for other interested individuals. The idea of this post is as follows: We take a small proof-of-concept (PoC) program and divide it into several stages. Each stage issues a system call (or syscall for short), and we will look inside the kernel to understand which actions and state changes occur in response to those calls. For this we use both, the kernel source code (elixir.bootlin.com , version 5.17.9) and a kernel debugging setup (derived from linux-kernel-debugging ). The Dirty Pipe-specific debugging setup and the PoC code is provided in a GitHub repository.

In this blog post I will go in depth into the inner workings of CVE-2021-43247 , which was fixed on the 14th of December 2021. This bug was classified as “Windows TCP/IP Driver Elevation of Privilege Vulnerability”. The vulnerability itself was probably dormant for a long time, but became exploitable when the AF_UNIX address family was first introduced in 2019.

I will also take this as an excuse to explain in detail, what drivers are, how user space communicates with drivers, what a Local Privilege Escalation (LPE) is and what how we can achieve it in this case.

Installing new .NET versions on a Windows 7 VM

In this post, I will explain how to install .NET Framework 4.8 on a Windows 7 VM.

Motivation

Virtual Machines running Microsoft Windows are frequently used for dynamic analysis of Windows executables. Windows 7 is still used for analysis VM, although it is no longer supported by Microsoft and ships with an outdated .NET version. If a sample requires a .NET version which is not present on the analysis VM, the execution fails and the file cannot be analysed. For this reason it might be required to install a recent .NET version on a Windows 7 VM.

Fuzzing Network Applications with AFL and libdesock

Fuzzing network servers with AFL is challenging since AFL provides its input via stdin or command line arguments while servers get their input over network connections. As the popularity of AFL grew, many attempts have been made of fuzzing popular servers like apache and nginx using different techniques and hacky workarounds. However an off-the-shelf network fuzzing solution for AFL didn’t exist for a long time until so-called “desocketing” tools emerged. These desocketing tools enabled network fuzzing without making a lot of additional modifications to the program under test and quickly became widely used in combination with AFL.