Mobile
ContentProvider Path Traversal Flaw on ESC App Reveals Info
A flaw in how path traversal was coded in the health app led to possible data leakage.
Save to Folio
Trend Micro researchers have found similar ContentProvider path traversal vulnerabilities in three different applications available on Google Play, one of which had over 5 million installations. These three applications are a keyboard customization app, the shopping app of a popular department store, and the app for the European Society of Cardiology (ESC). Fortunately, the keyboard and department store apps have both been patched by their developers. However, as of writing, the ESC app is still active. A more thorough investigation of the vulnerability in the app shows that it is an avenue that a malicious actor can use to steal private information. Here we analyze the vulnerability and suggest guidelines to help developers avoid this type of bug in the future.
What is a ContentProvider?
To understand this vulnerability, the role of content providers must be clearly defined. According to the Android Developer site, it is the standard interface that connects the data in one process with code running in another process. It encapsulates the data and provides it to applications while also providing mechanisms for defining data security. Additionally, it is required for sharing data between multiple applications.
Simply put, content providers manage access to a structured set of data and allow data to be transferred from one process to another.
Step 1. Request from Process 1 ---------> Content Provider of Process 2 ------------> Process 2 data
Step 2. Process 2 data ----------> Content Provider of Process 2 -----------> Process 1
Fetching the data from Process 2 is as easy as querying the content provider.
Diving into the vulnerability
The vulnerability in the ESC Pocket Guidelines application version 4.4 for Android is a path traversal vulnerability that allows other applications on the device to request sensitive information. It also allows read/write privileges for the files inside internal storage.
When we investigated the app, we saw that when the ContentProvider is exported,
the openFile function was rewritten and no "../" filter was added.
This leaves the app vulnerable to information gathering — any information generated and left in the app, therefore, is potentially at risk. In the case of the ESC app, a user’s account information is at risk. Luckily, the app is simply a pocket resource for clinical practice guidelines in cardiology. If this vulnerability were present in an app containing more sensitive information, however, users would be at risk and the enterprise could be held responsible for a data breach.
To illustrate the danger of this vulnerability, we wrote a normal app that we named PoC or poc.apk. This app can access the content provider (com.esccardio.escpocketguidelines.FileContentProvider) of the ESC app. The following steps detail how we were able to get information from files inside the vulnerable application.
Preparing for the attack
Step 1
We installed the vulnerable ESC Pocket Guidelines application on the device. We made sure that we were running the latest version at the time of analysis. At the time of our analysis, there were over 100,000 installations of the app:
Step 2
We took the app we created and also installed it on the device. The following is the main code of the app:
After both apps (PoC and ESC Guidelines) were installed on the device, we ran the PoC app:
Step 3
After running the PoC app, we were able to get the content of internal files within the ESC app.
First, we found the kinds of files inside the app through a root command.
Afterward, we picked one of the files randomly to verify the vulnerability. In this first example, license.json was randomly chosen.
After selecting the file, we put the file name through the PoC app to trigger the bug. This was successful and we were able to see the contents of license.json (illustrated in the following). As stated previously, because the vulnerability has no “../” filter, we could use this bug to index the right file and access it.
The file AppInfo.xml was used in this second example. Again, the file was chosen in advance through an ADB shell root command.
We got the file path and wrote it into the PoC app. As a result, we were able to see the file contents.
Security Recommendations
Users often leave personally identifiable information (PII) on applications. In turn, this makes any vulnerability that allows data gathering a serious threat. This particular bug allows malicious actors to scrape any information generated and left in an app. It is therefore necessary to highlight this issue since it is a relatively common mistake that has a simple fix.
Additionally, we hope that developers can counter this vulnerability and take security into consideration when building their applications. To prevent a bug like this, a developer has to ensure that the corresponding content provider cannot be exported or that the openFile function must add a filter check such as "../".
Any malicious apps that take advantage of this vulnerability can be detected by Trend Micro solutions, such as the Trend Micro™ Mobile Security for Android™. End users can also benefit from its multilayered security capabilities that secure the device owner’s data and privacy and safeguard them from ransomware, fraudulent websites, and identity theft.
For organizations, the Trend Micro™ Mobile Security for Enterprise suite provides device, compliance, and application management, data protection, and configuration provisioning. It also protects devices from attacks that exploit vulnerabilities, prevents unauthorized access to apps, and detects and blocks malware and fraudulent websites. Trend Micro’s Mobile App Reputation Service (MARS) covers Android and iOS threats using leading sandbox and machine learning technologies to protect users from malware, zero-day and known exploits, privacy leaks, and application vulnerability.