Complete Guide for Mobile Application Pentesting Use cases

Akash Venky
14 min readMar 23, 2023

--

ಹುಟ್ಟು ಹಬ್ಬದ ಶುಭಾಶಯಗಳು ವಿನಯ್ ಅಣ್ಣ

This WriteUp is dedicated to my Brother Vinay HC …!!!! Happy BirthDay…!!!

What is Mobile Application Pentesting?

The mobile application pen testing methodology is a systematic approach to searching for weaknesses or loopholes in an Mobile Developmented Apps such as Android,iOS or Windows Apps else in simple common lang, Before the Applications gets hacked by any malicious hackers. Hack the Mobile App and idetenfy the root path and inform the team about the loophole and help them to make the app to get “cyberSafe”

Types of Mobile Application Pentesting

  1. Android Applications (GooglePlay Store)
  2. iOS Applications (Apple Store)
  3. Windows Applications (Windows Store)

Important tools that can be used for Mobile PT

  • Appie — A portable software package for Android Pentesting and an awesome alternative to existing Virtual machines.
  • Android Tamer — Android Tamer is a Virtual / Live Platform for Android Security professionals.
  • Androl4b — A Virtual Machine For Assessing Android applications, Reverse Engineering and Malware Analysis
  • Vezir Project — Mobile Application Pentesting and Malware Analysis Environment.
  • Mobexler — Mobexler is a customised virtual machine, designed to help in penetration testing of Android & iOS applications.
  • Mobile Security Framework — MobSF — Mobile Security Framework is an intelligent, all-in-one open source mobile application (Android/iOS) automated pen-testing framework capable of performing static and dynamic analysis.
  • Objection — Objection is a runtime mobile exploration toolkit, powered by Frida. It was built with the aim of helping assess mobile applications and their security posture without the need for a jailbroken or rooted mobile device.
  • APKTool — A tool for reverse engineering 3rd party, closed, binary Android apps. It can decode resources to nearly original form and rebuild them after making some modifications.
  • Bytecode Viewer — Bytecode Viewer is an Advanced Lightweight Java Bytecode Viewer, It’s written completely in Java, and it’s open sourced.
  • Jadx — Dex to Java decompiler: Command line and GUI tools for produce Java source code from Android Dex and Apk files.
  • APK Studio — Open-source, cross platform Qt based IDE for reverse-engineering Android application packages.
  • Drozer — Drozer allows you to search for security vulnerabilities in apps and devices by assuming the role of an app and interacting with the Dalvik VM, other apps’ IPC endpoints and the underlying OS.
  • AndroBugs — AndroBugs Framework is an efficient Android vulnerability scanner that helps developers or hackers find potential security vulnerabilities in Android applications. No need to install on Windows.
  • For the Network and tcp/udp analysis many tools such as burp,wireshark,fiddler etc can be used
  • Android backup extractor — Utility to extract and repack Android backups created with adb backup (ICS+). Largely based on BackupManagerService.java from AOSP. and Many More …..!!!!!

What is dvm in android

On an Android device, the DVM compiles the Java code to an intermediate format called Java bytecode (. class file) like the JVM.

Then, with the help of a tool called Dalvik eXchange or dx, it transforms Java bytecode to Dalvik bytecode. Finally, the DVM translates the Dalvik bytecode to binary machine code.

The various factors which are relevant in Non-functional testing/Security Pentesting(Mobile PT) are:-

  1. Type of application based upon the business functionality usages (banking, gaming, social or business,Ecommerce etc)
  2. Target audience /End Users type (consumer, enterprise, education)
  3. Distribution channel which is used to spread the application (e.g. Apple App Store, Google play, direct distribution)

Security Testing Test Cases

The fundamental objective of security testing is to ensure that the application’s data and networking security requirements are met as per guidelines.

The following are the most crucial areas for checking the security of Mobile applications.

  1. To validate that the application is able to withstand any brute force attack which is an automated process of trial and error used to guess a person’s username, password or credit-card number.
  2. To validate whether an application is not permitting an attacker to access sensitive content or functionality without proper authentication.
  3. To validate that the application has a strong password protection system and it does not permit an attacker to obtain, change or recover another user’s password.
  4. To validate that the application does not suffer from insufficient session expiration.
  5. To identify the dynamic dependencies and take measures to prevent any attacker for accessing these vulnerabilities.
  6. To prevent from SQL injection related attacks.
  7. To identify and recover from any unmanaged code scenarios.
  8. To ensure whether the certificates are validated, does the application implement Certificate Pinning or not.
  9. To protect the application and the network from the denial of service attacks.
  10. To analyze the data storage and data validation requirements.
  11. To enable the session management for preventing unauthorized users to access unsolicited information.
  12. To check if any cryptography code is broken and ensure that it is repaired.
  13. To validate whether the business logic implementation is secured and not vulnerable to any attack from outside.
  14. To analyze file system interactions, determine any vulnerability and correct these problems.
  15. To validate the protocol handlers for example trying to reconfigure the default landing page for the application using a malicious iframe.
  16. To protect against malicious client side injections.
  17. To protect against malicious runtime injections.
  18. To investigate file caching and prevent any malicious possibilities from the same.
  19. To prevent from insecure data storage in the keyboard cache of the applications.
  20. To investigate cookies and preventing any malicious deeds from the cookies.
  21. To provide regular audits for data protection analysis.
  22. Investigate custom created files and preventing any malicious deeds from the custom created files.
  23. To prevent from buffer overflows and memory corruption cases.
  24. To analyze different data streams and preventing any vulnerabilities from these.

Usability Testing Test Cases

The usability testing process of the Mobile application is performed to have a quick and easy step application with less functionality than a slow and difficult application with many features. The main objective is to ensure that we end up having an easy-to-use, intuitive and similar to industry-accepted interfaces which are widely used.

  1. To ensure that the buttons should have the required size and be suitable to big fingers.
  2. To ensure that the buttons are placed in the same section of the screen to avoid confusion to the end users.
  3. To ensure that the icons are natural and consistent with the application.
  4. To ensure that the buttons, which have the same function should also have the same color.
  5. To ensure that the validation for the tapping zoom-in and zoom-out facilities should be enabled.
  6. To ensure that the keyboard input can be minimized in an appropriate manner.
  7. To ensure that the application provides a method for going back or undoing an action, on touching the wrong item, within an acceptable duration.
  8. To ensure that the contextual menus are not overloaded because it has to be used quickly.
  9. To ensure that the text is kept simple and clear to be visible to the users.
  10. To ensure that the short sentences and paragraphs are readable to the end users.
  11. To ensure that the font size is big enough to be readable and not too big or too small.
  12. To validate the application prompts the user whenever the user starts downloading a large amount of data which may be not conducive for the application performance.
  13. To validate that the closing of the application is performed from different states and verify if it re-opens in the same state.
  14. To ensure that all strings are converted into appropriate languages whenever a language translation facility is available.
  15. To ensure that the application items are always synchronized according to the user actions.
  16. To ensure that the end user is provided with a user manual which helps the end user to understand and operate the application who may be not familiar with the application’s proceedings

Usability testing is normally performed by manual users since only human beings can understand the sensibility and comfort ability of the other users.

Compatibility Testing Test Cases

Compatibility testing on mobile devices is performed to ensure that since mobile devices have different size, resolution, screen, version and hardware so the application should be tested across all the devices to ensure that the application works as desired.

The following are the most prominent areas for compatibility testing.

  1. To validate that the user Interface of the application is as per the screen size of the device, no text/control is partially invisible or inaccessible.
  2. To ensure that the text is readable for all users for the application.
  3. To ensure that the call/alarm functionality is enabled whenever the application is running. The application is minimized or suspended on the event of a call and then whenever the call stops the application is resumed.

Recoverability Testing Test Cases

  1. Crash recovery and transaction interruptions
  2. Validation of the effective application recovery situation post unexpected interruption/crash scenarios.
  3. Verification of how the application handles a transaction during a power failure (i.e. Battery dies or a sudden manual shutdown of the device)
  4. The validation of the process where the connection is suspended, the system needs to re-establish for recovering the data directly affected by the suspended connection.

Important Checklist

  1. Installation testing (whether the application can be installed in a reasonable amount of time and with required criterion)
  2. Uninstallation testing (whether the application can be uninstalled in a reasonable amount of time and with required criterion)
  3. Network test cases (validation of whether the network is performing under required load or not, whether the network is able to support all the necessary applications during the testing procedures)
  4. Check Unmapped keys
  5. Check application splash screen
  6. Continued keypad entry during interrupts and other times like network issues
  7. Methods which deal with exiting the application
  8. Charger effect while an application is running in the background
  9. Low battery and high performance demand
  10. Removal of battery while an application is being performed
  11. Consumption of battery by application
  12. Check Application side effects

BARE Minimum Compulsory Usecase

  1. To validate whether all the required mandatory fields are working as required.(ie App is fully developed and functional )
  2. To validate that the mandatory fields are displayed in the screen in a distinctive way than the non-mandatory fields. (Any Additional UI Backend Source code data Exposed)
  3. To validate whether the application works as per as requirement whenever the application starts/stops. (Checking for sudden stopping issue at cache level)
  4. To validate whether the application goes into minimized mode whenever there is an incoming phone call. (In order to validate the same we need to use a second phone, to call the device.)
  5. To validate whether the phone is able to store, process and receive SMS whenever the app is running and also during the Phone Call. (In order to validate the same we need to use a second phone to send sms to the device which is being tested and where the application under test is currently running.)
  6. To validate that the device is able to perform required multitasking requirements whenever it is necessary to do so.
  7. To validate that the application uses necessary social network options such as sharing, posting and navigation etc.
  8. To validate that the application supports any payment gateway transaction such as Visa, Mastercard, Paypal etc as required by the application.
  9. To validate that the page scrolling scenarios are being enabled in the application as necessary.
  10. To validate that the navigation between relevant modules in the application are as per the requirement.
  11. To validate that the truncation errors are absolutely to an affordable limit.
  12. To validate that the user receives an appropriate error message like “Network error. Please try after some time” whenever there is any network error.
  13. To validate that the installed application enables other applications to perform satisfactorily, and it does not eat into the memory of the other applications.
  14. To validate that the application resumes at the last operation in case of a hard reboot or system crash.
  15. To validate whether the installation of the application can be done smoothly provided the user has the necessary resources and it does not lead to any significant errors.
  16. To validate that the application performs auto start facility according to the requirements.
  17. To validate whether the application performs according to the requirement in all versions of Mobile that is 2g, 3g and 4g.
  18. To perform Regression Testing to uncover new software bugs in existing areas of a system after changes have been made to them. Also rerun previously performed tests to determine that the program behavior has not changed due to the changes.
  19. To validate whether the application provides an available user guide for those who are not familiar to the app

Performance based Use Cases

This type of testing’s fundamental objective is to ensure that the application performs acceptably under certain performance requirements such as access by a huge number of users or the removal of a key infrastructure part like a database server.

The general test scenarios for Performance Testing in a Mobile application are:

  1. To determine whether the application performs as per the requirement under different load conditions.
  2. To determine whether the current network coverage is able to support the application at peak, average and minimum user levels.
  3. To determine whether the existing client-server configuration setup provides the required optimum performance level.
  4. To identify the various application and infrastructure bottlenecks which prevent the application to perform at the required acceptability levels.
  5. To validate whether the response time of the application is as per as the requirements.
  6. To evaluate product and/or hardware to determine if it can handle projected load volumes.
  7. To evaluate whether the battery life can support the application to perform under projected load volumes.
  8. To validate application performance when network is changed to WIFI from 2G/3G or vice versa.
  9. To validate each of the required the CPU cycle is optimization
  10. To validate that the battery consumption, memory leaks, resources like GPS, Camera performance is well within required guidelines.
  11. To validate the application longevity whenever the user load is rigorous.
  12. To validate the network performance while moving around with the device.
  13. To validate the application performance when only intermittent phases of connectivity is required.

Common Frequently seen vulnerabilites of Mobile Pentesting

  1. Firebase DB injection
  2. Static Vulnerabilities detections from manifest files
  3. Web view implementation related vulnerabilities
  4. Insecure data storage
  5. Improper screenshots allowing
  6. Improper Authentications
  7. configurations errors
  8. XML External Entities
  9. Android Intent Sniffing
  10. iOS Keychain Risk
  11. Compromised File System
  12. Input Form Factor
  13. Access Encrypted Files
  14. Content Provider
  15. Checksum Changes
  16. Code Stealing
  17. Root Level Detections
  18. UserName Enumerations
  19. Session Expiry
  20. Application Cache Level Misconfig`s

For more vulnerabilities and CVE`s of Mobile Applications Visit Here

Examples of Owasp Top 10 2016 Mobile Pentesting

M1: Improper Platform Usage

App Local Storage Instead of Keychain The iOS Keychain is a secure storage facility for both app and system data. On iOS, apps should use it to store any small data that has security significance (session keys, passwords, device enrolment data, etc.). A common mistake is to store such items in app local storage. Data stored in app local storage is available in unencrypted iTunes backups (e.g., on the user’s computer).

M2: Insecure Data Storage

iGoat is a purposefully vulnerable mobile app for the security community to explore these types of vulnerabilities first hand. In the exercise below, we enter our credentials and log in to the fake bank app. Then, we navigate to the file system. Within the applications directory, we can see a database called “credentials.sqlite”. Exploring this database reveals that the application is storing our username and credentials (Jason:pleasedontstoremebro!) in plain text.

M3: Insecure Communication

Lack of certificate inspection

The mobile app and an endpoint successfully connect and perform a TLS handshake to establish a secure channel. However, the mobile app fails to inspect the certificate offered by the server and the mobile app unconditionally accepts any certificate offered to it by the server. This destroys any mutual authentication capability between the mobile app and the endpoint. The mobile app is susceptible to man-in-the-middle attacks through a TLS proxy. and also Weak handshake negotiation and Privacy information leakage comes under here.

M4: Insecure Authentication

Hidden Service Requests: Developers assume that only authenticated users will be able to generate a service request that the mobile app submits to its backend for processing. During the processing of the request, the server code does not verify that the incoming request is associated with a known user. Hence, adversaries submit service requests to the back-end service and anonymously execute functionality that affects legitimate users of the solution.

M5: Insufficient Cryptography

There are two fundamental ways that broken cryptography is manifested within mobile apps. First, the mobile app may use a process behind the encryption / decryption that is fundamentally flawed and can be exploited by the adversary to decrypt sensitive data. Second, the mobile app may implement or leverage an encryption / decryption algorithm that is weak in nature and can be directly decrypted by the adversary.

M6: Insecure Authorization

Insecure Direct Object Reference:

A user makes an API endpoint request to a backend REST API that includes an actor ID and an oAuth bearer token. The user includes their actor ID as part of the incoming URL and includes the access token as a standard header in the request. The backend verifies the presence of the bearer token but fails to validate the actor ID associated with the bearer token. As a result, the user can tweak the actor ID and attain account information of other users as part of the REST API request. and also misconfigured LDAP Rules and Roles…!!!

M7: Poor Code Quality

The attacks Such as BufferOverFlows, ratelimits, Execption errors data leakages etc

M8: Code Tampering

Games are a particularly popular target to attack using this method. The attacker will attract people that are not interested in paying for any freemium features of the game. Within the code, the attacker short-circuits conditional jumps that detect whether an in-application purchase is successful. This bypass allows the victim to attain game artifacts or new abilities without paying for them. The attacker has also inserted spyware that will steal the identity of the user.

M9: Reverse Engineering

Breaking up the internal files structure of app and Performing the CRED operations and recompling and running it.

Also, The attacker runs ‘strings’ against the unencrypted app. As a result of the string table analysis, the attacker discovers a hardcoded connectivity string that contains authentication credentials to a backend database. The attacker uses those credentials to gain access to the database. The attacker steals a vast array of PII data about the app’s users.

M10: Extraneous Functionality

An attacker tries manually added “debug=true” to a .properties file in a local app. Upon startup, the application is outputting log files that are overly descriptive and helpful to the attacker in understanding the backend systems. The attacker subsequently discovers vulnerabilities within the backend system as a result of the log.

The developers should have prevented the activation of ‘debug mode’ within a production build of the mobile app. and also exposing the Admin portals is also comes under this section…!!!

The Next Level of Detailed Usecase of Mobile PT will be released in the next WriteUP….!!!! Follow me to StayUpdated…!!!

Suggestions are most welcomed,

Please write a mail to Akash.venky091@gmail.com, Also you can follow me here for more updates on Security, Ethical hacking at Akash Venky or contact me @ https://www.linkedin.com/in/akash-h-c-4a4090a7/

--

--