OWASP Top 10 Mobile: Unintended Data Leakage

Continuing with our series on the OWASP Top 10 Mobile threats, the fourth most exploited mobile threat is called Unintended Data Leakage.

What is Unintended Data Leakage?

Unintended data leakage occurs when a developer inadvertently places sensitive information or data in a location on the mobile device that is easily accessible by other apps on the device. This insecure location could be accessible to other malicious apps running on the same device, thus leaving the device in a serious risk state.

How does Unintended Data Leakage work?

First, a developer's code processes sensitive information supplied by the user or the backend. During that processing, a side-effect (that is unknown to the developer) results in that information being placed into an insecure location on the mobile device that other apps on the device may have open access to. Typically, these side-effects originate from the underlying mobile device's operating system (OS). An attacker can simply write a small piece of code to access the location where the sensitive information is stored.

What is the difference between Insecure Data Storage and Unintended Data Leakage?

This is something that is often confused. The second most exploited mobile threat is the Insecure Data Storage. In simple words, here's the difference between the two

Insecure Data Storage: Talks about conscious efforts to store data in insecure manner

Unintended Data Leakage: Talks about OS specific quirks which can cause data leakages

Are you vulnerable to Unintended Data Leakage?

Unintended data leakage (formerly side-channel data leakage) includes vulnerabilities from the OS, frameworks, compiler environment, new hardware, etc. without a developers knowledge.

In mobile development, this is most seen in undocumented (or under-documented) internal processes such as:

• The way the OS caches data, images, key-presses, logging, and buffers.
• The way the development framework caches data, images, key-presses, logging, and buffers.
• The way or amount of data ad, analytic, social, or enablement frameworks cache data, images, key-presses, logging, and buffers.

How to prevent Unintended Data Leakage?

There are some common leakage points that you have to monitor. It is important to threat model your OS, platforms, and frameworks, 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
• Logging
• HTML5 data storage
• Browser cookie objects
• Analytics data sent to 3rd parties

Example of Unintended Data Leakage

Firefox for Android stores the personal data under the profile directory, located at /data/data/org.mozilla.firefox/files/mozilla/.default.

(CVE-2014-1484) Profile Directory Name Leaks to Android System Log

The random Profile Directory Name is written to the Android System Log (logcat) in various locations. For instance, upon Profile creation, the following data is written:

D/GeckoProfile( 4766): Found profile dir: */data/data/org.mozilla.firefox* */files/mozilla/24pd90uh.default*

In Android 4.0 and below, the Android log can easily be read by all apps including malicious ones by acquiring the READLOGS permission. Android 4.1 has introduced a change to this behavior to prevent such log leakage attacks: The READLOG permissions are no longer required; however, applications can only listen to their own logs. We will next see how a malicious app can manipulate Firefox for Android to leak its own private log in order to overcome this obstacle.