How to hack an app: 8 best practices for pen testing mobile apps

Mobile applications are here to stay. They've become an essential part of our lives as our dependence on our smartphones has grown. But when it comes to security, users are like sitting ducks. Arxan said in a recent study on the state of application security that "84 percent of mobile app users ... believe that their mobile health and finance apps are adequately secure."

Truth is, security can be a false perception if we do not know how our applications were developed and penetration tested. The reality is that downloading and using these applications can represent a potential risk to both you and your organization, given that untested apps may contain security bugs that can make your data vulnerable. Unfortunately, the Arxan report notes that a majority of mobile and health applications contain serious security vulnerabilities. 

Download 22-Page GuideApp Security Buyer's Guide + Sample RFP

One way to avoid this risk is to make sure that mobile apps have been properly pen tested against security vulnerabilities. Penetration testing can provide us with a certain level of confidence, but hacking into mobile applications demands a different approach and setup than with web applications. 

As with web applications, mobile apps suffer from many forms of security vulnerabilities. These vulnerabilities, however, are not that different from the web kind. The OWASP Top Ten Project also applies in all its form to mobile apps. SQL injections are a well-known vulnerability present in web applications, and they affect mobile apps. When this data is served through a thin client connecting to a web XML service, the security provided through the client and the server will depend mostly on how well it was developed and tested. In contrast, with mobile apps, where their data is mainly stored client side, you need to take a different security approach to protect them.  

In any case, the mobile application hosted or installed on the device and its security will be affected by the way the implementations were done. When we talk about assessing risks, the OWASP Mobile Top Ten gives us a great overview of the security threats that most mobile apps suffer. Here are eight best practices to help you fight back against mobile hacks with penetration testing.

1. Preparing the security testing plan

One of the challenges of pen testing mobile applications involves applying the correct methodology. The OWASP iOS cheat sheet provides an overview of the attack vectors that can be considered in your test plan. This one, has been specifically created for iOS devices, although the methodology applied can be used for other platforms.

As shown on the above tree, each major attack surface contains specific areas that apply to the assessment. For each major attack, consider an appropriate technique:

  • Application mapping ⇒ Information gathering
  • Client attacks ⇒ Runtime, binary, and file system analysis
  • Network and server attacks ⇒ Network analysis and insecure data storage

For each section, a specified set of tools and skills are necessary. In addition to understanding the OS to be attacked, you should pay close attention to the type of mobile application. Each one has a different attack vector. In the case of a native iOS app, it probably has been written in Objective-C or Swift language, but browser-based or hybrid apps are built using traditional web application technologies, created to be run on the device’s web browser.

Furthermore, compared with web applications, analysis of mobile applications has a major difference: binary and file system analysis. This stage requires reverse-engineering skills and the use of debugging techniques with programs such as IDA Pro, as well as disassembling files with GCC, for example. In contrast, reverse engineering represents a small portion of traditional web application penetration techniques, due to the architecture and deployment of the thin client.

2. Preparing the testing environment

Web applications run on all kinds of platforms and browsers, but that is not the case for mobile apps. Therefore, a specific device-driven testing environment must be configured. In the case of an iOS device, for example, it will be necessary to jailbreak the device, given the security imposed by Apple, which will not permit you to observe and analyze or respond to the attack? Using the evasi0n7 jailbreak allows you to boot the device and have root/admin access to the OS. In the case of Android, rooting a device by installing One Click Root will supply such access.

3. Building the attack arsenal

Once the device is ready, it will require some extra tools to be installed for analysis and information-gathering purposes. These should be deployed in the testing environment and the device. Cydia is the app store of jailbroken iOS, and through it, it's possible to download the necessary tools for hacking. Debuggers and decrypters can help you understand the mechanics of the application.

For binary analysis, using Android Apktool or a more robust Android Reverse Engineering virtual machine is highly recommended. If the app is encrypted, decrypting it using tools such as AppCrack or DumpDecrypted is a must. In addition, Burp Proxy, Android Proxy, OWASP ZAP, Wireshark, and Tcpdump are just a few of the tools available for network analysis.

4. Preparing the test cases: Application mapping

In this phase, observing the application at the functional level and analyzing its behavior, including decrypting it if the application has been obfuscated, is essential. Extraction of what kind of frameworks have been used, taking notes on the following, will help create a proper threat modeling, applying the same principles for creating a test suite as explained in the OWASP testing guide:

  • Identity, authentication, and access control => Key chains, brute-force attacks, parameter tempering
  • Input validation and encoding => Malicious input, fuzzing
  • Encryption => SQLite database password fields, configuration file encryption
  • User and session management => Session IDs, time lockouts
  • Error and exception handling
  • Auditing and logging => Logs, access control to logs.

5. Attacking the client: Binary and file analysis

During this phase, the main goal is to discover insecure API calls and files not properly secured with adequate access controls. This can be achieved by debugging and analyzing the code using IDA Pro or the Hopper App. Buffer overflows should not be discarded. To uncover vulnerabilities such as SQL injections, you can use techniques like fuzzing the application or applying malicious inputs. Techniques used to actually uncover vulnerabilities within a native application are similar to pen testing web apps with this difference: Instead of using a proxy to understand the inner workings of the app, debugging software is used.

Some of these techniques involve testing approaches similar to those used in the OWASP testing guide. During web pen testing, we are most certainly assisted by the use of an attack proxy to inject malicious input. In the case of a native mobile application, a tool such as iOKit can support this task. To assess risks related to local data storage, database browsing with the SQLite database browser applies in the case of Android and iOS, to verify how the data has been secured. Eventually, if encrypted, you can verify the type of encryption used in sensitive data fields. Analyze proper storing of API key chains' location and access control to them, among some of the tests applied to client attacks.

6. Network attacks: Install traffic, run traffic

When the mobile application has been designed with a clear client-server tier architecture, network attacks are one of the major concerns. Using sniffers to capture network traffic and investigate transport layer protection is essential. Attack proxies such as ZAP can assist with that. Other tests that should be included during this phase are:

  • Authentication. By observing the request and responses between client and server, it is possible to uncover vulnerabilities involving authentication. In cases where the application is using HTTP basic authentication, this represents a risk. If used, it should always be done through SSL. 
  • Authorization. Roles and access controls between them can be uncovered through parameter tampering. Securing the API key properly in an inaccessible folder can be uncovered by file analysis (native apps) or spidering the application (web-based apps).
  • Session management. Session ID tokens sent through GET methods and placed in the URL are visible while proxying the application or sniffing the network.
  • Weak encryption and protocols. Mobile applications are more vulnerable at these areas. Wireless vulnerabilities revolving around encryption protocols used by the device must be categorized.

7. Staging server attacks

Testing the infrastructure, specifically the server hosting the mobile web app, requires tools like Nmap and similar pen testing armor designed to map and discover potential vulnerabilities and exploitation threats. Also, unrestricted file upload, open redirect, and cross-origin resource sharing should be included as part of the tests.

Testing on hybrid and web-based mobile apps should focus on conducting attacks that try to bypass authentication mechanisms between the thin client and the server. For instance, implementation of web services security can cause vulnerabilities such as XML and XPath Injections. A clear example of a server-side attack occurred in 2013, when Apple ID iCloud accounts could be easily hijacked by resetting the password, providing only the email and date of birth of the owner of the account. Weak authorization controls were the major cause of this security vulnerability.

8. Learning more about mobile vulnerabilities  

Practice makes perfect. One of the resources available to testers willing to learn more about how security vulnerabilities occur in mobile applications are vulnerable mobile applications designed with this purpose in mind.

Some interesting dummy vulnerable applications are:

The Damn Vulnerable iOS app provides complete documentation, including some instruction articles that discuss setting up a testing environment, runtime analysis, and network traffic, among many other detailed examples. 

A false sense of mobile security is pervasive

There clearly is a false sense of security among mobile users. Mobile apps are plagued with vulnerabilities that affect them in ways that are similar or identical to those in web applications. There are real challenges in securing them, which demands an understanding of proper security controls so that applications are developed with security in mind. Testing the apps involves areas such as reverse engineering, decryption, and file analysis, which require skills that are not so simple to find.  

Mobile developers should also become aware of these techniques to build more secure applications. Some interesting documentation is available, as well as other resources focused on creating awareness around the risks of vulnerable mobile applications. In addition, continuous learning and practice can help you better understand the security risks associated with them. In the meantime, do not just click and download. Rather, execute due diligence by understanding who developed an application and what kind of information is provided regarding security controls, including proper two-factor authentication.

Download 22-Page GuideApp Security Buyer's Guide + Sample RFP
Topics: MobileSecurity