Protect Your Assets
Showing results for 
Search instead for 
Do you mean 

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

jhaddix ‎10-09-2013 11:35 AM - edited ‎09-25-2015 10:28 AM

When we deliver results to customers on mobile assessments there is always a bit of a learning curve pertaining to risk levels assigned to certain findings. In most cases, by themselves, low risk vulnerabilities can be non-issues. This is true for appsec vulns or mobile vulns. In reality some companies do not even fix them.

  

In part one of this blog I’ll go over a few that have presented interesting and high yield results. Hopefully this will remind people that combinations of these vulns (or bad applications of them) can be just as critical as any High risk finding on an assessment. We will use iOS examples below.

 

Paths Embedded in Binary

 

As part of cursory binary analysis of mobile apps, we often parse out usernames from binaries. When compiling, even symbol stripped binaries, cannot remove these paths due to the reflective nature of mobile programming languages.

 

See the example below, after parsing a mobile binary:

 

/Users/Walter_White/Desktop/MyCoolApp/Lib/Classes/CDVLocalStorage.m

 

You can see a Mac username (in red) and path in the binary.

 

Now, seems harmless right? In one particular instance we managed to find that username on GitHub while profiling the app. After some digging we found out that the original developer of this mobile app was no longer employed at our client.  Although let go, had seen fit to store their:

 

  • Mobile application source
  • Server source code
  • Private SSL certs
  • SSH keys

All in a public repo! Needless to say, that was a fun assessment!

  

Photo Storage

 

You know when an app installs and asks you for permission to access your photos? Something like this:

 

 

 

Well this allows apps to collect any photos in your photo roll directory and send them anywhere. This directory is on your iPhone:

 

/var/mobile/Media/DCIM/100APPLE

 

Many applications such as social media apps, storage apps, etc, do this for legitimate functionality. For everyday photos, the photoroll is the place to be for sharing!

 

Now, a problem occurs when you have an image like the one below, posted to a place where other apps can retrieve it:

 

 

 

Several apps from the category below were trying to use the camera and store photos but these photos were of a sensitive nature and should never have been put in a area of the phone that other applications can reach.

 

Some examples that we found putting private photos to the public photo roll:

 

  • Banking apps (like above)
  • HR apps (employee pictures and documents)
  • Document scanning (all scanned media)
  • Security functionality in apps (extra functions to try and make apps more secure but ended up letting us in; photos for facial recognition, etc!)

  

Recommendations:

 

  1. We recommend developing your applications using a generic user account like “developer1” in your compile environment.
  2. We recommend storing your images inside a folder in the application sandbox (/var/mobile/Applications/Your_App/tmp) and the applying a strong data protection class to that file.
  3. Always have your applications assessed before a major release.

 

Stay tuned for part two where we discuss screen caching and weak API’s!

0 Kudos
About the Author

jhaddix

Events
Aug 29 - Sep 1
Boston, MA
HPE Big Data Conference 2016
Attend HPE’s Big Data Conference on August 29 - September 1, 2016 to learn from peers in every industry and hear from Big Data experts and thought lea...
Read more
Sep 13-16
National Harbor, MD
HPE Protect 2016
Protect 2016 is our annual conference on September 13 - 16, 2016, and is the place to meet the world’s top information security talent, discuss new pr...
Read more
View all