10 things you must do when Pentesting Android Applications.

Mobile applications are no doubt an important part of our lives nowadays. More and more, users want to have everything within arm’s reach and service providers are turning to mobile channels to satisfy these needs.

For the same reason, attackers are also turning their attention towards mobile channels; the more they are used, the more attractive target they become. In these days, specially Android-based systems are becoming a focus of attention for attackers looking not only to gain some kind of control over the device, but also to compromise user’s sensitive data, primarily banking and financial information, service providers and application developers in these fields should pay close attention to the security of their applications.

Now, let’s make something clear from the beginning, one thing is for users to adhere to best practices when using their mobile devices; like setting up strong device authentication or avoiding installations from unknown sources and other is application-specific security, we’ll be focusing on the latter here.

Application-specific security refers not to the security of the device itself but the security of the applications running on the device. And more precisely, we will see 10 things for application-specific security that you, as a penetration tester, should not miss for every Android application you assess.

Do note that this is not at all an exhaustive list of the things pentesters should concern themselves with when assessing Android mobile applicaitons, but it is, in my opinion, a decent start. Let’s get to it:

1. Reverse engineer the application

One of the first things we would do is to start with some static analysis, this part is pretty straight forward, you would use a tool like apktool (in case of Android) to reverse engineer the application and check what resources the application is using.

Here, you should check for any configuration files, libraries used by the application and any other static resource that may seem valuable; a couple of files to keep an eye on are the AndroidManifest.xml and the @xml/network_security_config.xml files. More on reverse engineering here.

2. Analyze AndroidManifest.xml

On Android applications, the AndroidManifest.xml file contains a well of information about the application and how it behaves, most of the important configuration will be done through this file.

One of the things you should note here is the package name, which you might be needing in the future for other checks. You should also note the minimum SDK the application can be installed on, too low versions may expose the application to security issues of those old versions.

Application permissions should also be analyzed to see what kind of things the application is allowed to do and if, in fact, the applications needs all the permissions it requests. Permissions like reading/writing to external storage as well as SMS, Calls and Contacts should be analyzed. You should also check if the networkSecurityConfig field is set and note what file is been used for network configuration.

Components should also be carefully analyzed (although at this point we are just noting them); activities, services, broadcast receivers and service providers that are exported (either by exported=”True” or by declaring an <intent-filter>) should be of special interest.

Also important is to note if the application allows to be debugged (debuggable=”true”) and allows to be backed up (allowBackup=”True” or not specifically set to false), any of these flags set to true may represent a risk to the application.

3. Decompile the application

By decompiling the application you can first check whether or not any obfuscation was applied and analyze the code to understand how the application works to identify possible weaknesses.

In case of Android applications, you first need to extract the .dex file (which contains the application code) and use a tool like d2j-dex2jar to convert the Dalvik Executable code (.dex) to a Java archive ( .jar). After this, you need to to decompile the .jar file into a more human readable code with a Java decompiler , using jd-gui for instance, you can get code very similar to the original Java code. More on decompiling applications here.

One of the main thing you will check here is the code for each Android component (services, receivers & providers) that the application defines and uses to exchange information.

4. Check local storage

Often times, applications save information in the local storage, on application files (/data/data/app) or even on the SDCard itself; you should review both locations for any sensitive data.

To do this, you would use ADB (Android Debug Bridge) to first install the application and then access the device’s file system in order to check for any sensitive information. Do note that it’s important to interact with the application, as sensitive information may be written only after that.

Files, sqlite3 databases, shared preferences, libraries and keystores should be of special concern as they are usually used for storing data that may be sensitive. More on insecure data storage here.

5. Checks the logs

If configured insecurely, applications may leak sensitive information into the logs, this information may be at risk, for instance, because of malicious applications. A pentester should make sure to thoroughly review the application logs for any valuable information

To check the Android logs, you can use logcat; a tool to dump the system and application logs, you can dump logs into a file or review them in real-time to find any sensitive information. Here is more on using logcat to check logs.

6. Checks the memory

Sensitive information (like passwords, credit cards, etc) should stay in the application memory the least amount of time possible. Some threats may be able to dump application memory and scrap it for any sensitive data.

For instance, when using a String to hold a user password, even if you “clean” the variable by setting an empty or different value, the memory will still contain the password value, since Strings are immutable, in such cases, you should use a char array instead.

To analyze the memory, you need to first dump it, for that you would use the Android Monitor; which let’s monitor the device and all the applications running on it. Once dumped, you would use the hprof-conv tool to convert the dumped file into a file that can be analyzed with the Eclipse MAT (memory analyze tool). Here you can see more on Dumping and Analyzing Application Memory.

7. Check network communication

Network communication is an important check for mobile applications. A man-in-the-middle attack could seriously compromise the information of a user, files like the network_security_config.xml can shed some light on the security of the communication.

But it’s only after manually testing that you can make sure that security controls like SSL Pinning are in place and working correctly. First thing you would try to do is route the application traffic through a proxy, for which you may need to first install the proxy’s certificate on the device; whether the device trusts user-installed certificates by default depends on which Android version you are using (24 and above do not trust by default) and also on how the network_security_config is set up. If you are able to intercept the traffic at this point, there is serious security issue on the application.

When assessing a mobile application, verifying that it has SSL Pinning enabled is a requirement, but, what happens when you need to bypass this control, for instance, to test the endpoint (i.e. Webservice) the application communicates with. In such cases, a framework like Frida comes in very handy, I have written a couple of articles about using frida and the frida-gadget, make sure to check them out.

8. Android components

As mentioned before, all Android components (activities, services, receivers and providers) should be reviewed and analyzed to understand how they work.

Understanding what activities can be directly accessed, what information other components might be exchanging through IPC (Inter Process Communication) and what weaknesses (like SQL Injections) may be affecting this exchanges are only a few checks you need to consider.

A tool like the drozer framework can be very helpful in this section; drozer comes in two parts, the server installed on the device and the client installed on the workstation, more on using drozer

9. Masking of sensitive data

Whenever sensitive information is displayed on the screen, this information should be masked to avoid disclosure, for instance, if the application is displaying Credit Card numbers, these numbers should be masked.

Sensitive information should also be masked when taking screenshots or when setting the application into the background (by setting the FLAG_SECURE for instance).

10. Root checks

Applications should check if they are been installed on rooted devices, in such cases, the application should at least give notice the user and letting them know that running the application on a rooted device represents a security risk to their private information.

Conclusion

Mobile risks are on the rise, attackers are more and more focusing their attention on mobile channels in order to gain access to sensitive user data. Service providers and application developers for mobile applications should concerns themselves more with creating and delivering secure applications to their clients.