Exploring USB Connection Vulnerabilities on Android Devices

Breaches using the Android Debug Bridge

ao Amarante

and Jo

ao Paulo Barros

1,2

Polytechnic Institute of Beja, Beja, Portugal

UNINOVA-CTS, Monte de Caparica, Portugal

Keywords:

Vulnerability, USB, Smartphone, Mobile Device, Computer Security, Physical Attack, Internet of Things,

IoT, Mobile Cyber-physical Systems.

Abstract:

The complexity of avoiding vulnerabilities in the modern mobile operating systems makes them vulnerable

to many types of attacks. This paper presents preliminary work in the creation of scenarios to surreptitiously

extract private data from smartphones running different versions of the Android Operating System. Three

scenarios were already identiﬁed and a proof of concept script was developed, all based on the use of the

Android Debug Bridge tool. When running in a computer, the script is able to extract private data from a USB

connected smartphone. In two scenarios it was possible to extract the information in a totally surreptitious way,

without the user knowledge. In the third scenario, using a newer version of the Android operating system, a

user action is needed which makes the attack less likely to succeed, but still possible.

1 INTRODUCTION

In a world increasingly dominated by complex tech-

nologies, their negligent or ill-informed use provides

the opportunity for attack scenarios, which from the

point of view of programmers would seem improba-

ble. This current generation of smartphones like the

Apple iOS and Google Android based devices are

powerful enough to accomplish most tasks that pre-

viously required a personal computer. In fact, this

newly acquired computing power has given rise to

many applications that try to leverage new hardware.

These include Internet browsing, e-mail, GPS naviga-

tion, personalized messages and applications, among

others. Additionally, mobile devices provide an ideal

support for mobile cyber-physical systems. All these

contribute to the presence of a large amount of per-

sonal data that is stored inside the device.

Among the many different devices that make the

Internet of Things, the smartphones are still the most

ubiquitous and also the ones with more users unaware

of the related risks. This work focus on security and

privacy in mobile systems, namely a speciﬁc type of

attack to that kind of device: the exploit of USB con-

nection vulnerabilities to target private data in An-

droid devices (Google, 2017).

Android is being used by more than 2.1 billion

people around the world (Statista, 2017) and the ubiq-

uitous use and widespread adoption of the Universal

Serial Bus (USB) led mobile device manufacturers to

equip most third generation phones with USB ports.

With such a large number of consumers, the space to

produce a malicious attack is huge: whenever some-

one with an Android device connects it using a USB

port the device can potentially become compromised.

A small ﬂaw, error, or misinterpretation of a security

authority speciﬁcation can potentially jeopardize the

security of those systems. Proximity attacks, namely

the ones based on the USB connection, are a good

example of this and anecdotal evidence seems to indi-

cate that the associated risks are easily neglected by

users; in fact, a similar behaviour was already ob-

served regarding USB drives (Tischer et al., 2016).

Currently, USB connections are primarily used as

a means of charging the battery, communicating, and

synchronizing the contents of the phone with com-

puters and other phones. An important form of at-

tack occurs when private data is extracted from mo-

bile devices without user permission. The apparent

unawareness of many users regarding the risks of con-

necting their device to a compromised computer led

to the theme of this paper: the vulnerabilities in the

Android USB connection. The work in this paper is

part of a detailed study and evaluation of the USB

based vulnerabilities present in devices running the

Android Operating System: we present three concrete

572

Amarante, J. and Barros, J.

Exploring USB Connection Vulnerabilities on Android Devices - Breaches using the Android Debug Bridge.

DOI: 10.5220/0006475905720577

In Proceedings of the 14th International Joint Conference on e-Business and Telecommunications (ICETE 2017) - Volume 4: SECRYPT, pages 572-577

ISBN: 978-989-758-259-2

and implemented scenarios resulting from the use of

the Android Debug Bridge tool to extract private data

from smartphones, following a connection between

the Android mobile device and a compromised per-

sonal computer. Three scenarios were already identi-

ﬁed and a proof of concept script was implemented to

extract private data when a smartphone is connected

to a computer. In two scenarios, it was possible to

extract the information in a totally surreptitious way,

without the user knowledge. In the third scenario, us-

ing a newer version of the Android operating system,

a simple user action is needed which makes the attack

less likely to succeed, but nevertheless clearly possi-

ble for less aware or knowledgeable users.

Section 2 present background information about

the Android system and its security model. Section

3 presents the tested scenarios; Section 4 describes

the implementation of the script used to extract data

from smartphones without user awareness; Section 5

discusses related work and Section 6 concludes.

2 BACKGROUND

Android is an application execution environment for

mobile devices that includes an operating system, ap-

plication framework, and core applications. Here, we

brieﬂy present the problem of USB based vulnerabil-

ities and the ADB tool.

2.1 Vulnerabilities in USB Connection

The USB protocol is fully software controlled; there-

fore, it is similar on all Android devices. There are

two sub-protocols that are supported by Android: (1)

the mass-storage class (for example a USB removable

disk) and (2) the Android Debugger Bridge (ADB).

Each peripheral function has an associated device

class document that speciﬁes the default protocol for

that function. This allows hosts compatible with the

class and peripheral functions to interact without de-

tailed knowledge of each other’s operations. Class

compliance is potentially dangerous if the host and

peripheral are provided by different entities.

The USB connection does not support the network

class, audio class, or other classes, such as mass stor-

age class (MSC) or Media Transfer Protocol (MTP).

By default, ADB is disabled, and the computer refers

to Android as a mass storage device, with none of the

additional functions.

Initially, only the device’s SD card is exposed via

USB, rather than its system and data partitions. When

”USB debugging” (ADB) is enabled, the device can

be controlled with the same ”adb” tool that is pro-

vided in the Android SDK. This tool makes it possi-

ble to insert and retrieve ﬁles from and to the device,

install APK ﬁles, TCP and UDP redirects, etc.

Due to the vulnerabilities that this process pre-

sented, since version 4.4.2 (KitKat), Google has cre-

ated a security process for this connection: ADB

pairing, the pairing between a USB connection and

an Android Debug Bridge (ADB). Making sure each

USB connection has a pair of RSA keys accepted by

the host computer that the Android device will con-

nect to, so that each time the Android smartphone

tries to connect to a new host, it must have been pre-

viously accepted by it.

Next, we present the ADB tool, which was used to

implement the attack scenarios described in this pa-

per.

2.2 The Android Debugger Bridge

The Android Debug Bridge (ADB) (Android Open

Source project, 2017) is a command line tool that al-

lows communication with a connected Android de-

vice or an emulator allowing several actions, namely

through a Unix shell. It facilitates several device ac-

tions including app installation and debugging appli-

cations. It is a client-server program with three com-

ponents: (1) A client, which sends commands and

runs on the development computer — it is possible

to issue an adb command to invoke the client from

a command line terminal; (2) A daemon, which exe-

cutes commands on a device and runs as a background

process on each emulator or device instance; (3) A

server, which manages communication between the

client and the daemon; the server runs as a back-

ground process on the development computer.

When starting, an adb client checks to see if there

is an adb server process running. If not, the adb client

starts the server. When the server is started, it binds

to local TCP port 5037 and listens for commands sent

from adb clients. All adb clients use that same port to

communicate with the adb server.

The server then conﬁgures connections to all em-

ulator/device instances that are running. It locates

the emulator/device instances with an odd-port scan

in the range of 5555 to 5585, which is used by em-

ulators/devices. Where the server encounters an adb

daemon, it conﬁgures a connection to the port in ques-

tion. Each emulator/device instance acquires a pair of

sequential ports: an even-numbered port for console

connections and an odd-numbered port for adb con-

nections.

When the server conﬁgures connections for all

emulator instances, it is then possible to use adb com-

Exploring USB Connection Vulnerabilities on Android Devices - Breaches using the Android Debug Bridge

573

mands to access those instances. Because the server

manages the connections to the emulator/device in-

stances and manages all commands from multiple adb

clients, it is possible to control any emulator/device

instance of any client (or script). More information

about the ADB can be found at the ofﬁcial site from

where this information was also extracted (Android

Open Source project, 2017).

3 SCENARIOS

Three scenarios for the retrieval of private informa-

tion were identiﬁed. All are associated with the USB

connections. After, a script was implemented allow-

ing the following actions:

1. Obtain device information;

2. List of all installed packages;

3. Full copy of the entire SD card contents;

4. Copy a ﬁle to the device;

5. Install an application on the device;

6. Run an application on the device;

7. Obtain the contact list;

8. Obtain the messages;

9. Unlock the device screen;

10. Overcoming the ADB Pairing;

11. Rooting the device.

For mobile devices, three devices, each with a dif-

ferent version of Android, were tested. Speciﬁc con-

ditions were also tested for each version. USB debug-

ging is essential to exploit the vulnerabilities consid-

ered in this work, since the only contact of the phone

with the machine containing the script is through a

USB cable.

It was decided to write a script for the Windows

7 Home Premium Operating System using one of its

available tools: the Windows PowerShell ISE 5.0

Hence, the ﬁle has the .ps1 extension, which is the for-

mat associated with Windows PowerShell from Mi-

crosoft Corporation. The three scenarios correspond

to vulnerabilities that the script is able to exploit.

The versions used represent a small percentage of

the devices that have recently visited the Google Play

Store

, but the real number of these devices in use

is probably quite higher, as older and rooted devices

e.g. https://msdn.microsoft.com/en-us/powershell/script

ing/core-powershell/ise/introducing-the-windows-

powershell-ise

https://developer.android.com/about/dashboards/index.html

are much less likely to access the Play Store and the

number of rooted devices can be higher than usually

expected (e.g. (BusinessofApps, 2015; arsTechnica,

2016)). Additionally, it is easy to ﬁnd sites teach-

ing how to enable USB debugging, apparently with

no warnings about the possible associated risks (e.g.

(TechAdvisor, 2016; Hacks, 2015)). Also the third

scenario is also signiﬁcant and applicable to newer

versions of the Android system. Yet, to date, only

version 5.0 Lollipop was tested.

• Attack Scenario I:

Conﬁguration:

– Hardware: Samsung Galaxy Mini GT-S5570

– Android version: 2.2 (Froyo)

– USB debugging on

– Device rooted

Achieved results:

1. Obtain device information;

2. List of all installed packages;

3. Full copy of the entire SD card contents;

4. Copy a ﬁle to the device;

5. Install an application on the device;

6. Run an application on the device;

7. Obtain the contact list;

8. Obtain the messages;

This is the simpler attack scenario, as the debug-

ging is on and the device is rooted. This device

has a speciﬁc feature that, in practice, can increase

the vulnerability of USB Debugging: the user can

”enable” the connection, but keep it ”inactive”,

possibly giving a false sense of protection, but si-

multaneously leaving the door open to an attack.

In this way, and with rooting access to the device,

it was possible to obtain all type of desired infor-

mation, compromising the device security.

• Attack Scenario II:

Conﬁguration:

– Hardware: Sony Xperia Miro ST23i

– Android version: 4.0.4 (Ice Cream Sandwich)

– USB debugging on

– Device ”unrooted”

Achieved results:

1. Obtain device information;

2. List of all installed packages;

3. Full copy of the entire SD card contents;

4. Copy a ﬁle to the device;

5. Install an application on the device;

SECRYPT 2017 - 14th International Conference on Security and Cryptography

574

6. Run an application on the device;

If application roots the device than the follow-

ing three are also possible:

(a) Obtain the contact list;

(b) Obtain the messages;

In this scenario there is no rooting access to the

device, which would limit the range of possible at-

tacks. However, by enabling USB debugging, the

device is still exposed to SD card attacks, namely

the extraction of private data.

• Attack Scenario III:

Conﬁguration:

– Hardware: Aquaris E5 HD

– Android version: 5.0 (Lollipop)

– USB debugging off

– Device ”unrooted”

Achieved Results:

It was not possible to extract data from the device.

Yet, it was possible to conﬁrm that, if USB debug-

ging is changed to ”on” and after ADB pairing,

the script can still extract data .

4 IMPLEMENTATION

The developed script is based on the auto-detection

of a USB connection: when a device is connected

to a computer, it will be automatically detected and

the script will be started. Once the device is identi-

ﬁed, various attempts to obtain information will be

made through Windows PowerShell ISE 5.0 and/or

Android Debug Bridge (ADB) commands. All these

processes are invisible to the victim and through

them one can access the entire contents of the SD

card and also various information of the device. At

http://y2u.be/TDgUgxgOt o, a screencast shows the

script being run when a smartphone is connected to

the compromised host computer. Next, we present

what is executed by the script and the respective re-

sults for each of the actions listed in Section 3:

1. Obtain Device Information: It was possible to

obtain the identiﬁcation of the device, as well as

information about it, such as the letter assigned by

the Operating System, the Android version, and

the model. These data includes the paths to exe-

cute the intended attacks.

2. List of All Installed Packages: Obtaining a list

of all packages installed on the device was then

used to get the exact name that the system assigns

to each package. This was useful to retrieve data

about the application that was installed in order to

execute it. In the item Run an application on the

device the usefulness of this information will be

explained.

3. Full Copy of the Entire SD Card Contents: Due

to the little storage space that the devices have,

most users save a large amount of personal con-

tent on the SD card. This action retrieves all the

ﬁles and folders of the card such as photographs

and movies.

4. Copy a File to the Device: Once the script gets

the contents of the SD card, it can copy a ﬁle (in

this case an application that allows you to do An-

droid Rooting) to the device and verify that it was

on the card. This process allows putting in the SD

card any type of ﬁle. If it is a malicious one, it be-

comes possible to compromise the whole device.

5. Install an Application on the Device: As the ﬁle

copied to the device was an application it became

possible to perform its installation. This process

is extremely dangerous for the device if the ap-

plication being installed is some type of malware,

capable of corrupting it in any way.

6. Run an Application on the Device: After in-

stalling the application on the device is was possi-

ble to execute it, which in the case of being a mali-

cious application raises serious security problems

This process happens due to the fact that it is pos-

sible to obtain a list of all installed applications

and their information. From this list it is possible

to get the exact path to execute the full command

to run the application.

7. Obtain the Contact List: One of the main re-

sults was the retrieval of private information from

the device. In this case the contents of the contact

list have been copied. This is only possible if the

device is rooted, but since it was possible to copy,

install and run applications, with USB debugging

on, it was possible to do this invisibly to the victim

and obtain this type of information. After grant-

ing root access, it is then possible to change access

permissions to the protected content, so that it is

possible to give the command to copy the infor-

mation, which allowed the retrieval of the desired

list in SQL and plain text format.

8. Obtain the Messages: The content of all mes-

sages in the device was another type of retrieved

data. Using the previously described process it

was also possible to obtain the information of the

respective list in SQL and plain text format.

9. Unlock the Device Screen: In the identiﬁed

and implemented scenarios it is possible to by-

Exploring USB Connection Vulnerabilities on Android Devices - Breaches using the Android Debug Bridge

575

pass/disable the pattern unlock on Android via

ADB Commands, but only if two special condi-

tions are met: (1) the device is rooted and (2) the

pin code known. This is because it is necessary

to remove or update the system ﬁle containing the

screen lock key, which is only possible by chang-

ing the access permissions to it, as described pre-

viously, and restarting the device, which requires

the pin code.

10. Overcoming the ADB Pairing: If the device is

rooted, it is possible to eliminate this security en-

hancement by removing the system ﬁle containing

the ADB pairing key. However, to eliminate this

issue permanently, a ﬁrst access to the device must

be given.

11. Rooting the Device: It is possible to root a de-

vice, simply by copying, installing, and running

an application.

5 RELATED WORK

USB connection is just one of several ways to ex-

ﬁltrate data from mobile devices. (Do et al., 2015)

presents a catalogue of those methods and provides a

good starting point to this subject. Here we focus on

USB connections. Due to its relative importance and

relation to USB exﬁltration, we also discuss an avail-

able USB device that is able to disguise as a keyboard

thus providing a medium to extract data from other

devices.

As already stated, USB connections have been tra-

ditionally trusted mostly due to the physical proximity

it implies but also due to the presumption that both

devices belonged to the same owner. The work by

(Wang and Stavrou, 2010) was possibility the ﬁrst to

demonstrate that this trust could be abused. In par-

ticular, it discusses attacks where a smartphone acts

as Human Interface Device and sends keystrokes to

control the victim host showing how to boot a smart-

phone to take over another phone using a specially

crafted cable. The same article, also proposes defence

mechanisms to counter those USB attacks. In (Wang

et al., 2012) additional proposals are presented and

discussed.

The work by Xu (Xu, 2014; Xu et al., 2015) found

that the feature available in Android 4.2.2 cannot pro-

vide sufﬁcient protection when the host machine con-

nected to the Android device has been compromised.

It presents an implementation demonstrating this vul-

nerability. Hence, it complements the work here pre-

sented.

(Pereira et al., 2014) presents a vulnerability to

exploit the USB connection in a vendor customiza-

tion that allows extending the reach of AT (ATten-

tion) commands, where the system understands and

allows these commands to be sent over USB. Those

commands allows ﬂashing a compromised boot parti-

tion without the user’s consent thus gaining root ac-

cess, enable ADB, and install a surveillance applica-

tion that is impossible to uninstall without re-ﬂashing

the Android boot partition. In the case of Samsung, a

large list of its family of smartphones has this vulner-

ability, where it is possible to communicate with the

modem through the USB channel, without any previ-

ous conﬁguration in the device, something that does

not happen with ADB. Samsung expands the standard

AT command set that comes with 3GPP and GSM

standards, enhancing the interaction capabilities the

computer software (Kies) has on the device. Kies

for Windows uses the standard set and expanded AT

owner set of commands to get the contacts, the con-

tents of the SD card, and update the ﬁrmware of the

device. Through this process (Pereira et al., 2014),

it is possible to force USB debugging without prior

authorization thus allowing the use of ADB to com-

promise the device.

Attacks based on USB devices constitute another

area of research where the objective is related, but

somehow symmetric to the work here presented: the

objective is to attack a (typically larger) machine us-

ing a USB device, yet they can also be used to attack

a mobile device. The USB Rubber Ducky is a de-

vice that resembles a normal USB ﬂash drive (PEN).

When connected to a computer, it is recognized as a

keyboard, but it quickly introduces its malicious code.

It is a commonly used and very useful tool by pen-

testers. An online video shows how to use the device

to hack an Android phone (Hak5, 2012) .

Another type of attack consists in eavesdropping

the communications between an USB device and a

host. Neugschwandtner et. al describe and imple-

ment one of those attacks — a USB snifﬁng attack —

where a USB device passively eavesdrops on all com-

munications from the host to other devices, without

being situated on the physical path between the host

and the victim device. They also present UScramBle,

a lightweight encryption solution to prevent that kind

of attack (Neugschwandtner et al., 2016).

6 CONCLUSIONS

In this paper, three attack scenarios for USB con-

nection in Android Systems were presented, together

with a script as a proof of concept. The scenarios

use three different devices and Android versions. It

SECRYPT 2017 - 14th International Conference on Security and Cryptography

576

has been demonstrated — for the three speciﬁc sce-

narios — that whenever USB debugging is available,

the device is potentially compromised. In the tested

versions of the OS, the only way to prevent attacks

is to never make USB Debugging available. Once

given this access door, the entire device can be com-

promised in seconds and in a form that is completely

invisible to the victim.

In the speciﬁc model Samsung Galaxy Mini GT-

S5570 with the version 2.2 Froyo there is still a pe-

culiarity: the USB Debugging can be available, but in

”not active” state, which allows a false illusion to the

user to be protected when in fact it is not.

It has also been found that even the presence of

protection software, such as the anti-virus, does not

prevent the installation process of a potentially mali-

cious application, at it only warns that a certain appli-

cation may be harmful.

As future work new attack scenarios will be inves-

tigated, namely for newer versions of Android, over-

coming the need for ADB pairing. It would also be

interesting to have a social experience counting how

many devices are be attacked by hour, day or even

week, in places where it was offered the possibility to

charge the devices’ batteries for free. Different places

in different environments would allow the identiﬁca-

tion of cases where more people are most likely to be

victims.

ACKNOWLEDGEMENTS

This work was partially ﬁnanced by Portuguese

Agency FCT Fundac¸

ao para a Ci

encia e Tecnologia,

in the framework of project UID/EEA/00066/2013.

REFERENCES

Android Open Source project (2017). Android de-

bug bridge. https://developer.android.com/studio/

command-line/adb.html [Online; accessed 07-June-

2017].

arsTechnica (2016). 10 million android phones

infected by all-powerful auto-rooting apps.

https://arstechnica.com/security/2016/07/virulent-

auto-rooting-malware-takes-control-of-10-million-

android-devices/ [Online; accessed 07-June-2017].

BusinessofApps (2015). 80% of android phone

owners in china have rooted their device.

http://www.businessofapps.com/80-android-phone-

owners-china-rooted-device/ [Online; accessed

07-June-2017].

Do, Q., Martini, B., and Choo, K.-K. R. (2015). Exﬁltrating

data from android devices. Comput. Secur., 48(C):74–

91.

Google (2017). android. http://www.android.com [Online;

accessed 07-June-2017].

Hacks, G. (2015). How to enable developer options & usb

debugging. https://android.gadgethacks.com/how-

to/android-basics-enable-developer-options-usb-

debugging-0161948 [Online; accessed 07-June-

2017].

Hak5 (2012). Android hacking with the USB rub-

ber ducky. https://www.hak5.org/episodes/hak5-1216

[Online; accessed 07-June-2017].

Neugschwandtner, M., Beitler, A., and Kurmus, A. (2016).

A transparent defense against USB eavesdropping at-

tacks. In Proceedings of the 9th European Workshop

on System Security, EuroSec ’16, pages 6:1–6:6, New

York, NY, USA. ACM.

Pereira, A., Correia, M., and Brand

ao, P. (2014). USB con-

nection vulnerabilities on android smartphones: De-

fault and vendors’ customizations. In De Decker, B.

and Z

uquete, A., editors, Communications and Multi-

media Security: 15th IFIP TC 6/TC 11 International

Conference, CMS 2014, Aveiro, Portugal, Septem-

ber 25-26, 2014. Proceedings, pages 19–32. Springer

Berlin Heidelberg, Berlin, Heidelberg.

Statista (2017). Number of smartphone users

worldwide from 2014 to 2020 (in billions).

https://www.statista.com/statistics/330695/number-

of-smartphone-users-worldwide/ [Online; accessed

07-June-2017].

TechAdvisor (2016). How to get developer options on

android. http://www.pcadvisor.co.uk/how-to/google-

android/34-useful-things-you-can-do-in-android-

developer-options-new-3590299 [Online; accessed

07-June-2017].

Tischer, M., Durumeric, Z., Foster, S., Duan, S., Mori, A.,

Bursztein, E., and Bailey, M. (2016). Users really do

plug in usb drives they ﬁnd. In 2016 IEEE Symposium

on Security and Privacy (SP), pages 306–319.

Wang, Z., Johnson, R., Murmuria, R., and Stavrou, A.

(2012). Exposing security risks for commercial mo-

bile devices. In Proceedings of the 6th International

Conference on Mathematical Methods, Models and

Architectures for Computer Network Security: Com-

puter Network Security, MMM-ACNS’12, pages 3–

21, Berlin, Heidelberg. Springer-Verlag.

Wang, Z. and Stavrou, A. (2010). Exploiting smart-phone

usb connectivity for fun and proﬁt. In Proceedings of

the 26th Annual Computer Security Applications Con-

ference, ACSAC ’10, pages 357–366, New York, NY,

USA. ACM.

Xu, M. (2014). Security enhancement of secure USB de-

bugging in Android system. Master’s thesis, Univer-

sity of Toledo, USA. in http://utdr.utoledo.edu/theses-

dissertations.

Xu, M., Sun, W., and Alam, M. (2015). Security enhance-

ment of secure USB debugging in android system. In

2015 12th Annual IEEE Consumer Communications

and Networking Conference (CCNC), pages 134–139.

Exploring USB Connection Vulnerabilities on Android Devices - Breaches using the Android Debug Bridge

577