Improper Platform Usage. This is the first in a series of articles about the most significant security risks lurking mobile applications, as defined on the OWASP Mobile Top 10 in 2016. The list describes the main categories of risks and vulnerabilities affecting mobile applications, as perceived by the industry and the community. This articles focuses on the first category of the list, M1- Improper Platform Usage.
Improper Platform Usage covers mainly the misusing of platform features or failing to use platform security controls provided and documented by the platform and it’s community[1]. On Android-based applications, the AndroidManifest,xml file is certainly a well a information about the platform configuration and how the application should behave, this file is, indeed, a must-check for security misconfiguration. Here, we will be using the InsecureBankv2 project, a purposely vulnerable Android application made for security enthusiasts and developers to learn about the Android insecurities by testing the vulnerable application. [2]
First we download the InsecureBankv2 project, but before firing up the emulator and install the application, let’s focus on getting access to the AndroidManifest.xml file and see what we have. For this, we will be using apktool[3], a tool designed for reverse engineering Android apks. The tool has several options, but we will be focusing on the decode option, which extracts and decodes resources within the apk, the tool produces a readable AndroidManifest.xml file and smali code for the application source code, you can use the tools as follows:
In the previous command, we set the d option for decode and the -o option to specify the output directory where we want to send the results. Now we navigate into the folder and see that the tool generated the AndroidManifest.xml as well as a resources and smali folders, for now we will be focusing on the manifest.
We open the AndroidManifest.xml and explore it’s contents, in this case we will be using nano text editor, as follows:
Insecure Components
One of the first things you should check in this configuration file is for the stuff inside the <application> tag, here you will find the components defined for this application, components are either activities, broadcast receivers, content providers or services, each of one with their own functionality and characteristics. In general, if you see several components with the exported flag set to true, this is most likely a a sign of misconfiguration and bad use of the platform. Here, it is important to point out that, even if a component does not have the exported flag, if an intent-filter is defined within the component, the exported flag is set to true by default.
Each component should be reviewed and analyzed to understand what they are used for and what information they may be sharing with other components. One very useful tool to help in this matters is the drozer framework, which allows you to search for security vulnerabilities in Android-based. You can find a comprehensive step by step guide on how to setup and use the drozer framework here.
First, let’s install the target apk (InsecureBankv2.apk) on the Android virtual device, we can do this using the Android Debug Bridge, as follows:
Now, let’s use the drozer framework to quickly analyze the package, first let’s find out the package name by running the app.package.list module with the -f option (search for string):
We can see that the package name is com.android.insecurebankv2. Let’s now explore the information about this package:
Let’s now check for components and it’s configuration by using the app.package.attacksurface command:
We can see there are a few exported activities along with one broadcast receiver and one content provider. Let’s now find some information about the activities by using the app.activity.info module:
Let’s try and access the PostLogin activity:
We can see the activity has come up on the virtual device:
Debuggable application
While building an application, a debugger is a developer’s best friend, it provides the ability to inspect the application code line by line as it executes, this helps identifying root causes of bugs and fixing them. Shipping your application with the debuggable flag on, however, represents a security risk to your application; this could allow an attacker to obtain access to sensitive information, control the application flow and gain code execution in the context of the debugged application. You can find more detailed information on how to exploit this vulnerability here.
Allow Backup
Allowing your application to be backed up may also lead to situations in which code injection can be achieved by an attacker with access to the device. Once the attacker has been able get a backup of the application, the header of the back up is separated from the content (code and resources), the content then is modified by injecting code or changing values of resources, the modified content is then appended to the unmodified header and push back into the device. [More here]
Conclusion
As per the OWASP Mobile Top 10 2016, Improper Platform Usage is the main risk affecting mobile applications in the world. This makes sense in the way that developers are mostly concerned with getting the application to work and, sometimes, misuse platform features or leave out specific security controls that could easily mitigate these risks. Developer security awareness is, therefore, one of the most effective components in building secure software.
[1]https://www.owasp.org/index.php/Mobile_Top_10_2016-M1-Improper_Platform_Usage
[2]https://github.com/dineshshetty/Android-InsecureBankv2
[3]https://ibotpeaches.github.io/Apktool/
sdhfsjdfsjdfsjdf