Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Side-channel information leakage in mobile applications - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Side-channel information leakage in mobile applications

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:

Google Authenticator side-channel information leakage

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.

Properly configured application preventing side-channel information leakage

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

Bojan

371 Posts
ISC Handler
I agree with your sentiment towards mobile security, especially the concept that mobile devices can hold large amounts of very sensitive information. Just look at the Dark Caracal spyware campaign reported by the Electronic Freedom Frontier and Lookout mobile security. Although Android OS was mainly targeted, the data at rest and in use on mobile devices cannot be overlooked. Did not even think about the snapshots captured when applications are sent to the background, so thank you for that. Cheers.
Anonymous
Posts
FLAG_SECURE is not enough for Android because the virtual keyboard still gets captured. This is a known Android bug which Google is not fixing so far.

See the following (Google login required):
https://code.google.com/p/android/issues/detail?id=129285

We have done a detailed writeup on FLAG_SECURE some time ago:
https://blog.nightwatchcybersecurity.com/research-securing-android-applications-from-screen-capture-8dce2c8e21d
Anonymous
Posts
Indeed, there are cases where some data might leak even with FLAG_SECURE set; however in most cases it will be enough to protect potentially sensitive data.

Thanks for the feedback and the link, good stuff!
Bojan

371 Posts Posts
ISC Handler

Sign Up for Free or Log In to start participating in the conversation!