This article is part of a series:
Android Security Analysis Tools, part three - Drozer and QARK
Welcome to the third part of the blog posts series dedicated to security analysis tools for Android apps. The series focuses on the tools suggested by the OWASP Mobile Security Testing Guide (MSTG). In the first part we discussed the problem of security analysis and looked at the JAADAS framework. The second blogpost
The series is dedicated to tools for static analysis of apps. This means that analysis is performed automatically and that it operates on applications and their source code. However, it’s worth to note that it is not the only type of analysis available. The second type is called dynamic analysis and it involves examining the application by interacting with it. Thanks to this approach, vulnerabilities that were found can be experimentally tested. Such tests can show the scale of the problem and help the reviewer visualise their consequences. Dynamic analysis is also mentioned by MSTG. The book names a tool called Drozer, which is a complex piece of software focused mostly on dynamic analysis.
Drozer is a tool based on both of the aforementioned types of analysis, but mainly focused on the dynamic kind. It works in two stages. Firstly, on the reviewer’s request, the tool can perform static analysis to detect vulnerabilities and potential attack vectors. The user can then use the vectors to test the app’s behaviour and find out how big is the risk posed by the vulnerabilities.
The Drozer framework consists of two main elements:
- Main app console
- Drozer mobile agent - APK file
The first element is a Python application which works as the management console. The second is an Android application written in JAVA. Its task is to execute commands initiated by the reviewer in the console. This means that all simulations of attacks against the analysed app are performed from the context of an application installed on the same device. Such approach makes the application (Drozer mobile agent) work under the limitations imposed by the Android security architecture.
To use Drozer you need to meet a few requirements, which are listed below:
- Python 2.7
- Protobuf 2.6 or greater
- Pyopenssl 16.2 or greater
- Twisted 10.2 or greater
- Java Development Kit 1.7
- Android Debug Bridge
Drozer has a set of features that allows testers to perform very detailed analysis of the app. Every feature is a separate module. The set of modules is expandable, which makes Drozer extensible. Each module is used for different aspects of analysis. Some of them are designed to perform static analysis, while others can be used to perform different types of dynamic analysis. From the perspective of accuracy of analysis, this approach is the right choice. However, when it comes to static analysis and automation, such an approach can be a significant obstacle.
Dozer will be particularly useful because of its complexity and the fact that analysis is performed from the perspective of a malicious application installed on the same device. However, the tool requires interaction to make the best use of its capabilities. This means that full automation of this tool will not be easy and may limit its possibilities.
QARK, aka the Quick Android Review Kit, is the next tool we are going to discuss. In contrast to Drozer, QARK is focused on static analysis, although it has a few features that help with dynamic analysis too. Like the previous application, QARK is based on a console interface and written in Python and JAVA. The tool is published as open-source under the Apache 2.0 license. Also, similar to other tools, you need to meet some technical requirements:
JRE 1.6+ (preferably 1.7+)
OSX or RHEL6.6 (others may work, but not fully tested)
QARK is a very complex analyzer and, to a large extent, it is based on the assumptions of the previously discussed tools. However, it significantly improves on the disadvantages of the other software we’ve reviewed. It is also worth emphasizing that the tool is being continuously developed by the LinkedIn dev team.
Features and requirements
The range of functions performed by the tool is very large. The analysis takes place on multiple levels and, according to the documentation, QARK is able to find such vulnerabilities as:
- Inadvertently exported components
- Improperly protected exported components
- Intents which are vulnerable to interception or eavesdropping
- Improper x.509 certificate validation
- Creation of world-readable or world-writable files
- Activities which may leak data
- The use of Sticky Intents
- Insecurely created Pending Intents
- Sending of insecure Broadcast Intents
- Private keys embedded in the source
- Weak or improper cryptography use
- Potentially exploitable WebView configurations
- Exported Preference Activities
- Apps which enable backups
- Apps which are debuggable
- Apps supporting outdated API versions, with known vulnerabilities
A very important advantage of QARK is that it is made up of many modules that are based on known and proven tools. As an example :
- Parsing: PLYJ, Beutyfullsoup, Minidom
- Reverse engineering: Apktool, CFR, Dex2Jar, Procyon
- Build tools: Android SDK
As you can see, QARK uses multiple tools for the same task. Thanks to this approach the framework can be more effective. One great example of such effectiveness is reverse engineering - the tools listed above are used at the same time to perform source code decompilation with different methods. In case one method fails, the framework will use another one. This makes analysis longer, but the result is more accurate.
QARK can work in two modes - interactive or headless. The first one is the default and can be run by the following command:
$ python qarkMain.py
This mode doesn’t require any input parameters. It operates step-by-step. In each step, the user will be asked to select the next execution path or add some input parameters. In this mode user interaction is necessary.
The second mode can be started using one of the two following commands:
python qarkMain.py --source 1 --pathtoapk /APKs/diva-beta.apk
python qarkMain.py --source 2 -c /project/diva --manifest
This mode is fully automatic and it will be perfect for your CI/CD stack. Starting this mode will run full feature analysis without any user interaction. At the end, the framework will generate an output report. You can also add more parameters to the start commands that will modify the analysis flow. For example, you can add:
--exploit 1 --installto generate an exploitation APK file that will contain an implementation of the vulnerabilities found in the analysis process. The APK file will be automatically installed on connected devices via ADB. More launching parameters are available in the documentation.
The framework generates output in multiple formats. This is another characteristic of the tool that distinguishes it from other tools discussed in this series. The basic format of the output is HTML file. It contains a summary of the results presented as a static web page.
This format makes the results more user friendly, making analysis of the results faster and more precise. The results web page contains all detected vulnerabilities grouped into categories, such as:
- IPC communication,
An important element of the result file is also the reference section, which contains links to vulnerability information. Additionally, results are also generated as XML/JSON files. They are the source of all the data presented on the HTML web page, but can also be used for different purposes, like integration with external tools. This way the tool can be easily integrated with a CI/CD stack.
It is also worth noting that QARK generates ADB commands that allow practical use of a vulnerability against the analyzed application. Such commands can also be automatically compiled into an exploitation APK. This APK is optional, but it can be also generated as an output of QARK analysis. The APK allows the reviewer to additionally perform dynamic analysis directly on a device/emulator.
- Repository is up-to-date
- Last commit was published 3 months ago
- There is a roadmap for further development
- Analysis can be performed on source code or APK file (automatic decompilation)
- APK can be provided as a local file or QARK can download it directly from the device
- Is based on well-known tools
- Extended user interface interface (console)
- Multiple stages
- Some steps can be skipped
- Auto-generated exploitation APK for detected vulnerabilities
- Three compilations (different compilers) at once
- HTML report generated
- Result is generated in different formats
- HTML file
- JSON/XML files
- Lots of data on output
In this part, we have addressed the issue of dynamic analysis and discussed Drozer. It is a great, extensive tool dedicated to dynamic analysis of Android apps. The most important aspect of it is the fact that tests are carried out from the perspective of an application installed on the same device as the tested app. Thanks to this approach the tests are subject to the same security mechanisms as the potentially malicious app. This makes tests more reliable and precise. Drozer will be a great fit for dynamic analysis, but not so for static analysis. QARK from LinkedIn is better suited to this type of task.QARK is a complex tool based on similar assumptions as JAADAS and AndroBugs. However, the tool is a great answer to all the problems and disadvantages of the previous ones. It is being constantly developed, can generate output in multiple formats (user-friendly and well-formatted JSON/XML files), and it can work on different kinds of inputs (APK file, source code, or APK installed on device). Additionally, QARK uses a lot of proven tools for analysis, and sometimes it will use multiple tools at the same time to improve the efficiency and reliability of the processes (e.g. reverse engineering). Another advantage of QARK is the fact that it also generates ADB commands and exploitation APK files. Both features allow you to perform dynamic analysis based on the results of static analysis.In summary, QARK is a great tool and, in my opinion, a perfect solution if you’re looking to add vulnerability testing to your CI/CD stack. The only disadvantage I can think of is that it outputs a lot of data - but is that really a disadvantage?
Other articles from this series: