?
Digital Application Development
4 minute read

The Dangers of App Secrets on Mobile

See a demonstration of common data exfiltration vulnerabilities in mobile applications.

In This Article

For many years, mobile developers have faced the dilemma of requiring secrets at application runtime, but not necessarily being able to reach an API server to fetch any data from the backend. Unfortunately, too many developers resort to insecure methods of storing sensitive information, which can lead to catastrophic results for both the end-user and the company that maintains the app. 

Let’s look at two examples of how this could happen.

copy link

Scenario 1: iOS

A user has an iPhone. One day, they go to a public location and see a charging station for mobile devices. The user plugs their phone into a charging station and sees a notification asking the user for their password to unlock the device; the user then enters the information. Unfortunately, the charging station has been configured with malware (this attack is known as “juice jacking”), which has now obtained a pair-key that can be used to interact with the device. The malware is designed to collect all application property list (plist) files on the phone and upload their contents to a remote server.

We can simulate which steps the malware might take by SSH'ing into a device to read from its filesystem:

The malware first gathers a list of application plist files.

A picture containing text, window

Description automatically generated

The malware then scans each file, filters out files with no interesting information, and then submits the rest to a remote server for collection. Here is an example of some things the attacker can obtain:

Text

Description automatically generated

Immediately, you can see that the attacker has gained access to some sensitive information. In this case, they’ve gained a list of “remembered” WiFi networks the application has connected to; this is the type of information an attacker would need to obtain to perform even more sophisticated attacks.

How can we prevent this?

Depending on the implementation of the application, the attacker may be somewhat limited as to how often their malware can function. iOS implements several classes to accomplish varying degrees of file system protection depending on the application’s needs. In this case, the application was using “NSFileProtectionCompleteUntilFirstUserAuthentication,” which allows the file to be accessed after the user has unlocked their phone for the first time since boot. This effectively allows the malware to continuously read this file for as long as the phone is on. In retrospect, the better choice would have been to use “NSFileProtectionComplete,” which would prevent the malware from reading these files unless the user actively has their phone unlocked.

Graphical user interface, text, application

Description automatically generated
(https://developer.apple.com/documentation/foundation/nsfileprotectioncomplete)

Notice that this does not completely stop the attacker from gaining information if the user has their phone unlocked. The best approach, in addition to the above, would be to avoid storing secret values in plist files at all. 

We can achieve that by using the iPhone’s Keystore service, which encrypts values from an encryption key embedded on the hardware of the phone itself. 

Text

Description automatically generated
(https://developer.apple.com/documentation/security/keychain_services#//apple_ref/doc/uid/TP30000897-CH204-TP9) 

copy link

Scenario 2: The Android variant

In our Android example, the targeted vulnerability requires the user to have USB debugging enabled. This time we are targeting the preferences files. 

This user is tech-savvy and has done cool things with their Android which require USB debugging. Unfortunately, the user did not consider the security implications of leaving this setting on, so their device was also infected when they began charging their phone, after accepting the connection prompt on the screen.

Again, we can simulate the steps this malware might take:

Get a list of all preferences files.

Graphical user interface, text

Description automatically generated

Scan files for valuable content.

Text

Description automatically generated

And as you can see, the attacker has access to all the same information (the same app, but for Android).

How can we prevent this?

Unlike iOS, Android does not have any filesystem protection classes we can leverage, but we can still encrypt sensitive values by using Android’s Keystore.

Graphical user interface, text, application, email

Description automatically generated
(https://developer.android.com/training/articles/keystore)

copy link

Final thoughts

Bottom line: The best solution is to simply avoid storing sensitive data on any client device. However, in those cases where you cannot avoid doing so, be very intentional about how, where and what you store. These types of attacks apply to iPhone, Android, as well as other mobile devices. Attackers will take any avenue you aren’t expecting to obtain these values.