Low Risk Mobile Vulnerabilities Can Lead to High Risk Exposure pt. 2

Cache, Cache, Cache!

 

When you run any application there are certain things developers do to provide you with that seamless feel you are accustomed to. One of these things is caching. The idea behind caching is to preload or store some sort of information instead of having to retrieve it again from a far off place every time you need it.

 

Two examples we see often are iOS screen caching and NSURL caching.

 

iOS screen caching goes something like this;

 

You are inside an application on a screen with personal or valuable data...

 

info.png 

 

Then, in the middle of using your app, you have to hit the “home” button for something (or you get call). After you finish your call you want to go back and complete recovering your password. Well, in order to facilitate the fancy animation to bring back up your mobile app, iOS took a screen shot of where you were before!


This screenshot is stored on the phone in:

 

  • /var/mobile/Applications/{YourAppUID}/Library/Caches/Snapshots/{YourAppBundleID}/UIApplicationAutomaticSnapshotDefault-Portrait@2x.png

If your phone gets lost or stolen, normally, so does your data =(

  

We have run into several sensitive implementations of screen caching: 

  • Ticket QR codes (airline, train, transit, and concert)
  • Banking info (account numbers, etc)
  • Sensitive “scanned” Documents viewed in app
  • Etc.

 

 

NSURL caching is the same caching idea except with your applications network traffic.

 

If not configured right, NSURL (or other network communication methods) with keep a cache of all POST data responses in a SQL file called Cache.db

 

This file is given least amount of data encryption by the OS and stored inside:

 

  • /var/mobile/Applications/{YourAppUID}/Library/Caches/{YourAppBundleID}/Cache.db

 Why is this an issue? In the POST response data can be unique account information, session tokens, and private message data, you name it… all kinds of juicy info can be in there.

 

11-12-2013 1-15-07 PM.png

 

Recommendations:

 

We recognize that you might not even know these methods do this by default. Both these vulns, along with many other caching vulns we find, are part of a category of unintended data leakage in the OWASP Mobile Top Ten called “Side Channel Data Leakage”

 

We recommend:

 

  1.  When sending an application to the background you can overlay an image so that the screenshot taken is just that image, instead of juicy info. Here we’ve written just to splash the logo of our app:

@property (UIImageView *)backgroundImage;

- (void)applicationDidEnterBackground:(UIApplication *)application {

UIImageView *myLogo = [[UIImageView alloc] initWithImage:@"logo.png"];

self.backgroundImage = myLogo;

[self.window addSubview:myLogo];

}

 

2.   To prevent particular requests from being cached, implement the connection:willCacheResponse: method on the   delegate and return nil for those requests.

 

 (NSCachedURLResponse *)connection:(NSURLConnection * connection willCacheResponse:(NSCachedURLResponse *)cachedResponse

{

    // implement handling for different requests here

    return nil;

}

 

 3.    Always have your applications assessed before a major release.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.