|
|
| Line 6: |
Line 6: |
| | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' |
| | __TOC__{{TOC hidden}} | | __TOC__{{TOC hidden}} |
| − | = Introduction =
| |
| | | | |
| − | This cheat sheet provides a checklist of tasks to be performed to do a penetration test of an Android application. It follows the [https://www.owasp.org/index.php/OWASP_Mobile_Security_Project OWASP Mobile Top 10 Risks] list.
| + | After an exchange with the leaders of the [https://github.com/OWASP/owasp-mstg OWASP Mobile Security Testing Guide (MSTG)] project, it was decided to replace the content of this cheat sheet by a reference to the dedicated content on the MSTG project. |
| | | | |
| − | == Testing Methodology ==
| + | The explanation is simple: |
| − | [[File:AndroidPenAssessment.png]]
| + | # It's an OWASP project too. |
| | + | # The MSTG project is active. |
| | + | # It focus on Android and iOS areas. |
| | + | # It provides good and up-to-date advices about how to handle mobile threats for the both platforms. |
| | + | # MSTG content came from various specialists in the mobile domain. |
| | | | |
| − | A complete android pen testing involves different areas such as the ones described in the above picture
| + | Consult this [https://github.com/OWASP/owasp-mstg#android-testing-guide section] for information about ANDROID platform. |
| − | | |
| − | ===Application Mapping===
| |
| − | 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:
| |
| − | # What is the application genre ? (Game, business, productivity etc)
| |
| − | # Does the application connect to backend web services?
| |
| − | # Is the application purely native or incorporates readymade frameworks?
| |
| − | # Does the application store data on the device?
| |
| − | # What all features of the device are used by the application? (camera, gyroscope, contacts etc)
| |
| − | | |
| − | ===Client Attacks===
| |
| − | 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.
| |
| − | | |
| − | ===Network Attacks===
| |
| − | 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.
| |
| − | | |
| − | ===Server Attacks===
| |
| − | 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.
| |
| − | | |
| − | ==Devices==
| |
| − | | |
| − | There are also different ways to pentest the application , and we should consider in which case we need to use one or the other
| |
| − | | |
| − | # With Android device running in a factory default or normal mode
| |
| − | # With Android device running in a rooted mode
| |
| − | | |
| − | At the application level, there are 2 ways in which it shall be tested
| |
| − | # Application running on the device (to take benefits of touch related features)
| |
| − | # Application running on the emulator (to ease the task of testing using wider screen of desktop or laptop)
| |
| − | | |
| − | = 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]==
| |
| − | * Check AndroidManifest.xml permissions [https://developer.android.com/reference/android/Manifest.permission.html configurations] certain permissions can be [https://developer.android.com/guide/topics/permissions/requesting.html#normal-dangerous dangerous]
| |
| − | *If application uses fingerprinting, test against different vulnerabilities related to this [https://www.blackhat.com/docs/us-15/materials/us-15-Zhang-Fingerprints-On-Mobile-Devices-Abusing-And-Leaking-wp.pdf feature]
| |
| − | | |
| − | == 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
| |
| − | | |
| − | * /data/data/app_folder
| |
| − | * /sdcard/
| |
| − | * /sdcard1/
| |
| − | | |
| − | 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.
| |
| − | | |
| − | # SQL / XML injection, and if the reading intent is publicly exposed another application could read this.
| |
| − | # Local file read which can allow other application to read files of the application in question and if they contain sensitive data then data leakage via this media.
| |
| − | | |
| − | 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===
| |
| − | * Identify all ssl endpoints.
| |
| − | * Perform SSL Cipher Scan using (sslscan)[https://github.com/rbsec/sslscan] or similar software.
| |
| − | * SSLv2, SSLv3 is disabled
| |
| − | * TLS 1.2 and 1.1 is supported (1.2 is essential to ensure highest possible secure connection)
| |
| − | * RC4 and CBC Based Ciphers are disabled
| |
| − | * DH Params are >2048 Bits
| |
| − | * SSL Certificate is signed with atleast sha2 / sha256
| |
| − | * ECDHE Ciphers / Ciphers supporting Perfect forward secrecy are preferred
| |
| − | * SSL Certificate is from Trusted RootCA
| |
| − | * SSL Certificate is not expired
| |
| − | *[https://developer.android.com/training/articles/security-tips.html#IPC Verify Interprocess communication implementation]
| |
| − | | |
| − | ===2. On Device Side===
| |
| − | * Ensure application is working correctly by navigating around.
| |
| − | * Put a proxy in between the application and remote server. If application fails to load. Application might be doing cert validation. Refer logcat if any message is printed.
| |
| − | * Place Proxy RootCA in trusted root CA list in device. (Burp)[https://support.portswigger.net/customer/portal/articles/1841101-configuring-an-android-device-to-work-with-burp] (OWASP-ZAP)[https://security.secure.force.com/security/tools/webapp/zapandroidsetup]
| |
| − | * Try using application again. If application still doesn't connect, application might be doing cert pinning.
| |
| − | You could bypass the certification pinning by Hooking or changing the Smali code:
| |
| − | | |
| − | ====Using Xposed:====
| |
| − | * Install (Xposed Framework)[http://repo.xposed.info/module/de.robv.android.xposed.installer] and (Just Trust Me)[https://github.com/Fuzion24/JustTrustMe], enable JustTrustMe and then reboot device.
| |
| − | * Try again if everything works we have a application which employs certification pinning and we have bypassed it using the xposed module.
| |
| − | * [https://developer.android.com/training/articles/security-gms-provider.html Android Security provider has been properly updated against SSL Exploits]
| |
| − | | |
| − | ====Changing SMALI:====
| |
| − | *Identify/search for the methods where the certificate pinning is implemented (keywords like 'sha256/' followed by a certificate value such as "sha256/wl0L/C04Advn5NQ/xefY1aCEHOref7f/Q+sScuDcvbg="
| |
| − | *Change the value of the certificates being used by the one used by you generated BURP certificate
| |
| − | | |
| − | == M4 - Insecure Authentication [Client/Server attacks]==
| |
| − | For this part some of the tools necessary in order to carry on the assessment are,
| |
| − | *attack proxies such as ZAP, BURP or Charles
| |
| − | *Wireshark for Traffic analysis
| |
| − | | |
| − | By analyzing the traffic (HTTP request/response) between client and server, check the following items
| |
| − | *Analyze session management and workflow
| |
| − | *Analyze API authentication using an attack proxy
| |
| − | *Insecure WebViews
| |
| − | *Check if Credentials are being stored in the Datastore or Server side
| |
| − | * Misuse or access to [https://developer.android.com/reference/android/accounts/AccountManager.html Account Manager]
| |
| − | *[https://docs.box.com/docs/android-security-guidelines#section-authenticating-callers-of-components Authenticating Callers of Components]
| |
| − | | |
| − | 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
| |
| − | * Check and validate Sessions on the Backend
| |
| − | * Check for session Timeout Protection
| |
| − | * Check for improper Cookies configuration
| |
| − | * Insecure Token Creation
| |
| − | *Insecure implementation of [https://developer.android.com/training/articles/security-tips.html#WebView WebView]
| |
| − | | |
| − | == 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:
| |
| − | *Type SSL/TLS encryption used
| |
| − | *Retrieving files securely using HTTPS URI or a secure tunnel such as implementing HttpsURLConnection or SSLSocket
| |
| − | *Authentication Session Tokens
| |
| − | *Data storage containing sensitive information in clear text
| |
| − | *Access to encryption keys or improper key management
| |
| − | * Usage of known weak crypto algo's like Rot13, MD4, MD5, RC2, RC4, SHA1
| |
| − | * Do it Yourself / let me design my own algo for encryption
| |
| − | * Secret key hard coded in the application code itself.
| |
| − | *Implementation of own protocol
| |
| − | *Insecure use of Random Generators
| |
| − | | |
| − | == 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:
| |
| − | *Handling credentials: does the application make use of authorization tokens instead of asking Credentials all the time?
| |
| − | *Verify that the application allows access only to the allowed roles
| |
| − | *Storing username and password in the data storage instead of using [https://developer.android.com/training/articles/security-tips.html AccountManager]
| |
| − | | |
| − | == M7 - Client Code Quality [Client Attacks]==
| |
| − | There are 2 approaches for this part:
| |
| − | *If you have access to the source code, doing code review on the Client app and the server API.
| |
| − | *If you don't, you could still check the code by decompiling the APK
| |
| − | | |
| − | 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
| |
| − | *Decompile APK using tools such as apktool, dex2jar / enjarify, Bytecodeviewer or commercial tools such as JEB
| |
| − | *Analyze code using decompiler such as JD-GUI or Bytecodeviewer. Commercial version such as JEB allows you to even debug the decompiled application but not in all cases
| |
| − | * After analyzing the code, attempt to bypass functionalities whether by changing the Smali code or Hooking methods using Xposed or Frida frameworks
| |
| − | * Verify if the application has been obfuscated and verify the level of obfuscation searching for specific strings.
| |
| − | *Decompile APK and change Smali, (check this tool which automates the process of decompiling , compiling and signing the application: https://github.com/voider1/a2scomp)
| |
| − | *Android Binaries are basically dex classes, which if not protected can result in an easy decompilation of source code. This could lead to code / logic leakage.
| |
| − | Following controls need to be checked for and validated:
| |
| − | | |
| − | * Jailbreak, Device Rooted- Detection Controls
| |
| − | * Checksum Controls
| |
| − | * Certificate Pinning Controls
| |
| − | * Debugger Detection Controls
| |
| − | *Xposed Detection Controls
| |
| − | *[https://developer.android.com/training/articles/security-tips.html#DynamicCode Dynamic loading code]
| |
| − | *[https://developer.android.com/training/articles/security-tips.html#Native use of Native code with Android NDK]
| |
| − | | |
| − | References
| |
| − | | |
| − | (OWASP M10-2014)[https://www.owasp.org/index.php/Mobile_Top_10_2014-M10]
| |
| − | | |
| − | == 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 :
| |
| − | *Android Studio with SDK tools installed
| |
| − | *A rooted Android Device or Emulator
| |
| − | *For a rooted emulator you can use CuckoDroid which has Xposed installed
| |
| − | *Different tools installed for decompiling the APK such as apktool,Dex2Jar / enjarify or if you are looking for a total one use Bytecodeviewer or JEB
| |
| − | *IDA pro (for analyzing code flow)
| |
| − | * Smali decompiler/compiler and signer : https://github.com/voider1/a2scomp
| |
| − | | |
| − | Verify that:
| |
| − | *Has the application be obfuscated?
| |
| − | *Search for key strings and keywords with tools like Bytecodeviewer or JEB
| |
| − | *Search for implantation of SSL pinning , Device rooted or connections to API's (search for words like 'TrustManager' , 'SHA256', X509 ,SHA, SSL , for more info see [https://docs.box.com/docs/android-security-guidelines Android Security Guidelines]
| |
| − | | |
| − | == 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 =
| |
| − | | |
| − | * Jonathan Carter
| |
| − | * Prashant Phatak
| |
| − | * Milan Singh Thakur
| |
| − | * Anant Shrivastava
| |
| − | * Johanna Curiel
| |
| | | | |
| | = Other Cheatsheets = | | = Other Cheatsheets = |
