
BLOG
BLOG
Continuing with our series on the OWASP Top 10 Mobile threats, the fourth most exploited mobile threat is called 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.
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.
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
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:
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:
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.
We have so many ideas for new features that can help your mobile app security even more efficiently. We promise you that we wont mail bomb you, just once in a month.