This article introduces readers to a new tool for Android assessments rather discussing Android-specific vulnerabilities. Hence, this article assumes that readers have a basic knowledge of performing Android App assessments. If you are new to this, please have a look at my previous articles.

What is QARK

I always like to write the definitions from the original sources to make sure that the original meaning isn’t changed. According to one of its original sources, “At its core, QARK is a static code analysis tool, designed to recognize potential security vulnerabilities and points of concern for Java-based Android applications. QARK was designed to be community based, available to everyone and free for use. QARK educates developers and information security personnel about potential risks related to Android application security, providing clear descriptions of issues and links to authoritative reference sources. QARK also attempts to provide dynamically generated ADB (Android Debug Bridge) commands to aid in the validation of potential vulnerabilities it detects. It will even dynamically create a custom-built testing application, in the form of a ready to use APK, designed specifically to demonstrate the potential issues it discovers, whenever possible.”

Getting ready

As of now, QARK supports only Linux and Mac.

Extract QARK contents as shown below.

Make sure that you have all the dependencies mentioned in this Github page to run QARK.

Get the sample application provided in the downloads section

Android app assessments with QARK

This section shows how to use QARK to perform Android app assessments. QARK works in two modes.

Interactive mode Seamless mode

Interactive mode enables the users to choose the options interactively one after the other. Whereas seamless mode allows us to do the whole job with one single command. Let us first see the Interactive mode in action. Navigate to the QARK directory and type in the following command: python qark.py This will launch an interactive QARK console as shown below.

We can choose between APK and source code based on what we want to scan. I am going with the APK option, which allows us to see the power of QARK in decompiling the APK files. Once after choosing APK option [1], we need to provide the path to an APK file sitting on our PC or pull an existing APK from the device. Let’s choose the APK file location from the PC. In my case, I am going to give the path of the APK file(testapp.apk) that we used in PART-1 of this Android Hacking series [The same app is provided in the downloads section].

After providing the path of the target APK file, it is going to extract the AndroidManifest.xml file as shown below.

We can inspect the extracted Manifest file by choosing “Y” above.

It first displays the manifest file and waits for the user to continue. Press “Enter” to start analyzing the manifest file as shown below.

As we can see in the figure above, QARK has identified several issues among which one is a potential vulnerability due to the fact that “android:debuggable” value is set to true. QARK also has provided a warning that the activities shown above are exported. Once after finishing the analysis of manifest file, QARK begins with decompilation, which is required for Source Code Analysis. By pressing the “Enter” key, we can begin with the decompilation process as shown below.

For some reason, if this decompilation process takes longer time we can press “C” to continue with the analysis of whatever the code that was extracted during the decompilation process. QARK uses various tools to do the decompilation process. Once after finishing the decompilation process, we can press “ENTER” to start the source code analysis.

Let’s start the Source Code Analysis:

As we can see in the figure above, the source code analysis has been started to identify the vulnerabilities in the code. This provides a lengthy output on the screen with all the possible findings. This looks as shown below. After finishing the scan, QARK will present the following screen. This is one of its unique features, which allows us to create a POC app by choosing option [1]. onCreate INFO – No custom imports to investigate. The method is assumed to be in the standard libraries INFO – No custom imports to investigate. The method is assumed to be in the standard libraries INFO – No custom imports to investigate. The method is assumed to be in the standard libraries INFO – No custom imports to investigate. The method is assumed to be in the standard libraries INFO – No custom imports to investigate. The method is assumed to be in the standard libraries INFO – No custom imports to investigate. The method is assumed to be in the standard libraries INFO – No custom imports to investigate. The method is assumed to be in the standard libraries INFO – No custom imports to investigate. The method is assumed to be in the standard libraries INFO – No custom imports to investigate. The method is assumed to be in the standard libraries INFO – No custom imports to investigate. The method is assumed to be in the standard libraries INFO – No custom imports to investigate. The method is assumed to be in the standard libraries INFO – No custom imports to investigate. The method is assumed to be in the standard libraries INFO – No custom imports to investigate. The method is assumed to be in the standard libraries INFO – No custom imports to investigate. The method is assumed to be in the standard libraries

INFO – This class is exported from a manifest item: Welcome INFO – Checking this file for vulns: /Users/srini0x00/Downloads/testapp/classes_dex2jar/com/isi/testapp/Welcome.java entries: onCreate INFO – No custom imports to investigate. The method is assumed to be in the standard libraries ISSUES – CRYPTO ISSUES INFO – No issues to report ISSUES – BROADCAST ISSUES INFO – No issues to report ISSUES – CERTIFICATE VALIDATION ISSUES INFO – No issues to report ISSUES – PENDING INTENT ISSUES POTENTIAL VULNERABILITY – Implicit Intent: localIntent used to create instance of PendingIntent. A malicious application could potentially intercept, redirect and/or modify (in a limited manner) this Intent. Pending Intents retain the UID of your application and all related permissions, allowing another application to act as yours. File: /Users/srini0x00/Downloads/testapp/classes_dex2jar/android/support/v4/app/TaskStackBuilder.java More details: https://www.securecoding.cert.org/confluence/display/android/DRD21-J.+Always+pass+explicit+intents+to+a+PendingIntent ISSUES – FILE PERMISSION ISSUES INFO – No issues to report ISSUES – WEB-VIEW ISSUES INFO – FOUND 0 WEBVIEWS: WARNING – Please use the exploit APK to manually test for TapJacking until we have a chance to complete this module. The impact should be verified manually anyway, so have fun… INFO – Content Providers appear to be in use, locating… INFO – FOUND 0 CONTENTPROVIDERS: ISSUES – ADB EXPLOIT COMMANDS INFO – Until we perfect this, for manually testing, run the following command to see all the options and their meanings: adb shell am. Make sure to update qark frequently to get all the enhancements! You’ll also find some good examples here: http://xgouchet.fr/android/index.php?article42/launch-intents-using-adb ==>EXPORTED ACTIVITIES: 1com.isi.testapp.MainActivity adb shell am start -a “android.intent.action.MAIN” -n “com.isi.testapp/com.isi.testapp.MainActivity” 2com.isi.testapp.Welcome adb shell am start -n “com.isi.testapp/com.isi.testapp.Welcome” To view any sticky broadcasts on the device: adb shell dumpsys activity| grep sticky INFO – Support for other component types and dynamically adding extras is in the works, please check for updates

Additionally, it provides some adb commands to exploit the issues identified. Another nice feature of QARK to mention is its ability to provide nice reports.

Reporting

As we can see in the above figure, QARK has generated a report with the name “report.html”. We can navigate to the path provided in the previous figure and open “report.html” file to see the report. Personally, I liked the appearance of QARK reporting. Simple and clean. The following figure shows the overview of QARK findings under “Dashboard”.

Let’s first check the vulnerabilities reported from Manifest file.

As we can notice there are two vulnerabilities identified. Apart from the vulnerability information, there are some references provided to know more about those issues. The next tab has vulnerabilities related to App components.

As we can see in the figure above, QARK has identified two activities that are exported. Manual verification is required to decide if they are really vulnerabilities that pose some risk to the app. For this, we need to create a malicious application or write some adb commands. QARK provides these adb commands in its report as shown below.

We can install the target app on a device/emulator and run these commands on the PC.

Running QARK in seamless mode

Below is the command that can be used to run QARK in seamless mode. $ python qark.py –source 1 –pathtoapk ../testapp.apk –exploit 1 –install 1 This will do the same process of finding vulnerabilities without user intervention. If you are facing errors with building the POC app, set –exploit value to 0. If you don’t want it to be installed on the device set –install value to 0. python qark.py –source 1 –pathtoapk ../testapp.apk –exploit 0 –install 0 This will just perform the assessment and provide you a report without POC app as shown below.

Conclusion

QARK without a doubt is one of the best tools for Android SCA that is freely available. It requires having some more features such as providing adb commands for querying content providers, exploiting injection vulnerabilities, identifying insecure data storage vulnerabilities etc. According to their github page, some of them are about to come in its upcoming versions. So, let’s wait for more intelligent and powerful QARK. INFO – Zipfile: <zipfile.ZipFile object at 0x104ba0810> INFO – Extracted APK to /Users/srini0x00/Downloads/testapp/ INFO – Finding AndroidManifest.xml in /Users/srini0x00/Downloads/testapp INFO – AndroidManifest.xml found INFO – INFO – Determined minimum SDK version to be:8 WARNING – Logs are world readable on pre-4.1 devices. A malicious app could potentially retrieve sensitive data from the logs. ISSUES – APP COMPONENT ATTACK SURFACE WARNING – Backups enabled: Potential for data theft via local attacks via adb backup, if the device has USB debugging enabled (not common). More info: http://developer.android.com/reference/android/R.attr.html#allowBackup POTENTIAL VULNERABILITY – The android:debuggable flag is manually set to true in the AndroidManifest.xml. This will cause your application to be debuggable in production builds and can result in data leakage and other security issues. It is not necessary to set the android:debuggable flag in the manifest, it will be set appropriately automatically by the tools. More info: http://developer.android.com/guide/topics/manifest/application-element.html#debug . . . . . . ==>EXPORTED ACTIVITIES: 1com.isi.testapp.MainActivity adb shell am start -a “android.intent.action.MAIN” -n “com.isi.testapp/com.isi.testapp.MainActivity” 2com.isi.testapp.Welcome adb shell am start -n “com.isi.testapp/com.isi.testapp.Welcome” To view any sticky broadcasts on the device: adb shell dumpsys activity| grep sticky INFO – Support for other component types and dynamically adding extras is in the works, please check for updates An html report of the findings is located in : /Users/srini0x00/Downloads/qark-master/report/report.html Goodbye!