What is unintended data leakage?
When an application processes sensitive information taken as input from the user or any other source, it may result in placing that data in an insecure location in 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.
Security risks
Code becomes vulnerable to serious attacks, since exploiting these side channel data leakage vulnerabilities is very easy. An attacker can simply write a small piece of code to access the location where the sensitive information is stored. We can even use tools like adb to access these locations.
Example scenarios for unintended data leakage
Below is the list of example scenarios where unintended data leakage flaws may exist.
Leaking content providers Copy/paste buffer caching Logging URL caching Browser cookie objects
Analytics data sent to third parties In the next section, I will demonstrate how some of the above scenarios can be exploited by attackers.
- Leaking content providers Though this is vulnerability doesn’t place its contents anywhere on the device, data can be easily extracted from leaking content providers using a malicious app. A detailed writing of how this can be accomplished can be read here. (Link to Article 2).
- Copy/paste buffer caching Copy/paste buffer caching is one more dangerous problems in Android devices. Users generally tend to copy and paste a lot of things due to the space limitations on the mobile screen. If a user copies any sensitive information such as credit card number to the clip board, an attacker can easily read it with a small piece of code running on the same device as shown below. This may lead to a serious damage since the attacker can access this information remotely sitting anywhere in the world using the app running on the victim’s device.
I have developed a simple app using the same piece of code given above to demonstrate how a malicious app can read the clipboard to access sensitive information copied by the user. The scenario is the user has copied a secret message to the clipboard when he is using a legitimate app. Now, we are reading that message from the clipboard using our malicious app. Below is the screenshot. Though we are just reading and printing the message on the screen for demo purposes, an attacker can remotely access this by sending it to a remote server controlled by him. 3. Logging Android “Logs” is a great place to look for information leakage. Logging techniques are generally used by developers for debugging purposes during their application development. In this section, we will see how an attacker can exploit this information leakage via logs. During a pentest, we can test for information leaks via logcat in multiple ways, as described in the next section. 3.1 Using Eclipse If you are running Eclipse IDE, connect your device/emulator to the machine. We can see all the logs under the “logcat” option when your app is running and observe if any sensitive information is logged. Below is the screenshot of a test application logging its user passwords in logs.
3.2 Using ADB We can also look at the logs using adb. First connect your device or emulator to your machine using adb and type the following command: adb logcat It will display all the logs in the terminal as shown in the figure below. We can inspect those logs for sensitive information. The figure below is showing the dump of all the system events along with the application logs we are interested to inspect. We can filter the output using the options available in logcat. -v verbose -d debug -i information -e error -w warning
We can even write this output into a file using the following command: adb logcat > output.txt Now we can save this output.txt file somewhere on the local machine and inspect it further. 3.3 Using a malicious application: We can even develop a malicious application which can read logs from the device using the following code.
Note: READ_LOGS permission is disabled for third party apps on the regular devices right from Jellybean (Android 4.1 API level 16). We can still run the code on rooted devices/emulators with elevated privileges. 4. URL caching and browser cookie objects There have been plenty of issues with web view based applications which leak URLs, cookies and cached information on the device, which allows an attacker to take over the session of the user. This caching could be in any form including logs, web history, web cache, etc. We can filter the logcat output using grep and inspect the logs for sensitive information such as cookies with the command shown below. adb logcat | grep “cookie” Many applications do not disable caching of the applications. This can be easily avoided using HTTP’s caching headers such as “no-cache”, “no-store”. There are numerous vulnerabilities reported on this. Please look at the references at the end of the article for more information on this. 5. Analytics data sent to third parties There could be scenarios where apps use third party APIs. Using this app, the third party APIs may read sensitive information such as device ID and location from the device.
Conclusion
As per the OWASP Mobile TOP 10 list released in 2014, unintended data leakage is in 4th place. Though it looks like a simple vulnerability, it creates serious risk depending upon the criticality of the information being leaked. So it is highly recommended for developers to look into this during the development of an application, as it is super easy for an attacker to detect data leakage by inspecting all mobile device locations that are accessible to all apps.
Sources
Mobile top 10 2014 Vulnerabilities Firefox android overtaking Firefox profiles Show bug Protocols
