Offensive Mobile Forensics

Christmas is around the corner. Some of the top gifts are going to be shiny new mobile devices – smartphones, tablets, hacked Kindle Fires, Playbooks, and others. Is Exchange ActiveSync turned on in your environment? What is your plan for handling mobility in the Enterprise? But the biggest question of all is – What does a lost or stolen mobile device mean to your organization in terms of risk? What about when the CEO loses her device? Can you quantify your risk today?

The data leakage disclosed in this post has been gathered from a technique the author refers to as Offensive Mobile Forensics.  The term forensics is usually associated with incident response and management.  In other words, an activity performed after something bad has happened.  In contrast, offensive forensics is the act of preemptively performing a forensic analysis of systems or applications as a function of security testing, or for the purpose of quantifying risk.  An interesting side-effect of applying this technique to mobile device analysis is that it enables one to truly understand the risk of an attacker stealing or finding a lost device.  For example, if your analysis turns up native or third-party applications storing user credentials in cleartext – the author has seen everything from Facebook and Twitter to enterprise users’ Exchange ActiveSync credentials stored in the clear – depending on the accounts and data available, that could be a serious issue.

This technique depends on the ability to jailbreak (iOS) or root (Android) the target device, which provides root access to the underlying file system. If the reader is unfamiliar with these terms, some great resources to learn about jailbreaking and rooting are Redmond Pie (iOS) and XDA-Developers (Android). The author typically utilizes Redsn0w for iOS and SuperOneClick for Android, performing virtually all Android analysis on Samsung devices.


After jailbreaking is complete, only one other tool is necessary, OpenSSH, used to pull data from the device to a host computer for analysis over WiFi.  However, as is always the case with information technology, there’s more than one way to accomplish your objective.  So, experiment with other tools, and tweak and tune your own methodology.

Although outside the scope of this blog post, readers interested in learning about some of the other tools used for this analysis technique can check out the iOS Insecurities article in November’s issue of Hackin9 Magazine. The article is a greatly expanded version of what’s here, and also includes a table listing physical locations on iOS devices that contain interesting information for analysis.

There are many different locations containing interesting data on iOS devices.  Data often resides in SQLite databases, the chosen format for local storage on mobile devices.  The next best place to find sensitive information is in plist, or property list files – these are the primary storage medium for configuration settings in iOS, and they are also a fantastic source of sensitive information.  User credentials are often stored here, instead of inside the KeyChain where they should be.  Rounding out the top three data sources are binary or binary-encoded files, such as the device’s keyboard cache and pasteboard.  Although storage locations commonly change with the release of new iOS firmware, it is fairly simple to poke around the general area and find what you’re looking for.

The most severe threat to mobile devices and applications is loss or theft of the device.  As the old saying goes, “if an attacker has physical access, it is game over.”  It only takes a few days of analyzing applications on a device to discover that the vast majority of mobile application developers fail to consider the threat of physical access to their data.  Simply put, they are stuck in the mindset of web application or client/server developers, where virtually all threats affect applications remotely.  Add some terrible design and implementation decisions related to native apps and services from Apple themselves, and you have a device that can pose a significant risk to enterprises and consumers in the event of loss or theft.  The following examples are provided in no particular order.

Keyboard Cache (dynamic-text.dat)

In an effort to learn how users type, iOS devices utilize a feature called AutoCorrection to populate a local keyboard cache on the device.  The problem is this feature records everything a user types that is not entered into a SECURE text field, which masks displayed data.  The author fondly refers to this feature as “Apple’s native keylogging facility”.  Data typed into text fields for virtually any application can remain in the cache for more than a year if it is not reset periodically by the user:

Settings > General > Reset > Reset Keyboard Dictionary

Developers can also disable this feature programmatically by using the AutoCorrection = FALSE directive in desired UITextFields, although studies conducted with applications disabling this feature have shown users unanimously disapprove of it.

The file itself is a binary file, so passing it to the utility ‘strings’ is all that is required to generate newline-terminated output suitable for analysis.  Figure 1 displays the result of running ‘strings’ against the file, and Table 1 provides examples of near-complete conversations recorded by AutoCorrection.

Figure 1: Keyboard cache output to stdout in terminal

The keyboard cache is a well-known weakness in the iOS system, and there are many more interesting system-related locations to explore as an exercise for the reader.

Table 1: Keyboard cache entries - read column top-down

Application Data Leakage

Third-party applications represent the greatest threat of data leakage on iOS devices.  This is usually the result of lazy or poorly-informed, or trained, developers storing user credentials or other sensitive information in clear text.  This threat can be mitigated by developers in several ways including storing user credentials in the KeyChain, encrypting sensitive information in plist files with the Common Crypto library, or encrypting sensitive information in SQLcipher SQLite databases. Figure 2 shows one example of a mobile application improperly storing credentials in a plist file.  Unfortunately, this particular application utilizes various Internet APIs for authentication including Evernote, Google Docs, Dropbox, and others, which in the event of loss or theft, could result in the compromise of each account.

Figure 2: Credentials disclosed in an application's configuration PLIST


Although there are many similarities between iOS and Android, there are a few notable differences that should be discussed. First, Android does not use property list files (“plist”) for storing configuration data, which is common on iOS devices. Android uses XML files instead of plists. Also, analysts will find many more SQLite databases on an Android device. In fact, configuration information is sometimes stored in SQLite database in lieu of utilizing XML files. Similarly to the configuration files for iOS, the XML files storing preferences for Android applications commonly include user credentials and other sensitive information. Finally, there is a very rich diagnostic and debugging environment in the Android platform, and unfortunately this output is also a common source of data leakage.

A huge difference between iOS devices and Android devices is the presence of the Android Debug Bridge (“ADB”) for the latter. Using the ADB, one can push or pull files to the device, review diagnostic information, and even gain access to a remote shell. The ADB Shell is the primary method of accessing the device’s file system for the purposes of pulling data to a host computer for analysis, or performing analysis on the device itself. More information on this, and other, differences can be found in the Android Insecurities article in January’s issue of Hakin9 Magazine.

Annotated WiFi Credentials


The Android system, like iOS, stores email in a SQLite database. Unlike iOS however, which stores email credentials in the KeyChain, user credentials on an Android system are stored in cleartext in the email database. This may seem like a trivial occurrence of data leakage, but in addition to personal email accounts such as Gmail, Exchange ActiveSync (“EAS”) credentials are also stored there. As if credentials weren’t bad enough, the database also stores messages in the clear, along with email addresses of contacts that have sent the user mail. This could be particularly devastating for corporate enterprises utilizing EAS, in the absence of a proper mobile device management (“MDM”) solution.

EAS and personal email account credentials can be discovered in a couple of different ways.  Figure 3 shows analysis of the EmailProvider.db SQLite file in Base, a GUI SQLite client. An even easier way to find user information is by simply running the ‘strings’ utility against the database file, as seen in Figure 4.

Figure 3: Email credentials disclosure



The email situation is bad, but equally shocking is the method in which the Android system stores WiFi configuration information. Navigating to the /data/misc/wifi directory yields a configuration file called wpa_supplicant.conf on a Samsung Captivate that stores configuration information for every WiFi network the device has connected to – in cleartext. Assuming the data is disclosed to an attacker, an organization’s only defense is the use of multifactor authentication for their wireless networks, i.e., if corporate enterprise is using a combination of username and password exclusively, this could be a serious issue. The configuration file stores SSID, key management type, and the pre-shared key for the network.

Figure 4: Email credentials disclosure



Now, obviously various mitigating controls exist for protecting a user’s data on a mobile device, most notably the hardware-based encryption and Data Protection on the iPhone 4 and above, and encryption Android devices with Gingerbread. Passcodes lock devices, and in the case of Data Protection, enable a secondary layer of software-based encryption. That said, a recent study indicated over 50% of users don’t use a passcode at all on their devices, and another 20% utilize a 4-character combination that can be easily guessed in the usual 10 tries allotted – 1234, 4321, 9876, and so on. Add to this the ability to deploy OpenSSH as part of the jailbreaking process for iOS devices, the most prevalent choice for the Enterprise, or simply crack the passcode, and loss or theft is illuminated as a serious threat to data security. In the current ecosystem, with physical access to the device, it’s game over.

Joey Peloquin

Joey Peloquin is the director of mobile security at FishNet Security, where he’s responsible for MDM technology review, mobile security research, testing methodologies, and business development. He’s spent the last twelve of twenty years in IT specializing in Information Security. His experience ranges from risk assessment to intrusion analysis and incident response, network and application penetration testing, and mobile forensics.

One Response to Offensive Mobile Forensics

  1. Jamie Simmons says:

    Great article! Definitely the best I’ve seen on Netstumbler in a year or more.