What level of attacks can Android enable by enabling USB debugging?

0x01 Original Intention and Applicable Scenarios

Android’s USB debugging mode is designed for developers. Developers can use it to debug or test applications during the application development process.

adb provides a series of functions that are helpful for development, such as application installation and uninstallation, backup and recovery, log output and filtering, and it also provides a very user-friendly adb shell with considerable permissions.

In addition to developers, reverse analysts also use the adb interface when conducting reverse analysis and dynamic debugging of applications. For example, through this interface, they can dynamically debug and track so or smali, and dynamically debug some functional codes. Verify and so on.

However, convenience and security are inversely proportional to a certain extent. Under its rich functions, there are also a series of security issues.

0x02 Adb information leakage and permission leakage problem

If the debugging information output by logcat is not deleted when the application is released, it is very likely to cause sensitive information to be leaked. In minor cases, for example, logcat may print out the application The visited web page link or some other intermediate variables may also leak the account password. After all, the threshold for Android development is low, and the level of developers is inevitably uneven.

In order to facilitate debugging, developers may even write like this:

Android logcat information leaks have been disclosed many times in the past, such as:

WooYun: Tuniu.com app logcat information leaked users’ Group chat content

WooYun: Surfing browser logcat outputs user text messages

WooYun: Hangzhou Bank Android client login account and password information is leaked locally

In addition, many Android application vulnerability scanning platforms currently on the market will also focus on logcat The abuses are scanned and presented in the report, such as Tencent King Kong Audit System, Alibaba Security, 360 Risk Mirror (former Bug Hunter), etc. This also reflects the universality of this problem from the side.

In addition to the mistakes of developers, there are also some flaws in the design of adb itself. There was once a paper that specifically studied this issue: "Bittersweet ADB: Attacks and Defenses".

Through ADB or an Android application that has applied for ADB permissions, you can monitor private information such as text messages and phone records without applying for permissions, monitor/simulate screen click events, access private directories of other applications, and monitor Android devices Conduct DoS attacks, etc.

Most of the above behaviors can be obtained through the adb shell dumpsys command. For more details, please see the reference link [2].

0x03 Android backup problem

This is a very old problem. In low-version Android systems, when backing up an application, its private data will be backed up, and then you can Specific tools extract them, as shown below:

So what are the private data of applications? First of all, there will be personal identity credentials, or account passwords or other credentials. Generally, applications have private data I am quite confident. After all, it is called "private data", so many applications directly store it in plain text. Although some are encrypted, the data can be decrypted through reverse analysis of the application. For example, from a certain The content backed up in the client contains the following files:

You can find the decryption process by reverse engineering the apk, and you can decrypt it by copying the decryption class and method:

Another example is WeChat’s database , some articles have analyzed the encryption process of the WeChat database and given the method of generating the encryption key. If the WeChat local database, uin, and imei are obtained at the same time, the encryption key of the database can be calculated based on the latter two. And decrypt the encrypted database. At this time, all your chat records will be directly exposed to the sun.

In addition to directly manually decrypting the data, you can also restore the data intact to another mobile phone through adb restore, thereby forging identity, such as the article on droidsec "Steal the Weibo account of the goddess around you in two minutes" (refer to Link [4])

Some people have noticed that when using adb backup, you need to manually click to confirm before backing up. If the attacker does not have the opportunity to click on the screen, there will be no problem. However, Android has a mechanism called the input and output subsystem. In adb The sendevent command can be executed under the shell and can simulate various user inputs. Each model is different. On my machine, sending the following event can simulate the click and allow operation:

#EV_KEY BTN_TOUCH DOWN sendevent /dev/input/event7 1 330 1 #EV_ABS ABS_MT_POSITION_X 366 sendevent /dev/input/event7 3 53 366 #EV_ABS ABS_MT_POSITION_Y 690 sendevent /dev/input/event7 3 54 690 #EV_SYN SYN_REPORT 00000000 sendevent /dev/input/event7 0 0 0 #EV_KEY BTN_TOUCH UP sendevent /dev/input/event7 1 330 0 #EV_SYN SYN_REPORT 00000000 sendevent /dev/input/event7 0 0 0

0x04 through adb stallion

Since it is through adb The application can be installed, and it is silent, so naturally it can be used for you without the user being aware of it.

However, ordinary horses may not have icons and interfaces to increase the chance of being discovered, and applications that have not been launched cannot run, which means that the BroadcastReceiver they registered cannot receive anything. It needs A process of awakening.

Fortunately, adb shell can also realize this wake-up process. The adb shell am command can start specific components of specific application packages, so that the pony can run successfully.

Of course, if the attacker has a more powerful method, such as directly adb pushing an exploit and elevating privileges to root, it will be simpler and more crude.

0x05 Malicious code injection

This method is relatively elegant. When connected to USB debugging, you can use a series of commands to inject a custom malicious code into the installed application on the phone. This code It can be as simple as playing a greeting, or it can be very complicated remote control.

In order to further increase the credibility, you can choose an application that has applied for high permissions for injection. For example, after injecting an address book management software, it requests to read your contact list, which seems to be fine.

Although academia and industry have many measures to prevent repackaging, in actual tests, the success rate of this attack method is really not low, and even if the injection into an application fails, the crudest method can still be used. pm list packages -3 List all packages and try it again.

The following I wrote a simple program to inject a metasploit meterpreter http reverse shell payload into an application on a mobile phone with USB debugging turned on. There is no need to perform any operations on the mobile phone during the whole process. The general workflow is as follows:

When you click the injected application again, you will receive a meterpreter shell on the handler opened on the listening server:

The above, you can remotely control the Android application on the server side , after getting the Android meterpreter shell, you can do many things, including privacy stealing, sending text messages, opening web pages, taking screenshots, and taking photos.

Even, you can call your front and rear cameras for real-time monitoring.

Some of the commands supported are as follows:

0x06 Finally

In Android versions after 4.4, if you want to connect to adbd on an Android device, you need to verify the fingerprint of the host machine, which to a large extent Reduces the possibility of being attacked through these methods. However, today's Android management software on PC strongly encourages you to turn on USB debugging, and will even teach you step by step how to turn it on, so a considerable number of people are still exposed to this risk.

As you can see from the above, there are still many things that can be done through adb. The above are just some of the commonly used methods. If you want to completely prevent being attacked by the above methods, the simplest and most effective way is to turn off USB debugging. , and try to download trusted applications from regular application markets.

After all, imagine if you are at a train station or a public place, using a public charging socket that someone put there, and there is a malicious computer behind it, and you happen to open it, or you are induced by it to open it. USB debugging...