Thursday, April 21, 2011

Will Mobile Apps be the Achilles' Heel of Web Security?

Inspired by a post yesterday from Alasdair Allan and Pete Warden discussing how the iPhone records and stores geo-location data, I decided to poke around to see what other interesting security issues may be lurking among the iPhone backup files. I've been concerned for some time that we're due for a flood of security issues in mobile apps, given the explosive growth that we've seen, with thousands of developers rushing to profit from the app store model. Successful web services such as Twitter, Dropbox, Evernote, etc. have willingly provided APIs to allow integration with third party technologies, including mobile apps. This greatly enhances the value of such services, but unfortunately, the services then entrust third parties to implement appropriate security controls so as not to expose confidential user data. Unfortunately, this is not always achieved.

iOS devices record backup archives when the device is synced to iTunes. On OS X, the archive is stored in the following directory:

/Users/[Username]/Library/Application Support/MobileSync/Backup/

Apple makes some effort to obfuscate the content by archiving everything into files with titles comprised of seemingly random strings. However, unarchiving the content back to its original form is a trivial task using a tool such as the iPhone Backup Extractor. Once unpacked, you will find a variety of content including documents and images, but most configuration data is stored within either SQLite database files or .plist files. The former can be read with any SQLite viewer such as SQLite Database Browser, while the latter is simply an XML file that can be viewed in a text editor.

JotNot Scanner Pro

Let's look at a particularly egregious example of poor application security practices. JotNot Scanner Pro is an iPhone app that I rely on heavily during business travel. It is a popular app, first released over two years ago, which essentially turns your iPhone into a document scanner and allows you to store the scanned content either locally or upload them to a host of web based storage services. While Apple doesn't release sales figures for individual apps, with over 3,600 people having reviewed all versions of JotNot on iTunes, it's clear that this is a broadly adopted application.

The JotNot Pro backup archive is labelled com.mobitech3000.JotNotIPhone. Upon extracting the archive we see a directory structure with the Documents folder containing copies of previously scanned documents, while various configuration settings for the application can be found in the Library folder. The file that we're interested in is /Library/Preferences/com.mobitech3000.JotNotIPhone.plist:

Directory Structure of the JotNot Scanner Pro Backup Files
Contents of JotNot-Settings.plist file
This .plist file is an XML document, which includes version information and various user defined settings, including usernames and passwords for the third party storage services that the user has enabled to upload scanned documents to. JotNot works with a variety of online services and must authenticate with these services in order to upload documents on behalf of the app user. Unfortunately, the authentication credentials stored for Evernote, Google Docs, Apple's iDisk and any WebDav enabled server are stored in plain text. Therefore, anyone that gained access to this backup file, would then have your username/password for these services. It is particularly concerning that Google Docs and Apple's Mobile Me are on this list. Both services leverage single sign-on for their various online services, so knowledge of these credentials would also provide access to Gmail and Apple's MobileMe email service.


As an end user, you've followed best practices to keep your access credentials safe. You've chosen a complex password. You change it regularly and never share it with anyone. Unfortunately, all of that effort goes out the window when you trust an app with your data, which doesn't store it securely. In this situation, if you're a JotNot user and someone gains access to your computer either locally or remotely, they now have access to web services where you store confidential data such as documents, photos, receipts, etc. They may also gain access to your email accounts. Unfortunately, as a user, you really have no way of knowing which apps have incorporated appropriate security controls. Despite the fact that Apple must bless all apps before hosting them in the App Store and is very willing to take a 30% cut for doing so, they're clearly concerned more with blessing the 'user experience' as opposed to security. Storing passwords in clear text is security 101. If I can spot it in 15 minutes, surely they can have processes in place to identify and prohibit at least basic security issues. Web services should also be exposing APIs that don't accept usernames/passwords but rather tokens generated by the service to ensure that third party apps don't have the option to expose access credentials in the first place.

Why this isn't the first and won't be the last example of insecure mobile apps putting users at risk:

  1. Land Grab - Developers have realized the power of the mobile apps stores to generate profits and are rushing to get first mover advantage in each an every app category. Sadly, when developers are rushing to get products out the door, security is often left on the cutting room floor.
  2. New Technologies - iOS apps primarily leverage Objective-C as the programming language of choice for creating apps. This is a new language for many developers but thanks to user-friendly development tools, developers are able to produce mobile apps, even without a thorough knowledge of Objective-C.
  3. Gatekeeper - Apple is not ensuring that apps are secure before allowing them into the App store. Unfortunately, users don't realize this and are eagerly handing over passwords to apps that may or may not store them correctly.

Keep this in mind next time you're downloading the latest must have app. and handing over your passwords.

- michael 


Fred de Vries said...

And precisly that's why I've created a blog that focusses on geolocation and the steps you can take to disable it.

See here:

Alec said...

Michael -

Alec here from JotNot.

First, want to thank you for pointing out this issue. We are busy working on an update to address it. We hope to submit this to Apple shortly.

The file you refer to is stored in the sandbox and is not exposed to the user or other applications on the iPhone. The only way I know of to gain access to this file is by jailbreaking your iPhone or by syncing with iTunes and then using a special app to parse the backup files iTunes creates (which is what you did I assume.)

In the next update, we change the way we handle credentials. It adds an additional layer of security in case your phone is ever stolen or lost.

I'll post a follow up once we submit.


Michael Sutton said...

Alec - I appreciate the post. Good to see JotNot addressing the issue. Yes, I did access the plain text passwords in the backup file which is generated when syncing to iTunes and that is my concern, that plain text passwords for important services (Google/Apple) are stored on a user's hard drive without user knowledge where the passwords can be exposed. I'm glad to hear that you're working on a fix and look forward to amending the blog post to let everyone know that the issue has been resolved.

- Michael