Want To Steal A Mobile App's Secrets? There's An App For That

SSL Packet Capture makes it possible to reverse engineer secure traffic between mobile apps and the services they call home to.

The Internet security ante has officially been raised. Again.

Whereas some degree of hacking expertise and sophistication were once necessary to intercept and decrypt the transmissions between a mobile device and the services it interacts with, now there's an app -- available for free from the Google Play Store -- that makes it possible for average techies to spy on (and reverse-engineer) supposedly secure communications. In tests of the app with a variety of popular mobile applications, ProgrammableWeb was not only able to expose a majority of the secrets (including user IDs and passwords) that apps exchange with their back-end services, it was able to reverse-engineer the structure of the APIs associated with those services in such a way that we could have tampered with the services as well. The potential for disruption is not to be underestimated.

For example, even though many apps communicate with their back-end services over HTTPS (in a way that's thought to securely encrypt all transmissions), ProgrammableWeb had no trouble using the free app -- called SSL Packet Capture -- to not only intercept and decrypt those transmissions, but to discover sensitive and supposedly confidential information like API keys and OAuth tokens. In fact, so long as the application was active on our test device, pretty much all traffic between the device (from the Web browser as well any mobile apps) and the Internet was being monitored and decrypted. The app also handily inspected transmissions that were compressed or zipped (another technique used to ever so-lightly raise the barrier to hackers).

Over the last two years, the Internet's reliability as a secure channel for communicating sensitive information has been marred by a series of hacks and attacks that all too often, have exploited vulnerabilities in the API layer between front-end applications (e.g.: mobile apps) and their backend services. These attacks have proven two important lessons for the time being. First, users of anything that relies on the Internet as a communications channel should assume that the information they are sending or receiving can fall prey to some form of exploitation. Second, even the largest brands (ie: GoogleFacebook, etc) who employ the best digital security talent that money can buy are fallible, proving how difficult API security is and will continue to be for much lesser-capitalized organizations. 

For example, despite Apple's stellar track record when it comes to security, in an event that later became known as "The Fappening", hackers were able to gain access to the private, thought-to-be secure, and in some cases very explicit photographs that certain celebrities were storing in Apple's cloud. Although it required a clever combination of hacks to eventually gain access to those images, one of the key exploits allegedly leveraged a lack of rate-limiting on the private API used to enable Apple's Find My iPhone application. We've all bumped into rate-limits. They lock us out from our accounts after a certain number of failed attempts to login with the wrong credentials. Although rate limits were subsequently installed, Apple never publicly commented on the potential oversight. But, without rate-limiting, hackers would have been able to try a nearly unlimited number of user ID and password combinations through the Find My iPhone API in an attempt to gain unauthorized access to Apple accounts.

In order to exploit such a weakness, a hacker would not only need to know that the API existed (the Find My iPhone API was not a publicly documented API), she or he would also need to know something about the API's structure, how to authenticate with it, and how to speak its "language."  For the experienced hacker, reverse engineering an API to get at this level of detail, even if HTTPS is used to securely encrypt its communications, is relatively trivial. Earlier this year, ProgrammableWeb.com published an article that explained how hackers are able crack supposedly secure and private APIs by launching a "man in the middle attack" (aka: MITM) using freely downloadable utilities like mitmproxy.org. But now, the SSL Packet Capture app, released earlier this year, represents the functional equivalent of mitmproxy.org. Only it can be downloaded and run on an Android device with no special skills thus lowering the barrier to API hacking and allowing for even the most casual of hackers to engage in disruptive behavior.

Speaking to the potential for disruption, the recently reported hack of GM's OnStar system that allegedly allows hackers to locate, unlock, and remote start an OnStar-enabled vehicle was developed by monitoring and reverse engineering the communications between OnStar's RemoteLink Mobile app (there's an Android version in the Google Play Store) and the OnStar service. More than likely, an MITM-capable tool like SSL Packet Capture was involved in getting between the app and the service to intercept, decipher, and reverse-engineer the proprietary traffic, even if it was secured. 

David Berlind is the editor-in-chief of ProgrammableWeb.com. You can reach him at david.berlind@programmableweb.com. Connect to David on Twitter at @dberlind or on LinkedIn, put him in a Google+ circle, or friend him on Facebook.




So, what do you suggest for designing a secure API from packet capturing?