Exploiting unintended data leakage (side channel data leakage)
In this article we will learn about Exploiting unintended data leakage.
What is Exploiting unintended data leakage?
In previous articles, we discussed attacks associated with activity components, content providers, broadcast receivers and ways to secure them. In this article we will discuss about “Inadvertent Data Leakage” which was earlier known as “Side Channel Data Leakage”.
When an application processes sensitive information received as input from a user or other source, it may result in that data being placed in an insecure location on the device. This unsecured location could be accessible to other malicious applications running on the same device, putting the device at serious risk.
Security risks
The code becomes vulnerable to serious attacks because these side-channel data leakage vulnerabilities are very easy to exploit. An attacker can simply write a small piece of code to access where sensitive information is stored. We can even use tools like adb to access these locations.
Examples of scenarios for inadvertent data leakage
Below is a list of example scenarios where there may be inadvertent data leakage errors.
- Content leak providers
- Copy/paste to cache
- Logging
- URL caching
- Browser cookie objects
- Analytical data sent to third parties
In the next section, I will show how some of the above scenarios can be exploited by attackers.
1.Content leak providers
Although this vulnerability does not place its content anywhere on the device, data can easily be extracted from content leak providers using a malicious application.
A detailed description of how this can be achieved can be read here. (Refer to Article 2).
2.Copy/paste to cache
Copy/paste caching is another dangerous problem in Android devices. Users generally tend to copy and paste a lot of things due to the limited space on the mobile screen. If a user copies any sensitive information, such as a credit card number, into the clipboard, an attacker can easily read it using a small piece of code running on the same device as shown below. This can lead to serious damage as the attacker can access this information remotely from anywhere in the world using an application running on the victim’s device.
I developed a simple application using the same code above to demonstrate how a malicious application can read the clipboard to gain access to sensitive information copied by the user.
Related Article:Ethical Hacking Interview Questions 2023
The scenario is that a user has copied a secret message to the clipboard while using a legitimate application. Now we read this message from the clipboard using our malicious application. Below is a screenshot.
Although we are only reading and printing the message to the screen for demonstration purposes, an attacker can access it remotely by sending it to a remote server they control.
3.Logging in
Android “Logs” is a great place to look for leaks. Logging techniques are generally used by developers for debugging purposes during application development. In this section, we will see how an attacker can exploit this information leak through logs. During a pentest, we can test for information leaks via logcat in several ways, as described in the next section.
3.1 Using Eclipse
If you are using Eclipse IDE, connect the device/emulator to your computer. When your app is running, we can see all the logs under the “logcat” option to see if any sensitive information is logged. Below is a screenshot of a test application logging its user passwords.
3.2 Use of ADB
We can also look at the logs using adb.
First, connect your device or emulator to your computer using adb and type the following command:
adb logcat
It will display all the logs in the terminal as shown in the image below. We can check these logs for sensitive information. The image below shows a listing of all system events along with the application logs we want to check. We can filter the output using the options available in logcat.
-v verbose
-d debugging
-i information
-e error
-w warning
We can even write this output to a file using the following command:
adb logcat > output.txt
Now we can save this output.txt file somewhere on the local computer and view it further.
3.3 Use of a malicious application:
We can even develop a malicious application that can read the logs from the device using the following code.
Note:
The READ_LOGS permission is disabled for third-party apps on mainstream devices directly from Jellybean (Android 4.1 API level 16). We can still run code on rooted devices/emulators with elevated privileges.
4.URL caching and browser cookies
There have been many issues with webview-based applications that leak URLs, cookies, and cached information on the device, allowing an attacker to take over the user’s session. This caching can be in any form including logs, web history, web cache, etc.
We can filter the logcat output with grep and check the logs for sensitive information like cookies using the command below.
adb logcat | grep “cookie”
Many apps don’t disable app caching. This can be easily avoided using HTTP cache headers such as “no-cache”, “no-store”.
Many vulnerabilities are reported in this regard. For more information, please see the references at the end of the article.
5.Analytical data sent to third parties
There may be scenarios where applications use third-party APIs. Using this app, third-party APIs can read sensitive information from the device, such as device ID and location.
Conclusion
According to the OWASP Mobile TOP 10 list released in 2014, accidental data leakage is in 4th place. Although this looks like a simple vulnerability, it creates a serious risk depending on the criticality of the leaked information. Therefore, developers are strongly advised to look into this during application development, as it is very easy for an attacker to detect a data leak by checking all mobile device locations that are accessible to all applications.
