[Editor comment: This is the first post of an in-depth series by three skilled pen testers and great authors, focused on assessing mobile application and their associated infrastructure. The series will unfold over the next month or two. We start, naturally enough, with the overall methodology, a description of attack vectors, and an inventory of the items you'll need to conduct such tests. Really useful stuff --Ed.]
By Pieter Danhieux, Erik Van Buggenhout, and Koen Van Beirendonck
During the past few years, we've seen mobile devices evolve from simple, rather dumb phones to complete, integrated communication devices. As these devices became more intelligent ("smart" phones) and data transfer speeds on mobile networks increased significantly, people no longer used them solelyfor making phone calls or sending text messages, but started using them for sending email, browsing the Internet, playing games, checking-in for flights, or doing online banking transactions.
Companies started creating mobile applications to offer all sorts of services to their clients. Today, mobile applications are available for storing and synchronizing data files in the cloud, participating in social network sites, or even playing with a talking crazy frog. As the data that is stored, processed, and transferred by these applications can often be considered sensitive, it is important to ensure that the security controls on these mobile devices and applications is effective.
We see that the industry understands the need for methodologies (like the OWASP mobile project) and specialised tools to direct the sometimes-specific requirements of mobile applications. However, up until now, most of these initiatives are still quite draft and not ready to use out-of-the box.
Therefore, over the next two months or so, we will publish several blog posts aimed at giving you some tips and tricks in assessing mobile applications and their associated infrastructures based on lessons learned from our own experience. We'll give you a heads up on the different attack vectors for mobile applications and the typical attention points/vulnerabilities for each vector. Furthermore, we'll give you a practical example of how security assessments for the four big mobile platforms (Windows Mobile, Blackberry, Apple's IOS, and Google's Android) can be performed.
When we have a look at the architecture of most mobile applications, we can clearly identify three major components that support different attack vectors:
- Client software running on the mobile device
- Communications channel
- Server side infrastructure
For each of these three attack surfaces, we'll give a short description and some attention points to focus on when looking for potential vulnerabilities. These attention points act as an inventory or checklist of vital items for penetration testers and vulnerability assessment personnel to analyze in each aspect of the mobile application environment. While the attention points included below are not exhaustive, they do provide the most fertile hunting grounds for exploitable vulnerabilities.
Client Software on Mobile Device
Usually, a client software package is installed locally on the mobile device which acts as the front-end for the user. Packages are typically downloaded from an app store or market, or provided via the company's website. Similar to non-mobile software, these applications can contain a myriad of vulnerabilities. It is important to note that most testing on the client device usually requires a device that is rooted or jailbroken. For example, the authentic mobile OS will most likely prevent you from having access to all files and folders on the local file system. Furthermore, as software packages can often be decompiled, tampered with or reverse engineered, you may want to use a device that does not pose any restrictions on the software that you can install.
- Files (temporary, cached, configuration, databases, etc.) on the local file system
- Insecure file permissions
- Application authentication & authorization
- Error handling & session management
- Business logic testing
- Decompiling, analyzing and modifying the installation package
- Client-side injections
The second attack surface is the communications channel between the client and the server. Although applications use more and more secured communications for sending sensitive data, this is not always the case. In your testing infrastructure, you will want to include an HTTP manipulation proxy to intercept and alter traffic. If the application does not use the HTTP protocol for its communication, you can use a transparent TCP and UDP proxy like the Mallory tool. By using a proxy, you can intercept, analyze, and modify data that is communicated between the client and the server.
- Replay attack vulnerabilities
- Secure transfer of sensitive information
- Server-side validation of input data
- Session ID vulnerabilities
In most cases, the server to which the client communicates is one or more web servers. The attack vectors for the web servers behind a mobile application is similar to those we use for regular web sites. Aside from looking for vulnerabilities in the web application, you should also perform host and service scans on the target system(s) to identify running services, followed by a vulnerability scan to identify potential vulnerabilities, provided that such testing is allowed within the scope of the assignment (it should be, but make sure you check!).
- OWASP Top 10 Vulnerabilities
- Running services and versions
- Infrastructure vulnerability scanning
Preparing The Test Environment
The following are vital parts of your test environment for assessing mobile applications and their associated infrastructure:
1. Mobile device / Mobile device emulator
If available, we would always opt to use the original (jailbroken) mobile device for performing our testing activities. We understand, however, that this is not always a feasible option, so an emulator is an acceptable alternative.
Example emulators for popular mobile client systems include Google Android Emulator, MobiOne, iPhoney, and the Blackberry Simulator.
We recommend that you get an appropriate decompiler in order to decompile the binary application files. During black-box engagements, decompilation is essential in order to have a good understanding of how the application internals work.
Example decompilers for mobile applications include Reflector.NET (Windows Mobile), otool and class-dump-x (iPhone), dex2jar and JD-Gui (Android), and Coddec (Blackberry).
3. Code analysis tools (optional)
Once the application code has been successfully decompiled, we can consider using a code analysis tool in order to identify vulnerabilities in the application source code.
Examples of such tools include Klocwork Solo, Flawfinder, Clang, and more.
Communication Channel / Server-Side Assessment
The proxy will work as a "Man-in-The-Middle" between the mobile device and the server. It will allow us to intercept and modify traffic in order to facilitate testing.
Example proxy tools for manipulating traffic include the Burp Suite, WebScarab, Paros, Charles (all of which are web-focused) and Mallory (a more general transparent TCP and UDP proxy tool).
5. Web application vulnerability scanner (optional)
In order to test the application server, it can be a good idea to have a web application vulnerability scanner handy. After all, many of the common vulnerabilities are identical to web application issues and can thus be detected by (semi-)automated scanners. Please note that most of these scanners are commercial and some boast rather expensive license packages.
Example scanners include BurpSuite Active Scanner, Acunetix, Cenzic Hailstorm, IBM AppScan, and HP WebInspect.
So far, we have discussed a generic view of attack surfaces and tools for your arsenal in assessing mobile applications. In the next post in this series, we'll present a more detailed look at client-side assessments on Windows Mobile and Applie's iPhone.