Reflection on allowBackup sensitive information leakage in Android Application Development

Reflection on allowBackup sensitive information leakage in Android Application Development
1. Background

In fact, this article may make a little fuss, but it is necessary to go back and think about it. We believe that Android API Level 8 has provided the function of backing up and recovering data for applications. This function can be switched through AndroidManifest in the application. the allowBackup attribute value of the xml file is configured. The default value is True. Therefore, you can back up data in our applications. I believe that many people have passed the Android feature just like me and have never taken care of it. However, the old story is as follows:

Not long ago, I suddenly received a Bug report from the famous ChineseWhite hats organize wooyun PlatformI will not introduce this Organization. I believe everyone knows the seriousness of the problem. It is very fast to fix this Bug, however, after fixing this Bug, I had to think about it (just like dealing with SQL injection), so I wrote this record.

In fact, the risk principle of allowBackup is mainly to allow the use of adb backup to back up the data of the device that enables USB debugging. Once the backup file is obtained, it is hard to say, for example, evil people can recover your data to their own devices through adb restore, and then play with the App completely on their own devices in your name; you can also use the code to analyze the core information such as the account and password that you log on to the App in the backup file. In short, Google designed its core to facilitate data backup, but applications developed by everyone seem to ignore the problems of mobile phone loss or being discovered by others, for example, if an application such as Address Book, business card, and payment has serious consequences, pay attention to it.

2. Restore an instance

In order to verify the major sensitive information leakage problems caused by this small problem, We will select several representative apps for testing, so that you can intuitively feel the crisis of leakage.

Note:The applications involved in this example are only verified, and this issue generally does not cause too many risks. Therefore, please keep yourself updated and do not slander application developers; of course, I have submitted vulnerabilities for the following applications through the wooyun vulnerability platform. I believe these applications will soon be solved in the new iterative version.

Simplified book Android 1.9.7 Testing

Conclusion:Account theft may occur.

Verification:After logging on to the account and password of device A, follow these steps:

Then run the following command on the device to back up the data to the computer:

XXX@ThinkPad:~/workspace/myself/temp$ adb backup -f back.ab -noapk com.jianshu.harukiNow unlock your device and confirm the backup operation.

Install this application on Device B without logging on to any account or password. Run the following command:

XXX@ThinkPad:~/workspace/myself/temp$ adb restore back.abNow unlock your device and confirm the restore operation.

As you can see, Device B has not logged on to the account and password, but successfully logged on to device A by restoring the backup data of device.

Sina Weibo Android 5.1.0 Test

According to the test procedure shown above, the Data recovered from device A on Device B is invalid. Device B still displays the following information:

That is to say, Sina Weibo has taken a thorough consideration and has fixed this potential risk of leakage. The backup data recovery is invalid and you still need to log on again to give a thumbs up.

Test mint Android 5.4.5.1

Based on the above operations, you will find that you can log on to device B without logging on to the account. You only need to restore the backup account information of another user to access the account interface of another user, as shown below:

In the case of Device B, you can directly operate the account of device A on Device B.

3. Reflection and summary

After reading the above two sections, you may also be aware of the potential severity of the problem. Google's initial intention is good, however, once the breakthrough point is reached by someone with ulterior motives, the problem will be serious. For example, if you are more advanced, someone with ulterior motives will write a piece of code to execute data backup and upload it to your cloud server. Then, the backup data will be parsed. If you are small, your personal information will be leaked, you know.

In this case, you will certainly be concerned about the solution. The specific solution is easier, as shown below:

Solution 1:

Set Android: allowBackup = "false" directly in your android inventory file, as shown below:

Solution 2:

Do not set Android: allowBackup = "false" in your android inventory file to allow backup. However, on the application startup page, perform logical checks to determine whether to log on again, for example, you can check whether the unique identification device Number of the device is consistent with that before the backup. Otherwise, you can directly go to the login page and clear the data and cache of the current application.

Well, I am not so confident in my opinion. I just wrote a summary for the project being fed back by wooyun. At present, we have adopted solution 1 similar to Sina Weibo.