OWASP MOBILE TOP 10 : Insecure Data Storage - Tutorial Boy -->
Home
Mobile Pentest

OWASP MOBILE TOP 10 : Insecure Data Storage

Introduction

We already touched on this topic a little in the first chapter M1.2016 but it is a bit more complicated than it seems at first. To gain something from this vulnerability thought is not very easy. The bad actor needs access to the device or needs to have an app installed that has access to the storage on the mobile device of the victim. This makes the attack vector a little bit more complicated but there is still a possibility of a very big impact if the incorrectly stored data is sensitive information, partially due to the easy exploitability.
  • Exploitability: Easy
  • Prevalence: Common
  • Detectability: Average
  • Impact: Severe

Attack vector

When an attacker has physical access to the mobile device and they can unlock it, they can hook it up to a computer and read it out. If the attacker can’t gain access though, they can craft an exploit app to read all the public data and send it to the attacker. An attacker can even modify existing apps to do this and hide their true intentions in an innocent app like flappy bird which will steal all the user's public data in the background.

Security Weakness

Developers must learn how to securely store data because if they do not learn and accidentally store sensitive data in an insecure location, a bad actor may have access to those files. Every developer and organization should design their applications with security in mind and they should always assume a system is compromised. Since the filesystem is so easily accessible, we should also assume that the files can get compromised. Rooting or jailbreaking a mobile device circumvents any encryption protections, this means that a bad actor would need some simple specialized tools to read the files.

Impact

The impact can range from none to critical. It depends on the information that is stored insecurely. If the data has no impact then there is vulnerability but often there will be at least some kind of impact since developers usually store information which they will need later on. This information usually contains at least some useful information for bad actors.

Insecure data may result in the following business impacts:
  • Identity theft; if personal information is stored incorrectly.
  • Privacy violation; if personal information is stored incorrectly.
  • Fraud; Personal data might get stolen such as credit card numbers.
  • Reputation damage; both to the victim and the organization.
  • External policy violation (PCI); PCI compliance is a set of standards and guidelines for companies to manage and secure credit card-related personal data.
  • Material loss; An attacker may steal information allowing them to rob the victim.

Prevention

Developers need to be very aware that there are also background processes going on which can store personal data that they may not know about.

  • Sometimes the OS caches data, images, key-presses, logging, and buffers. These can all contain personal or sensitive information.
  • Sometimes the development framework caches data, images, key-presses, logging, and buffers. These can all contain personal or sensitive information.
  • Sometimes 3rd party applications cache data, images, key-presses, logging, and buffers. These can all contain personal or sensitive information. We can see third-party applications as our integration points, for example, ads, analytics, logging frameworks,…
Your mobile app, OS, platforms, and frameworks all have their own way of caching data and developers need to be very aware of this so that they do not send sensitive information to these components that could end up being read out by hackers because they were sent to a public data location.

It is crucial to see how they handle the following types of features :

  • URL caching (both request and response)
  • Keyboard press caching
  • Copy/Paste buffer caching
  • Application backgrounding
  • Intermediate data
  • Logging
  • HTML5 data storage
  • Browser cookie objects
  • Analytics data sent to 3rd parties.

Implementation

We should look at every aspect of data storage, from all possible attack locations (OS, framework, and app). We need to look at all the processes and not just the ones we think we control via our mobile app. This includes but is not limited to:
  • URL caching (both request and response)
  • Keyboard press caching
  • Copy/Paste buffer caching
  • Application backgrounding
  • Intermediate data
  • Logging
  • HTML5 data storage
  • Browser cookie objects
  • Analytics data sent to 3rd parties.
We need to perform a threat model on our application, the OS, and the framework we are using to make sure no sensitive data is being located where it should not be.

For iOS, we also have to make sure that no iTunes backup files contain sensitive data because in iOS 10 there is an issue that makes it easy to crack these backups. Include the following code:
let fileURL = try! FileManager.default
    .url(for: .cachesDirectory, in: .userDomainMask, appropriateFor: nil, create: false)
    .appendingPathComponent("data.dat")

We also need to prefer the keychain for storing small parts of data such as keys or passwords. Ensure you are using the most protective attributes:

https://developer.apple.com/reference/foundation/nsfileprotectioncomplete

To make our storage SUPER safe, we can even use the iOS encryption capabilities:

https://developer.apple.com/reference/security/1617956-seckeyencrypt

For android we need the following in our manifest to disable ADB access to our backup data:

android:allowBackup=”false”
Do not store sensitive data in the SharedPreferences as this can easily be accessed on a rooted device.

Attack  Plan

Data stored insecurely includes, but is not limited to, the following:
  • SQL databases
  • Log files
  • XML data stores or manifest files
  • Binary data stores
  • Cookie stores
  • SD card
  • Cloud syncs
We are looking for these files but of course, it could be anything containing sensitive information. You can try “strings” on Linux which is a command to find all the strings in any file.

These files can leak from:
  • The OS
  • Frameworks
  • Compiler environment
  • New hardware.
  • Rooted or Jailbroken devices
As an example, we can use iGoat. iGoat is developed by OWASP and it will contain a SQL file in its file systems. If we download the file and use strings, we can see credentials we should not be able to see.

Summary

According to OWASP, insecure data storage vulnerability is one of the most dangerous vulnerabilities mobile applications are susceptible to. To avoid introducing such a vulnerability into your mobile applications, keep an eye out on your databases, log files, data stores, the SD card, and the cloud. Also keep in mind that unintended data leakage might also stem from vulnerabilities in your operating system, frameworks in use, new hardware, also rooted or jailbroken devices.

Keep in mind that the threat agents for this vulnerability include an adversary who has attained access to a mobile device or the execution of malware sent by an attacker. Knowing these things in mind should make your mobile applications more secure.

Post a Comment