Introduction
Recently, I researched Android application testing and found that the OWASP article is quite systematic, so I translated it to share with everyone. The translation in this article aims to maintain the original format as much as possible, but some modifications were made for fluency and understanding. If there are any translation issues, please feel free to point them out. The version during translation is 20170911, and subsequent updates will also be followed up if there are significant changes.
Overview
This quick reference guide provides a checklist for conducting Android application testing. It mainly describes the top ten mobile security issues according to OWASP.
1.1. Testing Methodology
A complete Android application penetration test involves several different areas, as shown in the image above.
1.1.1. Application Architecture
In this area, the focus is on understanding the application logic and what the application actually does. This includes some manual testing items, where we will perform basic operations such as installing the APK on the phone, logging in, and understanding the APP’s functionalities.
Understand the application architecture and look for potential attack vectors, such as:
1. What type of application is it? (Game, business, productivity, etc.)
2. Does the application connect to backend web services?
3. Is the application entirely custom-built or does it use existing frameworks?
4. Does the application store data on the device?
5. What features of the device does the application use? (Camera, gyroscope, contacts, etc.)
1.1.2. Client-Side Attacks
This is the most challenging and exciting part of the penetration testing process. Android apps are packaged into APK files, also known as Android Package Kit or Android Application Package. It is the penetration tester’s task to confirm whether the existing protective mechanisms are effective when the application faces known attack vectors. Android mobile applications are typically distributed through platforms such as Google Play. Once the application is fully installed on the client side, it must withstand any kind of attack from the client.
1.1.3. Network Attacks
Just as we need to identify vulnerabilities on the client side, it is also essential to analyze traffic to confirm whether the communication between the client and server is secure. To achieve this, using proxy tools, assessing potential SSL issues, and analyzing Wireshark packet capture files are necessary components of the evaluation work.
1.1.4. Server-Side Attacks
Last but not least, issues at the server level can also affect the security of the application. Some insecure implementations, such as misconfigurations, vulnerabilities, and issues at the API or database level, can also impact the security of the application.
At the device level, the application needs to be tested in two ways. Reverse engineering is a necessary part of mobile application testing. This requires a device that has been rooted. If you are confused about why we need to reverse-engineer an installed APK, the main reason lies on the client side.
1.2. Devices
There are also two methods to test applications, and we need to consider which method to use during testing.
1. Test Android devices running in factory or normal mode
2. Test Android devices running in ROOT mode
At the application level, testing should be conducted in two ways:
1. The application runs on real devices (beneficial for testing touch-related features)
2. The application runs on emulators (using a large screen of a desktop or laptop is beneficial for testing)
OWASP Getting Started Guide
For each of the following standards, testers should follow multiple steps for testing.
2.1. M1-Platform Misuse [Client-Side Attacks]
l Check the AndroidManifest.xml permission configuration; certain permissions may be dangerous.
l If the application uses fingerprint recognition, test different vulnerabilities based on this feature. Refer to https://www.blackhat.com/docs/us-15/materials/us-15-Zhang-Fingerprints-On-Mobile-Devices-Abusing-And-Leaking-wp.pdf
2.2. M2-Insecure Data Storage [Client-Side Attacks]
This part of the test should be conducted after using the application for some time to allow for thorough testing. This method requires the application to have time to store some data on disk. This may require a rooted Android device to access common paths in Android, such as ‘/sdcard’.
/data/data/app_folder/sdcard//sdcard1/Android applications need to store data locally in SQLite or XML structures, so SQL/XML queries need to be executed or file I/O monitored.
This could lead to two main threats.
1. SQL/XML injection, and if the target read is public, another application may also read this data.
2. Local file reading may allow other applications to read relevant application files; if they contain sensitive data, that data may be leaked through this route.
If the application is an HTML5 hybrid application, cross-site scripting (XSS) issues also need to be considered. XSS can expose the entire application to attackers because HTML5 applications can call native functions, thus controlling the entire application (WebView).
Additionally, applications can use the “adb backup” option to create a backup of the application; by analyzing the backup contents, one can identify what the application stored and leaked when interacting with the client.
2.3. M3-Inadequate Network Layer Protection [Network/Traffic Attacks]
Here are methods for testing different layers.
2.3.1. Server Side
l Identify all SSL endpoints.
l Use (sslscan) or similar software to identify SSL encryption methods.
l Check if SSLv2, SSLv3 are disabled.
l Check if TLS1.2 and 1.1 are supported (1.2 is crucial for ensuring the highest possible secure connection).
l Check if RC4 and CBC-based encryption algorithms are disabled.
l DH parameters should be >2048 bits.
l SSL certificates should be signed using at least sha2/sha256.
l ECDHE keys should support perfect forward secrecy.
l SSL certificates should be issued by a trusted RootCA.
l SSL certificates should not be expired.
l Verify if inter-process communication implementations have issues.
2.3.2. Device Side
l Confirm that the application works properly through browsing.
l Set a proxy between the application and the remote server. If the application fails to load, it may have performed certificate validation. Pay attention to logcat (note: logcat is a command-line tool in Android used to obtain program log information) for any message outputs.
l Add the RootCA certificate used by the proxy to the device’s trusted RootCA list.
l Try using the application again. If the application still cannot connect, it may have used certificate binding.
You can bypass certificate binding by intercepting or modifying Smali code.
2.3.2.1. Using Xposed:
l Install the Xposed Framework and the Just Trust Me module (used to disable SSL certificate verification), enable JustTrustMe, and then restart the device.
l Try again. If everything works well, we have successfully bypassed certificate binding using the Xposed module.
l Currently, Android’s security provider has been properly updated for SSL vulnerabilities.
2.3.2.2. Modify SMALI:
l Identify/search for methods that implement certificate binding (look for keywords like ‘sha256/’ followed by certificate values similar to “sha256/wl0L/C04Advn5NQ/xefY1aCEHOref7f/Q+sScuDcvbg=”).
l Change the certificate binding value to correspond with the value of the BURP certificate you are using.
2.4. M4-Insecure Authentication [Client/Server-Side Attacks]
In this part of the test, some necessary tools are required for evaluation.
l Proxy tools such as ZAP, BURP, or Charles.
l Wireshark for traffic analysis.
By analyzing traffic between the client and server (HTTP requests/responses), pay attention to the following items:
l Analyze session management and workflows.
l Use proxies to analyze API authentication.
l Insecure WebView.
l Check if credentials are stored in data storage or server-side.
l Abuse or access AccountManager (Android’s user management class).
l Authenticating Callers component calls.
Incorrect session handling often leads to the same results as poor authentication. When you authenticate and are given session information, this session information allows you to access the mobile application. There are many things to pay attention to here:
l Check and validate backend sessions.
l Check session timeout protection.
l Check incorrect Cookie configurations.
l Insecure token creation.
l Insecure WebView implementations.
2.5. M5-Inadequate Encryption [Client/Network/Server-Side Attacks]
In this part, you need to enumerate the places where encryption is used for a comprehensive analysis. For example:
Using SSL/TLS encryption types:
l Use HTTPS URLs or secure channels such as implementing HttpsURLConnection or SSLSocket.
l Authenticate session tokens.
l Store sensitive information in plaintext in data storage.
l Access encryption keys or incorrect key management.
l Use known weak encryption algorithms such as Rot13, MD4, MD5, RC2, RC4, SHA1.
l Self-made or self-designed encryption algorithms.
l Hardcoded keys in program code.
l Use proprietary protocols.
l Insecure use of random number generators.
2.6. M6-Insecure Authorization [Client/Server-Side Attacks]
After understanding the application architecture and data flow, the authorization mechanism can be verified as follows:
l Credential handling: Does the application use authorization tokens instead of always asking for credentials?
l Verify whether the application only allows specified roles to access.
l Store usernames and passwords in data storage instead of using AccountManager.
2.7. M7-Client Code Quality [Client-Side Attacks]
There are two methods for this part:
l If you have access to the source code, conduct a code audit on the client code and server API.
l If you cannot access the source code, you can check the code by decompiling the APK file.
In this case, we strongly recommend conducting a code audit. Due to incorrect implementations, there are likely many potential vulnerabilities here.
2.8. M8-Code Tampering [Client-Side Attacks]
This part requires a rooted device and reverse engineering skills.
l Use tools such as apktool, dex2jar/enjarify, Bytecodeviewer, or commercial tools like JEB to decompile the APK file.
l Use decompilers like JD-GUI or Bytecodeviewer to analyze the code. Commercial tools like JEB even allow you to debug the decompiled application, although this is not always possible.
l After analyzing the code, attempt to bypass various functionalities, whether by modifying Smali code using Xposed or Frida frameworks or intercepting method implementations.
l Verify whether the application has been obfuscated and check the obfuscation level by searching for specific strings.
l Decompile the APK and modify Smali (using this tool, which can automatically decompile, compile, and sign applications. https://github.com/voider1/a2scomp).
l Android binaries are essentially dex classes, which can be directly decompiled into source code without protection.
Check and verify whether the following restrictions are in place:
l Jailbroken, Rooted device – detection restrictions.
l Checksum restrictions.
l Certificate binding restrictions.
l Debugger detection restrictions.
l Xposed detection restrictions.
l Dynamic code loading.
l Use of native code in Android NDK.
2.9. M9-Reverse Engineering [Client-Side Attacks]
Reverse engineering is a necessary part of mobile application testing. It also requires a rooted device. For this part of the testing, ensure you have prepared the following tools:
l Android Studio with installed SDK tools.
l A rooted Android device or emulator.
l A rooted Android emulator can use CuckoDroid with Xposed installed.
l Various APK decompilation tools such as apktool, Dex2Jar/enjarify, or if you choose an integrated environment, Bytecodeviewer or JEB.
l IDA pro (for analyzing code flow).
l Smali decompiler/compiler and signing tool: https://github.com/voider1/a2scomp.
Verify the following issues:
l Has the application been obfuscated?
l Use tools like Bytecodeviewer or JEB to find key strings and keywords.
l Search for SSL certificate binding implementations, device root privilege acquisition, or API connections (look for keywords such as ‘TrustManager’, ‘SHA256’, X509, SHA, SSL, for more details, please refer to the Android security overview https://developer.box.com/docs/android-security-guidelines).
2.10. M10-Excessive Functionality
Testing this part requires code auditing or reverse engineering the APK (if the code cannot be obtained).
Authors and Main Editors
l Jonathan Carter
l Prashant Phatak
l Milan Singh Thakur
l Anant Shrivastava
l Johanna Curiel
*Source: OWASP Foundation, please indicate the source from FreeBuf.COM
