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:




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:




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!)




  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


June 6 - 8, 2017
Las Vegas, Nevada
Discover 2017 Las Vegas
Join us for HPE Discover 2017 in Las Vegas. The event will be held at the Venetian | Palazzo from June 6-8, 2017.
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all