Smartphones today carry an unbelievable amount of sensitive information. As absolutely everything is going mobile these days, we have to pay special attention on security of mobile applications, specifically data at rest (data stored on a mobile device) and data in transit (data transferred to the target server).

In today’s diary I will write a bit about data at rest and how to handle applications being backgrounded. This is something I keep finding repeatably in mobile application penetration tests and, unfortunately, only rarely do developers implement this as they really should. We can argue, of course, that the risk of this vulnerability is low, but we should always strive to achieve the best.

For a long time, smartphones have allowed us to multitask. While one might argue that you do not need this feature on a phone, it is certainly useful to be able to have a backgrounded application while doing something else (i.e. making a phone call). iOS, for example, added this feature in 2010 with the release of iOS 4, while Android supported multitasking for even longer.

The issue I will describe today is related to storing sensitive data on a smartphone – specifically, what happens when you send an application into background (i.e. by pressing the Home button on an iPhone). Immediately after this button has been pressed, the operating system (iOS) will capture a snapshot of the application’s window. This is done so when the task switcher is opened (i.e. by pressing the Home button twice) the application can be visually represented.

This snapshot is stored in a subdirectory in the application’s container. For example, if our application was edu.sans.isc.diary, the snapshot would be stored in this directory:

/var/mobile/Containers/Data/Application/$APP_ID/Library/Caches/Snapshots/edu.sans.isc.diary/

where the $APP_ID is the application’s GUID. We can see potential risk from this feature: if we had sensitive data on the screen (i.e. in a banking application this could be our account balance or even card information), this will be stored in the filesystem from where it can potentially be retrieved (especially in case of a jailbroken/rooted phone).

Besides being stored as a file, contents of the taken snapshot are, as explained above, also visible in the task switcher. Here is what it looks like with Google’s Authenticator, which does not have any protection against snapshots implemented:

Hmm, maybe too much information? At least these are one time passwords, but in other, more sensitive applications, this behavior is not wanted.
Luckily, iOS allows us to remove sensitive information from views before moving to the background. The application’s delegate can implement the -applicationDidEnterBackground: method. This method allows a developer to configure the application’s view as it should appear in the task switcher, effectively removing sensitive information from being displayed.

The image below shows an application implementing this properly, where the snapshot has been blurred to prevent reading the data when cycling through backgrounded applications with the task switcher.

Besides this, there is another setting that sensitive applications should have: in the configuration profile, the application should set allowScreenShot to false – this way users will not be able to save a screenshot of the display and will be prevented from capturing a screen recording.

On Android phones, the Recent Apps task switcher works very similarly to the one on iOS, and the generated snapshots are available in one of the following directories:

/data/system/recent_images
/data/system_ce/0/recent_images/  (when encryption is enabled – system_ce is the credential encrypted directory)

The same story as above applies – in order to make sure that potentially sensitive data displayed on the screen in an application that has been backgrounded cannot be read, the application should set the FLAG_SECURE layout parameter. This will cause the screen in the Recent Apps task switcher to be blank, and will also prevent creation of screenshots.

While we will all agree that this is not a critical vulnerability, it should nevertheless be verified during a mobile application penetration test. The specific category has been also added to the OWASP Mobile Security Testing Guide (2.9, Verify that the app removes sensitive data from views when backgrounded).

The scenarios when this vulnerability becomes more serious include a jailbroken/rooted device where a malicious application can become root, or when a device has been stolen and is not protected with a PIN (and with penetration of smartphones there will always be users that do not put a PIN on their mobile device).

I will be talking about this and (many) more mobile application security issues this year at SANSFIRE – let me know if you will be there!

--
Bojan
@bojanz

INFIGO IS