Mobile Application Penetration Testing, Part 4

In Part 1 of this post, I provided an overview of mobile app attack vectors and penetration testing approaches. In Part 2, I covered tools, techniques and issues related to the two types of mobile applications: browser-based and native. Part 3 discussed penetration testing of mobile client apps, with a focus on Apple’s iOS.
In this Part 4, the final installment, I’ll share tips on penetration testing of the communications channel.
Although applications in general are using increasingly secure communications for sending sensitive data, there are still vulnerabilities to contend with. In particular, one can use an HTTP manipulation proxy to intercept and alter traffic between an application and the server. In scenarios where the application does not use the HTTP protocol, a transparent TCP and UDP proxy like the Mallory tool can be used.
While testing the communications channel, the pen tester’s focus should be on replay attack vulnerabilities, and on making sure that sensitive data is transferred on a secure channel. A proxy will work as a “man-in-the-middle” (MiTM) between the mobile device and the server, allowing you to intercept and modify traffic to facilitate testing. Examples of proxy tools for manipulating traffic include Burp Suite, OWASP WebScarab or Zed, Paros, Charles (all of which are web-focused), and Mallory (a more general transparent TCP and UDP proxy tool).
In a sense, mobile application penetration testing is not all that different to web application penetration testing. Regardless of platform, mobile applications basically make use of one or more of three network communication mechanisms:

1. Clear text transmission (HTTP)
2. Encrypted transmission (HTTPS)
3. A custom or proprietary protocol

A MiTM attack becomes possible when an application uses clear text transmission and is made easier due to the availability of WiFi by smartphone users. The Firesheep packet sniffer, an extension of the Firefox browser, provides one way to exploit this vulnerability.
To analyze HTTP traffic on the iPhone, just enable a manual proxy on the phone (Settings -> WiFi -> Manual), as illustrated below. Many applications are still running on HTTP.

To transmit sensitive data, and to make sure that even if an attacker can get hold of data it can’t be used, encryption over HTTPS is required.
In SSL communication, apps may fail to validate the SSL certificate; e.g., allowsAnyHTTPScertificateForHost. Apps that do validate the SSL certificate will thwart MiTM schemes, in a manner similar to modern browsers like Google Chrome or Microsoft Internet Explorer 10. To capture the traffic, load your proxy (e.g., Burp) CA certificate into the iPhone. This is also applicable to other protocols that work with certificates.
Hackers have broken the SSL encryption in use by millions of sites. An example is the BEAST (Browser Exploit Against SSL/TLS) proof-of-concept code published by researchers, which decrypts secret PayPal cookies.
If your application uses a custom protocol instead of HTTP/HTTPS, then you’ll need to identify the communications protocol on SSH Terminal using Tcdump –w traffic.pcap and then load the .pcap file into Wireshark for analysis. Many custom protocols don’t respect iPhone proxy settings, so it’s better to use other proxy tools.
Once you capture the traffic, you can perform typical web application penetration testing, in which attacks are performed on the application server; e.g., authentication, authorization, session management, weak ciphers, etc.
To discuss penetrating testing services for your business-critical mobile applications, contact Pivot Point Security.