Drozer is a framework for Android security assessments developed by MWR Labs. It is one of the best Android security assessment tools available for Android Security Assessments. According to their official documentation, “Drozer allows you to assume the role of an Android app, and to interact with other apps, through Android’s Inter-Process Communication (IPC) mechanism, and the underlying operating system.” When dealing with most of the automated security assessment tools in web world, we need to provide the target application details, go and have a cup of coffee, and come back to get the report. Unlike regular automated scanners, Drozer is interactive in nature. To perform a security assessment using Drozer, the user has to run the commands on a console on his workstation. Drozer sends them to the agent sitting on the device to execute the relevant task.
Getting ready with lab setup
Prerequisites:
- A workstation (in my case Ubuntu) with the following:
JRE or JDK Android SDK
- An Android device or emulator running Android 2.1 or later. First, grab copy of Drozer installer and Agent.apk from the following link. https://www.mwrinfosecurity.com/products/drozer/community-edition/ In fact, MWR Labs has given an awesome user guide which can be downloaded from the same link. But this article gives a brief introduction to setup and basic usage of Drozer, so that we can use this to build on it in the upcoming articles where we discuss more sophisticated vulnerabilities. This article assumes that the reader is working on a similar environment as I am doing. Download the appropriate version of Drozer if you are working with a different set up. After downloading, install all the required dependencies before installing Drozer itself. If you are using the Windows version of Drozer, installation is straightforward and it is similar to any other software installation. To check if installation is successful, open up a new terminal and run the command “drozer” as shown below.
Now, install the agent.apk file we have downloaded earlier onto your emulator. It can be done using “adb” as shown below. [plain] adb install agent.apk [/plain]
To start working with Drozer for your assessments, we need to connect the Drozer console we have on the workstation and agent sitting on the emulator. To do this, start the agent on your emulator and run the following command to port forward. Make sure you are running the embedded server when launching the agent. [plain]adb forward tcp:31415 tcp:31415[/plain]
Now, we can simply run the following command to connect to the agent from the workstation. $ drozer console connect We should now be presented with the Drozer terminal as shown below.
Performing android security assessments with Drozer
We try to perform security assessment of one of the apps, which we already discussed. This shows the power of Drozer. If you have gone through my first article in this series, we saw how to exploit vulnerable activities, which are exported. Install the app in a real device or emulator. In my case, I am using an emulator for this demo. Installing testapp.apk
As we know from the first article, testapp.apk has an exported activity. Fill out the form below to download the file if you don’t already have it. Let’s begin using Drozer to perform a security assessment of this app. Before we begin, let’s have a look at some useful commands available in Drozer.
Listing out all the modules
[plain] dz> list [/plain] – shows the list of all Drozer modules that can be executed in the current session.
The above figure shows the list of modules that can be used (the output is truncated). Retrieving package information To list out all the packages installed on the emulator, run the following command: [plain] dz> run app.package.list [/plain]
(Output is truncated) As we can see in the above figure, I have highlighted two apps, which we used earlier in this series. Now, to figure out the package name of a specific app, we can specify the flag “-f” with the string we are looking for. [plain] dz> run app.package.list –f (string to be searched) [/plain]
As we can see in the above figure, we got our target app listed below. [plain] com.isi.testapp [/plain] To see some basic information about the package, we can run the following command. [plain] dz> run app.package.info –a (package name) [/plain] In our case, [plain]dz> run app.package.info –a com.isi.testapp[/plain]
We can see a lot of information about the app. The above output shows where the app data is resided, APK path, if it has any shared User ID etc.
Identifying the attack surface
This section is one of the interesting sections when working with Drozer. We can identify the attack surface of our target application with a single command. It gives the details such as exported applications components, if the app is debuggable, etc. Let’s go ahead and find out the attack surface of testapp.apk. The following command is the typical syntax for finding attack surface of a specific package. [plain] dz> run app.package.attacksurface (package name) [/plain] In our case for testapp.apk, [plain]dz> run app.package.attacksurface com.isi.testapp[/plain]
As we can see in the above figure, testapp application has two activities, which are exported. Now, it’s our job to find the name of the activities exported and if they are sensitive in nature. If they are sensitive, we can further exploit it using existing Drozer modules. This app is also debuggable, which means we can attach a debugger to the process and step through every single instruction and even execute arbitrary code in the context of app process. We have already covered two detailed articles on how to exploit debuggable apps. You can go through them if you want to know more about it.
Identifying and exploiting Android app vulnerabilities using Drozer
Now, let’s work on the results we got in the previous section where we were trying to identify the attack surface of our target applications. Attacks on exported Activities This section focuses on digging deeper into testapp.apk in order to identify and exploit its vulnerabilities. From the previous section, we already knew that this app has an exported activity. To identify the names of the existing activities in the current package, let’s go ahead and execute the following command. [plain] dz> run app.activity.info -a (package name) [/plain] In our case, [plain]dz> run app.activity.info -a com.isi.testapp[/plain]
In the above figure, we can see the list of activities exported in the target application. com.isi.testapp.MainActivity is obviously the home screen which is supposed to be exported in order to be launched. com.isi.testapp.Welcome looks like the name of the activity which is behind the login screen. So, let’s try to launch it using Drozer. [plain] dz> run app.activity.start –component (package name) (component name) [/plain] In our case it is, [plain]dz> run app.activity.start –component com.isi.testapp com.isi.testapp.Welcome[/plain]
The above command formulates an appropriate intent in the background in order to launch the activity. This is the same as launching activities using activity manager tool, which we discussed in the previous module. The following figure shows the screen launched by Drozer.
It is clear that we have bypassed the authentication in order to login to the app. What is the problem here? As we discussed in the first article of this series, the activity component’s “android:exported” value is set to “true” in the AndroidManifest.xml file.
Conclusion
This article is to give readers a brief introduction to Android application penetration testing with Drozer. In the upcoming articles, we will see even more sophisticated vulnerabilities and their exploitation. We will also see how to write Drozer extensions later in this series.
