Showcases
In this section we will have a look how BadIntent can be used for Pentesting purposes. Some examples will use the InsecureBankv2 app, which is an on purpose insecure app in order to be able to train or demonstrate typical vulnerabilities.
Setup BadIntent filter properties as follows in order to monitor the app and all transactions:
Package filter regex: com.android.insecurebankv2
Interface filter regex: .*
Capture Log: true
BadIntent can be configured to monitor logs using the Capture Logs switch in BadIntent Android preferences. After logging in to InsecureBankv2 you can observe that the username and password is logged:
Accidently exported activities can be attacked using the Repeater functionality. In the following example a previously used PostLogin is repeated in order to bypass the login screen.
As a result, the PostLogin view is opened without having entered the user credentials:
Pasteboard vulnerabilities can be easily detected. Therefore, BadIntent Android’s preferences need to be configured as follows:
Interface filter regex: .*Clipboard
As you can observe in the following HTTP history, account information (Text: 88888888) are sent to the clipboard.
Sniffing generated or received intents is the core feature of BadIntent. The following configuration is sufficient for monitoring intent interactions:
Interface filter regex: .*ActivityManager
With respect to InsecureBankv2 you can quickly determine that password changes are broadcasted:
After putting the user credentials in the main activity, an intent is created and submitted to the DoLogin activity. This activity creates a HTTP request in order to perform the login against the backend. In order to conduct brute force attacks you can inject the words into the intent instead of the HTTP request. This is especially handy when you face some obfuscated backend but non-obfuscated internal communication:
Intruder configuration:
You can observe in InsecureBankv2's backend (VM) that the attack is successfully running:
Although this is not the purpose of BadIntent, it is possible to create a keylogger. The only thing you have to do is setting up BadIntent Android’s preference:
Interface filter regex: .*InputContextCallback
Soft keyboard entries can be easily tracked, since the InputManager creates IInputContextCallbacks containing the entered text using in the keyboard. For more information please refer to the official IME documentation: https://developer.android.com/guide/topics/text/creating-input-method.html
Let's assume there is an app which does not validate input (represented by intents) from external apps and eventually places it in a WebView. This is an ideal example how Burp's intercept functionality can be used to modify the intent and conduct a Cross-Site Scripting attack:
Now, the URL is replaced by some XSS-payload:
As a result, the Javascript payload is executed and the vulnerability proofed:
Most IPC calls are implemented using AIDL. In the AOSP you can find various .aidl files, which are then used to generate stub (server-side) and proxy (client-side) code. As an example, we are going to perform some AIDL tests against Android's Keystore https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/security/IKeystoreService.aidl.
In order to understand which method is called you need to generated proxy/stub code and retrieve the transaction codes:
It is possible to interact with the Android Keystore, e.g. in order to encrypt or decrypt data blobs. In the following example the generate key method with alias "Repeated" is invoked from the repeater view (the Binder response is also present in the HTTP response):
As you can see the key has been created:
In the next step we are going to use Burp's sequencer in order to analyze the entropy of the data blob's returned by the generate key method:
(Firebase/Google) Cloud Messaging consists of the communication between Google APIs, local Play Store (com.android.vending) and the relying app. For receiving messages the relying app needs to implement receivers, which filter and process the com.google.android.c2dm.intent.RECEIVE action.
In order to be able to modify incoming messages the Play Store has to be hooked. Since the messages are transported as intents, ActivityManager is the interesting interface. Make sure to not intercept the communication to the Google servers, since the authentication in GMS will fail. The following BadIntent configuration is suggested:
Package filter regex: com.android.vending
Interface filter regex: .*ActivityManager
Use system proxy: false