At Black Hat 2017 Khalil Mateusz performed an Arsenal Talk, where he spoke about his new project BadIntent, which is a “missing link between Burp and the core of Android’s IPC/Messaging-system.”
This description is from the official Black Hat website: “BadIntent consists of two parts, an Xposed module running on Android and a Burp-plugin. Based on this interplay, it is possible to use the Burp’s common workflow and all involved tools and extensions, since the intercept and repeater functionality is provided. BadIntent hooks deeply into the Android system, performs various method redirections in Parcels and adds additional services to provide the described features. Most notably, BadIntent works system-wide and is not restricted to individual user apps.”
Android’s Inter-Process-Communication mechanism is the Binder framework. Apps and their internal components such as services and activities are able to interact with each other through Binder. Every interaction is handled by a Binder transaction. Every transaction consists of a request and a reply, and the data is transmitted in a Parcel. BadIntent hooks and persists all write operations. The delayed executions are stored in BadIntents parcel pool. All transactions are hooked and the Parcels are sent to Burp for inspection. Afterwards the updated Parcel is handed over to the actual transaction routine.
This write-up details my method for setting up this environment. In my setup, I’m using a Genymotion emulator (Nexus 5x, Android 6.0, API level 23), a VM (can be Windows or Linux) hosting Burp Suite Professional v1.7.29 (although Burp Suite Free Edition will work), and the Android SDK platform-tools set that can be downloaded from the Android developer site. All links cited here can be found at the end of the article.
Genymotion emulators are rooted by default and contain a ‘su’ binary allowing you perform root actions, but to give specific applications root access I needed to leverage something like the app “SuperSu”. Installing SuperSu from the app store didn’t work for me as you will likely get the error that there is already a su binary on the device. So, after some digging through sites, I found an older version of the SuperSu app in a zip/flashable format. Genymotion makes flashing these files as easy as dragging the zip onto the emulator and releasing. This works when using the Genymotion Android tools (pictured below).
Now we can install the Xposed Framework and Xposed Installer app. My first try at this I installed the latest version of the Xposed Framework and Installer from the Play store. This gave me errors in regards to API level and architecture. Remember, Genymotion emulators are x86 but support armv7 applications. So, if you are in a root shell on an Android device, you can run the command “getprop”, look down the list for “ro.product.cpu.abi”, and you should see x86 as the value. Below is the error I was receiving in Xposed:
The BadIntent GitHub page mentions that he tested this on a Genymotion emulator with Android 6.0, api level 23, and Xposed framework v87. After a little searching, I was able to find a site that hosted multiple versions of the Xposed framework, installer, uninstaller, and apk for different architectures. Grab the x86 v87 zip files and proceed to flash them onto the virtual device the same as the SuperSu package. This will require a couple of reboots which on Genymotion is just, power off and back on. Now you can see the Xposed installer in your apps list. Once opened the status should indicate that Xposed framework version 87 is active. See image below:
Xposed has its’ own module repository, so if you click the menu button in the top left corner, you can go to Download, and search for the BadIntent module. Once the results return, you should have only one option to download/install.
After the module downloads, make sure the checkbox is selected in the Modules menu. See image below:
Next, open the BadIntent module from the applications list on the device. There are a handful of options that you can set. From the top down, the Package filter regex can be the package that you want to intercept. For this example, I’m selecting the com.workday.workdroidapp.
The Interface filter regex is by default set to “.*” which is fine as it is. Turn on the Capture Log function so we can see what’s being printed there. I usually leave Hook system apps off, since it can cause problems like boot loops if the system apps are being hooked while the device is being booted up. The Target IP is the current IP of the Android device. This is usually set to the WIFI-IP. This is needed because Burp needs to determine where the transaction details are going to. The next option is “Use System Proxy”. I have this turned on, as I set the proxy for the WIFI connection in the system settings. If not, you can potentially use the Proxy Host and Proxy Port options below to specify your Burp IP and port. Pretty straightforward.
Now on to the BadIntent Burp extension. When this talk was given, the extension was submitted to portswigger, but as of writing this in December 2017, the extension has not yet been published to the BAPP Store. Luckily, Mateusz added the BadIntent Burp extension java files and pom.xml to the repo, so we can clone those and build it ourselves. Once you have done a git clone of the repo, you can use Eclipse Oxygen (current Eclipse Java IDE) to load up the project. With this updated version of Eclipse, the Maven plugin is built in, and required for this compilation. In the BadIntentBurp folder, you will see a pom.xml file which is a build config file used with Apache Maven. Conveniently, we can build and package these java files into a single jar file with dependencies included.
In Eclipse, select File -> Open Projects from File System, then click Directory, find the BadIntentBurp folder and select it. Check the box of the folder you want to import and click Finish. See image below. My BadIntentBurp folder is already imported, so it’s greyed out for me. Yours will not be since you haven’t imported it before.
Once the project finishes loading up, if all went well, you should be able to right-click on the root folder of the project, select Maven and then Update Project. This should build the project model. Then we go to Run -> Run As -> Maven Build. This will download all dependencies if they are not already, and build the project into a single jar file with dependencies included. There will be a secondary jar file without dependencies, but we won’t be using that one. See images below:
Next, we can take that badintent burp with dependencies jar and load that up in Burp Suite. Under the Extender tab, click the Extensions tab and then Add, to add an extension manually. In Extension details, make sure Java is selected and then select the jar file you just built. The rest of the options can stay default since we want to use the UI to view output and errors. Once the BadIntent extension is added, make sure the checkbox is checked. See image below:
I’m going to assume you’ve used Burp Suite before, but go ahead and set up your proxy. In the options tab, edit your listener by setting the radio button to “specific address” and select your current IP. See image below:
If you haven’t done so, you will need to export your Burp certificate to install on the Android device. Under the same options tab, select import/export CA certificate -> export Certificate in DER format. Then rename to a .cer. Using the adb tool from Android SDK platform tools, do an “adb push <path to .cer > /sdcard/burp.cer” to push the cert to the sdcard directory on the device. Then, in the Genymotion emulator under settings, select Security -> Install from SD card. Select the burp.cer and complete this process. Now you have the necessary cert to properly intercept all traffic from this device in Burp Suite, unless an application uses certificate pinning. I won’t walk you through using adb since you should know this if you’re looking at Binder attacks on Android devices. 😉 See below image where I am intercepting parcels from the workday application:
Please see the slides and documentation from Mateusz’ Black Hat Arsenal talk and great work on this project. This will help testers and developers know this attack surface and the risks of not encrypting data used in inter-process-communications.