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

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:

 

permsios.jpg 

 

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:

 

check.png

 

 

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!

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
About the Author


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