This article describes basic steps to setup, install and use the drozer framework to identify possible vulnerabilities on Android-based applications during pentesting. The drozer framework[1] comes in two parts, the first part is the drozer console, which you install on your working computer (workstation), the second part is the drozer agent, which you need to install on the Android virtual device you’ll be using for testing.
Setting up the drozer framework
For either Debian or Ubuntu you can download the drozer .deb package and install it, you should download the agent apk too (remember to verify the checksums). First, install the drozer framework using dpkg, then run it to make sure it is working fine:
Start the Android virtual device you are using for testing, you can refer here[2] for creating and managing virtual devices. Once the device is running, install the drozer agent apk using the Android Debug Bridge:
Run the drozer agent on the Android virtual device and make sure the Embedded Server is started (ON), take note of the port, 31415:
Now, we need to somehow communicate between the drozer console (running on our workstation) and the drozer embedded server (running on the virtual device as the agent). For this, we use the forward option of the adb, as follows:
This sets up a listener on port 31415 on our workstation and forwards TCP traffic on it to the same port on the virtual device, we can check the listener on the workstation by using the netstat command:
Then, we start the drozer console and connect to the embedded server on the virtual device, through the listener set in our workstation on port 31415:
Installing the application to evaluate
Once you have the apk of the application you want to evaluate, install it using the Android debug bridge:
And run it to see how it works, in this case we have created a small (two activities) Android application that we’ll be using; this is a basic application and looks like this:
Assessing the application with the drozer framework
First, let’s see what commands the drozer console accepts by using the help option. We can see several options, including the list option, which shows a list of all available modules:
After issuing the list command, you can see a host of modules, to work with activities, packages, services, a few scanners and Linux command execution:
Let’s now get the list of packages installed in the device, we can see that the package we installed earlier is listed:
Once we identify the package name we’re interested in (com.securitygrind.application), we can get details on the package by running the app.package.info command and sending the package name as parameter (-a com.securitygrind.application):
Here we can see some interesting information; data directory, UID, permissions. Let’s now use scanner.misc.readablefiles module to find if there is any world-readable files in the package data directory. First let’s see how this module works:
First, we need to setup the Busybox tool, since this module requires it. We run the command below:
Then, we can issue the next command, and get a list of world-readable files:
Back to identifying the attack surface
One very interesting module on the drozer framework is the app.package.attacksurface, this one helps identify possible weaknesses. Here we can see there are a couple of exported activities, one broadcast receiver and one service exported as well, we can see that the debuggable flag is also set:
Let’s now try to find some more information about the exported activities, for this we can use the app.activity.info module and sent the package name as parameter:
We notice that there are two exported activities, the first one (LoginActivity) is the main point of entrance of the application, and so, it makes sense for it to be exported, the other activity, however, seems to be misconfigured, let’s try to start this activity directly (without going through the LoginActivity):
We check the virtual device and see that the PrivateActivity was started:
You can also start activities on the virtual device using the activity manager through the ADB shell, as follows ./adb shell am start [packagename]/.[activity]
We can see that the activity is started as well:
Note: in this specific case, the allowBackup flag is also set on the Android application, however, this information didn’t came up on the attack surface results, this is something you should check on the manifest file directly:
Conclusion
drozer is an easy-to-use framework for quickly identifying weaknesses and possible vulnerabilities on Android based applications during pentesting. This article covers the basics on how to setup and start working with the framework, however, the framework still have some interestingly looking functionality, for instance, the ability of the to work as a RAT (Remote Access Tool).
[1]https://labs.mwrinfosecurity.com/tools/drozer
[2]https://developer.android.com/studio/run/managing-avds.html
Recent Comments