Security Products
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!

About the Author


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.
1-3 December 2015
Discover 2015 London
Discover 2015 in London, the ultimate showcase technology event for business and IT professionals to learn, connect, and grow.
Read more
November 2015
Software Online Expert Days
Join us online to talk directly with our Software experts.
Read more
View all