Android Testing Cheat Sheet
Last revision (mm/dd/yy): 03/3/2017
This cheat sheet provides a checklist of tasks to be performed to do a penetration test of an Android application. It follows the OWASP Mobile Top 10 Risks list.
In this first phase, the focus relies on understanding the application logic and what exactly the application does. This involves some manual test where we do some basic operations such as install the APK on the phone, login and comprehend the functionality of the app.
Map the application for possible security vectors such as:
This is one of the most challenging and exciting parts of the pentest assessment. Android apps are packed as an APK, also known as Android Package Kit or Android Application Package. Our mission as Pen testers is to verify how well protected the application has been created and designed against known threat actors.Android Mobile applications are distributed through platforms like Google Play. Since the application is fully installed on the client, it becomes vulnerable to any attacks coming from the client.
As we need to identify vulnerabilities in the Client, is also essential to verify how secure is the communication between the Client and the Server by evaluating the traffic. For this purpose, using tools like Attack proxies, evaluating potential SSL issues, and executing Wireshark Data package inspection is an essential part of the assessment.
Last but not least, issues at the Server level will impact the security of the application. Insecure implementation such as misconfigurations , vulnerabilities and issues at API or Database level, affect also the security of an application
At the device level, there are 2 ways in which the application shall be tested. Reverse Engineering is an essential part of pen testing mobile applications. It also requires the use of rooted devices. If you have been wondering why do we need to Reverse Engineer an installed APK, the major reason relies on the client.
There are also different ways to pentest the application , and we should consider in which case we need to use one or the other
At the application level, there are 2 ways in which it shall be tested
OWASP Step-by-step Approach
(For each of the standards below, there shall be multiple steps for the tester to follow])
M1 - Improper Platform Usage [Client Attacks]
M2 - Insecure Data storage [Client Attacks]
This Section should be ideally tested after using the application for some time. This way application has time to store some data on the disk. It will probably require the use of a rooted Android device in order to access files in Android such as '/sdcard' Commonplaces to look at
Android applications need to store data locally in sqlite files or XML structures and hence need to performs either SQL/XML Queries or file I/O.
This gives rise to 2 major issues.
If the application is a HTML5 hybrid application then Cross Site Scripting (XSS) should also be considered. XSS will expose the entire application to the attacker as HTML5 applications will have the ability to call native functionality and hence control over the entire application. (WebViews)
Additionally a backup of the application could be made using `adb backup` option and that can be analyzed to identify what the application stores and leaks when the client interacts with it.
M3 - Insufficient Transport Layer [Network/Traffic attacks]
Multiple layer of checks to be performed here
1. On Server side
2. On Device Side
You could bypass the certification pinning by Hooking or changing the Smali code:
M4 - Insecure Authentication [Client/Server attacks]
For this part some of the tools necessary in order to carry on the assessment are,
By analyzing the traffic (HTTP request/response) between client and server, check the following items
Improper Session Handling typically results in the same outcomes as poor authentication. Once you are authenticated and given a session, that session allows one access to the mobile application. There are multiple things to look at
M5 - Insufficient Cryptography [Client/Network/Server attacks]
For this part , you will need to perform a overall analysis where you can enumerate where encryption has been used. For example:
M6 - Insecure Authorization [Client/Server attacks]
After a proper Application mapping and understanding the data flow, you can verify the authorization mechanism for the following:
M7 - Client Code Quality [Client Attacks]
There are 2 approaches for this part:
We strongly recommend a Code Review in this case. This will definitely extract many potential vulnerabilities due to bad implementation
M8 - Code Tampering [Client Attacks]
For this part you will need a rooted device and reverse engineering techniques
Following controls need to be checked for and validated:
M9 -Reverse Engineering [Client attacks]
Reverse Engineering is an essential part of pen testing mobile applications. It also requires the use of rooted devices. For this part make sure that you have prepared the following tools :
M10 - Extraneous Functionality
For testing this part, it will be necessary to do a code review or Reverse engineer the APK (if code is not available)
Authors and Primary Editors