Author: Xiangqian Zhang, Huiming Liu of Tencent Security Xuanwu Lab

0x0 Introduction

In this blog, we will detail our research on Android privacy protection apps. We investigated the privacy protection applications provided by the top five Android vendors and found that many applications do not protect our privacy well.

We proposed three threat models based on our research. And we will show four attack examples for the privacy protection applications.

0x1 Privacy protection apps

Nearly all top vendors develop and provide us some privacy protection apps such as Secure Folder, PrivateSpace, Safe, App Lock, etc. They can be categorized into three types:

1) Protecting the file access such as safe, file safe.

2) Protecting app usage such as app lock.

3) Private isolated space, such as secure folder.

The left picture shows a File Safe app. The user can store their files in it and protect them by setting a password and the files are encrypted. The middle picture shows App Lock which can protect users’ apps from unauthorized usage. The right picture shows private space and a secure folder app which can isolate multiple apps at the same time.

We investigated the privacy protection apps released by top five Android vendors and the result is shown here. All of them released at least one type of privacy protection apps and two of them released all the three types.

[*] Phones Shipments data: https://www.counterpointresearch.com/global-smartphone-share/

The question is: is our privacy really safe? So we begin our research.

0x2 Threat models

Privacy Protection apps protect files or apps or space with an independent password. So we expect them to keep files or apps or space safe even after the attacker break the normal space, or log in the Android os.

For File Safe: attackers can’t retrieve and decrypt file without valid authentication.
For App Lock: attackers can’t use the app without valid authentication.
For Private Space: attackers can’t access or modify or Insert anything in it without valid authentication.

We proposed the following attack methods:

A1: Attack from malicious apps
A2: Attack from malicious apps which can gain system previledge
A3: Attackers have physically compromise the phone
Our expectation is that attackers can’t get anything when: A1 or A2 or A3

But the fact is, all of them can be compromised.

0x3 Vulnerabilities

According to the above attack model, we found many vulnerabilities. And we choose 4 of them to present to you the details, they are typical and good examples.

Vul Type #1 - Steal data from the safe from malicious apps

Generally, You can move the secret files to safe and set the password. And the app will encrypt the secret files, then attackers cannot retrieve the file without the password. But we found that the encryption here is not safe at all. In this case, the encrypted files are stored in the SD Card.

And the encryption algorithm is AES/CTS/NoPadding.

But the key is generated by the deviceID, Key = md5 (packagename + deviceID ) +10.

Here is getDeviceId function.

As we can see, if the IMEI is not NULL: Key = md5(packagename+imei)+10.

If the MAC is not NULL: Key = md5(packagename+mac)+01.
if the IMEI/MAC is NULL: Key = md5(packagename+”0000000000”)+00.

So It only relys on the package name, IMEI ,MAC, which malicious apps or local attacker could easily get.

That seems a very simple vulnerability, but the case is not alone. This is another example.

The encryption algorithm is AES/ECB. The key generation is just a such fixed string: SHPLXYKZ.

We also found that another Safe is encrypted by XOR with a single byte.

Vul Type #2 - Retrieve the safe’s plaintext password from TrustZone

In our research , we found some vendors use TrustZone to protect the files. We are happy to see this because the TrustZone is capable to protect our privacy very safe. If the vendor store the key and data in TrustZone rightly, the hardware architecture will guarantee their safety.

[*] https://arxiv.org/pdf/1506.07367.pdf

In the introduction of the Safe app, it says that the password is not stored and cannot be restored.

Our expectation is this:

Step 1: Input password.

Step2: The file safe app send the password to TEE interface to check.

Step3: The tee interface send the password to check to TrustZone.

Step4: The TrustZone app is responsible to check that the password is valid and return the result.

Step5: If check ok, the TEE interface will send the message to file Safe app.

Step 6: Then the File safe app will use the input password to decrypt the file and display it to users.

Step 7: The user get the decrypted file.

The PlainText password never leaves the trust world. No one can get the password of the Safe, even if the phone is rooted

However,the fact is this:

In step 3, the TEE interface get the password from TrustZone.

Step 4: The TrustZone app will return the plaintext password to normal world, and then compare it to the password which user input. If checked OK,the user get the decrypted file. So the PlainText password leaves the trust world. It will not safe anymore.

This picture shows the function to extract the password from TrustZone. The function’s Input is boxFolderName which is the File Safe’s folder name, and the return value is plaintext password.

We can easily call this function to get all the File Safe’s password in the Normal World. The TrustZone is totally useless in this scenario. What a pity! They did so many efforts in TrustZone to improve the safety, but they are totally ruined by such a simple design flaw.

Vul type #3 Bypass the privacy password

We found almost all privacy apps can be unlocked by Fingerprint. But some privacy apps failed to check the the Fingerprint is new added or not. So the attacker can add a new Fingerprint to bypass the authentication.

And also you can easily reset the privacy app’s password with SMS verification code on some vendors’ phone if you can unlock the phone.

Vul type #4 Break the private space totally

Finally, Let’s talk about the last type, private space apps. In their introduction, the vendors says : The users can create a secure space on your device to encrypt and store your private data and apps. Apps and data in Secure Folder are sandboxed separately on the device and gain an additional layer of security and privacy, thus further protecting them from malicious attacks.
The secure folder seems very safe, so we were curious about its implementation. We reverse engineered the app, and we found it call the android UserManager multi-user api to create another user.

This is the output of adb shell command pm list users.

When we activate the secure folder, another user named “Secure Folder” will be added in the system. It confirmed our guess.

Android supports multiple users on a single Android device by separating user accounts and application data. For instance, parents may allow their children to use the family tablet, a family can share an automobile, or a critical response team might share a mobile device for on-call duty. For more detailed information, please visit: https://source.android.com/devices/tech/admin/multi-user

The users’ data are stored separately on the device. Here is the data path.

1 2	/data/user/<userId>/<app.path> /storage/emulated/<userId>

And there are some commands for us to manage other users as primary users. For example, pm,am,adb install and etc. We can also use content provider to read or write other user’s data.

The primary user can install and control user-install apps and access any data in it.

So, we can break the private space by these commands easily.

1. Install malicious Apps:

adb install --user ID myApp.apk

2. Start app:

adb am start --user ID com.example.app

3. Grant permission:

adb shell pm grant --user ID com.herbo.test android.permission.READ_EXTERNAL_STORAGE

4. Steal data from secure folder:

adb shell content write --user ID --uri content://android.tradefed.contentprovider/sdcard/some_file.txt < local_file.txt

adb shell content read --user ID --uri content://android.tradefed.contentprovider/sdcard/some_file.txt > local_file.txt

We make a demo to show this attack.

This is a common vulnerability. All the private space based on multi-user can be exploited.

0x4 Mitigation

Based on the vulnerabilities, we proposed the following mitigations.

For Developers:

1) Use the TrustZone properly.

2) SD Card is not safe at all. Don’t use it when you are very careful about your privacy.

3) Don’t use IMEI/MAC as key or to generate key. Use android_id will be better. Because android_id varies for different apps (after Android O).

4) Take local attacks more seriously.

For Users:

1) Don’t rely on privacy protection Apps.

2) Keep good security habit is more useful.

0x5 Conclusion

Nearly all top vendors develop and provide us some privacy protection apps such as Secure Folder, PrivateSpace, Safe, App Lock and so on. They claim that saving private files in those apps will be safe. However, we conducted comprehensive research about them and found that it is not true for most of them. Many design or development flaws allow attackers to bypass the protection and access the privacy files inside, which will affect billions of users.

We presented 4 types of vulnerabilities and advices for developers and users. By sharing our research, we want to improve the security of the privacy protection apps and better protect users’ privacy.

All vulnerabilities are reported to vendors in April 2020 and most of them are fixed.

The content of this article is from our Blackhat Asia Briefing:

https://www.blackhat.com/asia-21/briefings/schedule/#a-mirage-of-safety-bug-finding-and-exploit-techniques-of-top-android-vendors-privacy-protection-apps-22336