Home BadBinder Emulator Root
Post
Cancel

BadBinder Emulator Root

During a recent mobile audit engagement I was on I was faced with a typical problem that most mobile researchers and bug bounties hunters face.

A number of protections were implemented in the mobile application I was scoped with testing.

These features included things such as

  1. Root Detection
  2. Emulator Detection for genymotion
  3. Requirement of the Gplay applications.
  4. GPS Location requirement.

These protections are typical in mobile application audits however they can increase the time to audit a mobile application.

During the engagement I was also slowly (still am.) working my way through the wonderful course by cloudfuzz on android kernel exploitation located here Android Kernel Exploitation.

This course works through CVE-2019-2215 This is a Use after free (UaF) in the Binder IPC also known as BadBinder discovered by syzbot in December 2017 then discovered by Maddie Stone (@maddiestone) of Project Zero on 27th September 2019 Syzbot Discovery which also included documentation with the exploitation primitive here Maddie Stone Exploit Primitive

During this guide its required to patch the android kernel to reintroduce the BadBinder bug, then recompiling the kernel to run on the stock android studio emulator with the gplay applications once the vulnerable kernel is compiled run the following to start the emulator with the vulnerable kernel and supports gdbserver to allow for kernel debugging

emulator -show-kernel -no-snapshot -wipe-data -avd CVE-2019-2215 -kernel ~/workshop/android-4.14-dev/out/kasan/dist/bzImage -qemu -s -S

This will boot the emulator into a halted state as the kernel needs GDB to be attached before it will progress.

Halted Kernel

Once gdb -quiet ~/workshop/android-4.14-dev/out/kasan/dist/vmlinux -ex 'target remote :1234'. GDB will be hooked on the kernel and can be progressed by entering in c for continue as demonstrated below.

Kernel Start

However due to the fact this is the standard emulator from android studio running adb root will response with the typical adbd cannot run as root in production builds. Permissions

However, We stress not, Due to the BadBinder bug being reimplemented into the kernel we can leverage it to successfully gain temp root access on the restricted device.

To execute this we drop into shell running adb shell since we don’t have permissions a number of syscalls and binaries applications will not execute. Limited Execution

This makes auditing applications drastically harder, For this to work we need the PID of the sh application. So running pidof sh i was returned 7037 as demonstrated below. PID

With this knowledge we are able to gain root by running the Scripted Privilege Escalation script provided by CloudFuzz and using the the pid as the argument which will then gain root permissions.

Rooting

Once the rooting is completed the PID 7037 now has a root access, From this we are able to deploy frida using the frida-push.py script Frida-Push.

The Frida application binary is then wrote out to /data/local/tmp/frida-server and since we have root permissions we are able to chmod +x frida binary and run it. This allows us to use frida and other applications bypassing the root detection methods because it is a temporary root which means checking for the typical root detection methods such as su will not work.

Frida! However since this running with the wipe-data flag and is temp root all information on the device is lost when the device terminates, Keep this in mind when using this emulator for testing purposes.

This post is licensed under CC BY 4.0 by the author.