All Your Droid Are Belong To Us: A Survey of Current Android Attacks

Timothy Vidas Daniel Votipka Nicolas Christin

ECE/CyLab INI/CyLab INI/CyLab
Carnegie Mellon University Carnegie Mellon University Carnegie Mellon University

Abstract ilege abuse resulting in unauthorized network access)

now also apply to mobile devices. However, common
In the past few years, mobile devices (smartphones,
security measures deployed on personal computers (e.g.,
PDAs) have seen both their computational power and
rapid patch cycles and anti-virus software) are made
their data connectivity rise to a level nearly equivalent
more difficult by the managed security model, leaving
to that available on small desktop computers, while be-
the user fundamentally unprotected.
coming ubiquitous. On the downside, these mobile de-
vices are now an extremely attractive target for large- Until recently, mobile devices used to present high
scale security attacks. Mobile device middleware is thus operating system heterogeneity, as each device had a
experiencing an increased focus on attempts to mitigate rather unique operating system variant. Such hetero-
potential security compromises. In particular, Android geneity created a difficult management situation for car-
incorporates by design many well-known security fea- riers, but also made the devices more difficult to attack,
tures such as privilege separation. The Android security as a given vulnerability and subsequent exploit would
model also creates several new security sensitive con- apply to a relatively small set of devices. With Android,
cepts such as Android’s application permission system the iPhone and Windows Mobile now making up a sig-
and the unmoderated Android market. In this paper we nificant portion of the 31% of all users that own a smart
look to Android as a specific instance of mobile com- phone [7, 18], the situation has markedly changed to-
puting. We first discuss the Android security model and ward a more homogeneous deployment, which makes
some potential weaknesses of the model. We then pro- for more efficient management, while simultaneously fa-
vide a taxonomy of attacks to the platform demonstrated cilitating large-scale attacks [28].
by real attacks that in the end guarantee privileged access The ubiquity and increasing power of so many mobile
to the device. Where possible, we also propose mitiga- devices poses a number of security challenges that must
tions for the identified vulnerabilities. be addressed. In this survey paper, we focus on Android
security. Specifically, we provide a taxonomy of mobile
1 Introduction platform attack classes with specific, concrete examples
as each class applies to the Android environment. Where
Today’s smartphone has as much processing power and
possible we also provide attack mitigations that can be
memory as a high end laptop computer only a few years
added to the current security model. The rest of this pa-
old. The additional capabilities of a smartphone also in-
per is organized as follows. In Section 2, we provide
troduce a range of issues that are not present in either
relevant background of Android’s security model and in
the security models for portable computers or traditional
Section 3, we analyze new challenges that result from
mobile phones. Modern smartphones are always-on de-
this model. In Section 4, we detail specific attacks ap-
vices which combine phone network connectivity with
plicable to different parts of Android. These attacks ul-
high-speed data networking capabilities and geolocation
timately provide privileged access for a determined ad-
services (e.g., GPS). Further, the vast array of mobile ap-
versary. In Section 5, we provide possible mitigations
plications that extend the feature set of a smartphone en-
for some of the attacks considered. We offer concluding
ables the user to keep considerable amounts of (private)
remarks in Section 6.
information on the device. All of these factors pose a
host of security and management problems.
The current management models employed by the
2 Android Security Model
major smartphone systems make them to a large extent Android was created with certain security design prin-
more similar to corporate-managed devices, rather than ciples, such as privilege separation, in mind [38]. At
personal machines. For instance, phones are by default its core, Android is a Linux-based open-source oper-
not “rooted” (i.e., the user does not have administrative ating system, with a layered structure of services [14]
privileges). This management model introduces secu- including core native libraries and application frame-
rity side-effects that users are unlikely to consider. Se- works. Android natively separates applications and pro-
curity issues that plague typical computing (e.g., priv- vides safety through operating system primitives and en-
vironmental features such as type safety [38]. At the ap- loads [4], needing only an appealing facade to convince
plication level, each software package is sandboxed by users to install the malicious code.
the kernel, making Android a widely deployed system The open nature of the Android market requires
that employs privilege separation as a matter of course. a management model that facilitates reactive malware
This sandboxing is intended to prevent many types of in- management after applications have been installed.
formation disclosure such as one application accessing The malware issue is currently addressed with remote
sensitive information stored on the system or in the pri- [un]install capabilities maintained by Google via the
vate space of another application, performing unautho- Google Talk and Google Services software present on
rized network communication, or accessing other hard- every Android device. Following the identification of
ware features such as the camera or GPS. Applications malicious applications, possibly through Android users
instead request access to system resources via special ap- rating an application negatively, Google may remove ap-
plication level permissions, such as READ SMS, which plications from the market and remotely kill and unin-
must be granted by the user. stall the applications from devices known to have down-
Android’s permission model requires each applica- loaded the application [34]. Interestingly, while Android
tion to explicitly request the right to access protected is largely considered to be open-source, the sources for
resources. The permission model is intended to prevent software such as Google Talk, Google Services, the An-
the unwarranted intrusion by an application on the user’s droid market app (Vendor.apk), and carrier-specific up-
data and the data of other applications, as well as limit date software are not readily available. In this model the
access to features that directly or indirectly cause finan- user only maintains control of applications found in the
cial harm (e.g. a mobile phone plan that charges for each restricted user space, and even this can be over-ridden
SMS message). Before installing an application, the user via remote uninstall.
is presented with a list of all1 the permissions requested
by that application which they must accept before instal-
lation begins. Not only is the permission set so confus-
3 Android Security Model Analysis
ing that it is difficult for users to read and understand, but Even with the inclusion of security as part of the original
it is also a binary decision where the user must accept all design, the new security features create new opportuni-
requested permissions or not install the application [38]. ties for attack, and the growth of the platform provides
The semantics of these application level permissions incentive. In this section we discuss several features of
may be difficult for most users to understand [21, 40], the Android model that may make it vulnerable to attack.
but this understanding is further complicated with im-
plementation details and design choices. For exam- Application model. Unprivileged application attacks
ple, a method of inter-process communication employed can take advantage of the complexity of the Android per-
by Android known as Intents can be broadcast to sev- mission model and the Android market to persuade users
eral software handlers existing in multiple applications. to install malicious software and grant applications the
Each application has the option of registering a handler permissions required to deliver a harmful payload. Ap-
for an Intent, and for some Intents, an associated prior- plications advertised in the Market must be signed by the
ity. When pondering permissions at install time, a user author, but the user has no means of verifying that a sig-
has no way of knowing what priorities are assigned to nature is associated with any particular entity [27]. Even
a given handler or what effects installation will have in users that carefully monitor permission requests may not
conjunction with already installed applications when a fully understand the semantics of a particular permis-
particular event occurs. sion or the framework behavior surrounding a permis-
Applications are made available to users through an sion. Many common users may simply not understand
unmoderated venue, the Android Market. Any entity the security trade-offs that surround permissions like
can create an Android Market account for a modest fee, ACCESS SURFACE FLINGER or BIND APPWIDGET.
and immediately make software available to the pub- Other permissions, such as SEND SMS are more likely
lic. While mobile applications on Android must be to be recognized by users, and yet the framework imple-
signed, they are typically self-signed without employ- mentations may cause undesired behavior. For example,
ing any kind of central authority or any means for a user the receipt of an SMS on a device causes an Android
to validate the authenticity of a certificate. This open ordered-broadcast to be sent system wide. Applications
policy can actually make the market a means for propa- can register the ability to take action when the broad-
gating malware [34]. Attackers can easily publish mali- cast is observed by the application and can assign them-
cious applications to a venue with over 4 billion down- selves a priority over the broadcast. Thus, an applica-
tion that registers a higher priority will receive and have
1 We show later that this list is not necessarily comprehensive the ability to act upon this broadcast before any other
 Not Android Specific Android specific

Vulnerability Component Patch Manufacturer Makes User Applies

Discovered Available Patch Patch
A B C D E F G
Vulnerability Google Releases Carrier Releases
Disclosed Patch Patch

Figure 1: Android patch cycle: Lifecycle of an Android patch from vulnerability identification until a patch reaches
the user device

OS Version

Google Droid X HTC Legend Samsung Captivate

2.2 (Froyo) X X X X X X X
Motorola Droid myTouch 3G Samsung Fascinate
HTC Evo
HTC Hero
Google Samsung Moment Xpreia X10
2.1 (Eclair) X X X X X
Motorola Droid Motorola Cliq
myTouch 3G

1/10 2/10 3/10 4/10 5/10 6/10 7/10 8/10 9/10 10/10 11/10 12/10 1/11 2/11 3/11 4/11 Time

Figure 2: Android version timeline: Google [3] and Manufacturer releases of Android 2.1 [25,29,30,43] and 2.2 [36]

application at a lower priority.2 In regard to SMS, this the permission is not defined for the older API, will still
means that any application with a priority higher than the implicitly have access to the SD Card [10].
standard SMS application will have the ability to process In a stronger form of abuse of application permis-
the incoming SMS message first, including the ability to sions, the attacker may craft malicious applications to
prevent the broadcast from being observed by any other gain privileged (“root”) access to the user’s device. Typ-
application. Malware employing covert communication ically a privilege escalation attack takes advantage of
channels in this manner has already been seen [31, 39]. Android’s slow patch cycle, explored below. When de-
When a user grants permissions based on prompts that ployed as a malicious application, the attack uses the un-
show a RECEIVE SMS permission, such behavior is moderated market’s weaknesses as a vector to propagate
likely unexpected. the malware to the user’s device.
Similarly, the only means a user has of understand- Patch cycles. In an effort to increase adoption of the
ing the capabilities of an application is through the list Android OS, Google created the Open Handset Al-
of permissions presented at install time. In addition to liance to build cooperation between hardware manufac-
the framework implementation issue mentioned above, turers to facilitate implementation on their devices [9].
additional ambiguity is introduced via new permissions Through this cooperation, Google provides the base
that existing in later versions of the SDK. For example open source operating system then device manufactur-
the STORAGE permission group relates to accessing an ers and telecommunications carriers modify this base to
external SD Card. The STORAGE permission was not differentiate their offerings from other Android devices
available until API version 4, so the behavior of an older and provide added value to their customers. Figure 1
application on a newer device is ambiguous. Current shows the patch cycle from a vulnerability’s initial dis-
devices simply do not display a comprehensive list of covery until the patch eventually reaches the user’s An-
permissions to the user. An older application that does droid device. Patch cycle events A through C are typical
not request the STORAGE permission, it should not as of any software product. The software fix represented
by C is typically the end of the vulnerability window
2 Applicationsat the same priority receive the broadcast in an order introduced at A. When considering one of the re-used
undefined by the Android API [2] components in Android, such as WebKit, D-G are ap-
pended to the patch cycle. The additional states added bkit or Linux is discovered, it is generally patched and
to the cycle come from Google’s cooperation with mul- released quickly by the open-source community, how-
tiple manufacturers and carriers. Whenever a patch to ever the corresponding Android patch may not be avail-
Android becomes necessary, Google provides an update able to users for months. The imbalance between the
through their open source forum and manufacturers then Android patch cycle and the software components it is
proceed to port the update to their customized version of built upon leaves a longer attack window for Android
the operating system. devices. Similarly, due to Android’s Linux foundation,
Google’s standard major release cycle is approxi- lower level attacks are simpler when compared to less
mately four months, with minor patches released inter- ubiquitous OSes, as attackers do not need to learn a new
mittently [3]. However, this is not the date on which kernel [20]. For Android to provide a secure platform
these updates are actually available to users. Once it must not only strive for a secure framework, but also
Google releases its patch, the manufacturer must then provide timely updates to minimize the attack window.
update it to work with their custom hardware [23]. These Trusted USB connections. With local USB access a
updates may actually never be made available to the user developer can interact with an ADB (Android Developer
if the carrier deems deployment too costly [44]. Af- Bridge)-enabled device. The ADB is a development tool
ter the manufacturer modifies the patch to work with provided by Android intended to gather debugging in-
their custom device, there can be a delay before the formation from an emulator instance or USB-connected
patch is released by the carriers. An example of a de- phone [1]. The ADB provides further benefit to the user
lay between the manufacturers release of a patch and the by facilitating direct installation and removal of appli-
patch’s eventual release to the public can be seen in [33] cations, bypassing the Android Market, and providing
where AT&T postponed the release of Android 2.2 to the access to an unprivileged interactive remote shell. Us-
Dell Streak creating a three month gap between states E ing the ADB interface, attackers can add and execute
and F in Figure 1. malicious tools that exploit vulnerabilities in the device.
Examples of the disparity between Google’s release Such malware does not need to be present in the An-
of Android updates and their eventual release to specific droid market and will not be tracked for possible remote
devices can be seen in Figure 2. It is not uncommon uninstall by Google. With ADB access an attacker can
to observe at least two months (and sometimes much again take advantage of Android’s slow patch cycle to
more) of delay between an Android update and an ac- gain privileged access to the device. However, this at-
tual deployment of the update by the major manufactur- tack could be carried out via ADB without installing any
ers. As a case in point, 2.1 only became available on application.
certain devices (e.g., Xperia X10) after Google had al-
ready superseded it with Android 2.2. With such a large Recovery mode and boot process. Android devices
vulnerability window and the separate release dates for employ a special recovery boot mode that enables device
Google and each manufacturer, attackers can use reverse maintenance. The recovery mode allows the user to boot
engineering techniques to identify and exploit a vulnera- to a separate partition on the device circumventing the
bility on a device using information available in the orig- standard boot partition [41]. Android’s default recov-
inal released patch or any other manufacturer that adopts ery mode image facilitates maintenance features such as
the patch earlier [22]. Platforms that exhibit slow patch applying a system update to standard system and data
cycles regularly are at even greater risk since the patches areas, cleansing a device of user data ostensibly for re-
made available to comparable systems can be analyzed sale, or software repair to restore life to corrupted (or
in order to determine the vulnerable conditions making “bricked”) devices. Because there is no trusted compo-
the still un-patched devices easy targets. nent to the boot system, attackers can utilize the separate
recovery partition by loading in their own malicious im-
Because of Android’s slow patch cycles, the standard
age to gain privileged access to the user’s information
re-use of common software components that underline
without affecting user data.
the Android framework can cause increased vulnera-
bility. Within the Android framework, common open- Uniform privilege separation. Users can download
source components such as WebKit and the Linux kernel applications marketed for security, however the effec-
are re-used to reduce the cost of system design. Com- tiveness of such applications is extremely limited. On a
ponent re-use is a common practice among large sys- typical computer, security software, such as anti-virus,
tems such as Android. Apple’s iPhone similarly employs may require privileged access in order to secure per-
WebKit [5] and a BSD kernel derivative (Darwin) [13]. mission to scan all files. Security applications on An-
The re-use of common software components itself is not droid are limited to the same restricted environment as
detrimental, but the additional delay introduced by An- every other Android application. Even applications that
droid’s patching model is. Once a vulnerability in We- claim to “block malware, spyware and phishing apps”
(e.g., [8]) require a rooted device in order to obtain the tioned attacks would also be applicable in the case of
necessary permissions to perform these functions. physical access to an unobstructed device.
Likewise, most Android applications that claim fire-
wall capabilities only provide call and SMS filtering. In- 4.1 Unprivileged Attacks
deed, adequate network firewall features require a rooted Much like a user that will install an application inse-
device [38]. Without security tools available, users can- curely downloaded from the Internet despite any oper-
not identify malicious content and the burden falls on the ating system warnings, a user may easily install applica-
device manager. tions that request dozens of Android permissions with-
out a second thought. Applications that are restricted via
4 Attack Classes Android’s typical application sandbox, but that have co-
Perhaps unsurprisingly, full privileged device access is pious access to resources through permissions, can per-
guaranteed given physical access. Perhaps less surpris- form many of the same functions of malware common
ing is the relative ease with which privileged access can on the personal computer platform [26]. For example
be obtained and the amount of nefarious activity that is the Zeus botnet architecture has been ported to most
possible without privileged access. In this section we mobile platforms [15], worms such as Yxe have been
describe unprivileged malicious applications and the cir- seen on SymbianOS [17], and Trojan malware has been
cumstances and methods necessary to gain privileged ac- found in applications present in the legitimate Android
cess to an Android device with respect to the following Market [12, 27]. Users that completely disregard, or are
attacker capabilities. tricked into accepting prompts from the device regard-
No physical access: Attack circumstances where it is ing install time permissions effectively permit negative
impossible to gain physical access to a user’s device. actions completely at the application level.
Then the attacker must get the user to perform actions In some cases, misleading the user may not even be
on the attackers behalf. Such remote attacks commonly required. Some software handlers (Android Receivers)
rely heavily on social engineering [16]. To achieve the may be registered by an application at install time. In-
appropriate initial access to the user’s device an attacker tents expected to occur regularly or those that can be
must get some malicious software running on the device. remotely invoked can be used to achieve remote code
To run code remotely on a user’s device, the attacker typ- execution without requiring user action. Users may in-
ically must convince the user to either download a ma- stall applications from the Android Market web inter-
licious application or access malicious content via one face, which initiates a remote install. Thus, an attacker
of the applications already installed on the device. If the that has somehow obtained a user’s authentication to-
attacker can exploit a vulnerability on the user’s device, ken to the web interface can remotely install applica-
then this access may be used further to gain privileged tions to a user’s device. To achieve remote code ex-
access. ecution the attacker simply has to perform an action
Physical access with ADB enabled: If the attacker finds that results in the device generating an Intent that the
a device left unattended, yet obstructed via a password app for which the application has a receiver. Even se-
or screen lock, the attacker may be able to exploit the curity related features, such as the screen lock may be
device through the Android Developer Bridge. remotely bypassed, by registering a receiver (for exam-
Physical access without ADB enabled: If the attacker ple PACKAGE ADDED) and using the legitimate API for
finds an obstructed Android device left unattended, but KeyguardManager to disable the screen lock upon appli-
is unable to use the ADB service, the attacker may still cation installation [24].
gain privileged access via recovery boot. Application re-packing has proven to be an effective
Physical access on unobstructed device. In some cases means to entice users enough to download malicious ap-
the attacker may actually have access to a device with- plications. Entire families of Trojan software have been
out a password protected screen lock. Such a situation classified in third party black markets as well as the offi-
allows the attacker to actually leverage any other attack cial Android market. Families such as Geinimi [35] and
method since the attacker can choose to install applica- DroidDream [32] have been found in dozens of applica-
tions, visit malicious websites, enable ADB on the de- tions in the Android market. Many of these applications
vice, etc. offer no additional value to the consumer, they are sim-
We next detail specific attacks that demonstrate the ply existing, popular applications that have been reverse
real threats present in the cases enumerated above. Note engineered enough that the attacker can augment the ex-
that we do not include physically destructive attacks isting application with the malware and re-package the
such as opening the casing in order to access debugging application. The attacker then signs the new application
ports (e.g. JTAG). The last case is included for complete- with a new key and makes the application available in
ness, but not specifically detailed since all of the men- the market for victims to download.
 The fact that malware can successfully operate within device with the level of privilege given to the browser.
Android’s restricted application environment signifi- The attacker can then copy a Linux privilege escalation
cantly lightens the attacker’s burden to achieve privi- exploit to an executable mount point on the device, run
leged access through escalation. Applications executing the secondary exploit, and gain privileged access to the
in an isolated environment simply obtain the appropri- whole device.
ate permissions from the user at install time and perform
nefarious activity from within the confines of the appli- 4.3 Physical Access with ADB Enabled
cation sandbox. Even so, attackers may wish to obtain Similar to the previous case, it is possible for an attacker
elevated privileges in order to perform actions for which to obtain privileged access through physical access to
no application level permission exists, or in order to have a device that has ADB enabled [19]. Given physical
guaranteed persistence. access, an attacker can easily determine if ADB is en-
abled, by connecting the device via USB and executing
4.2 Remote Exploitation adb get-serialno on the attached computer. If the
When turning to privileged access, an attacker may rely device’s serial number is returned, then ADB is enabled.
on convincing the user to install a malicious applica- Once the attacker knows that ADB is enabled on the
tion. Such an application may present an enticing fea- device, a privilege escalation only requires the attacker
ture to the consumer but contain software that executes to use ADB’s push feature to place an exploit on the
a privilege escalation attack. Oberheide [34] demon- device, and use ADB’s shell feature to execute the
strated such an attack. Oberheide’s seemingly benign exploit and gain privileged access.
application received more than 200 downloads within Different from most remote attacks, an attack on an
24 hours [34]. In the background this application would ADB enabled device does not require any action from
routinely make remote requests for new payloads to ex- the user. Privilege escalation using ADB does rely heav-
ecute. Whenever a new privilege escalation exploit was ily on the availability of an enabled debug bridge, which
discovered for the current running version of Linux, the is only usually the case on devices used by developers
application could obtain the exploit to gain root access. and not the typical user. However, if the device is not
These exploits must be delivered to the application be- password-protected, the attacker could simply interact
fore the vulnerability is patched, which is generally easy with the common device interface and enable ADB.3
to do considering the long patch cycles discussed above. An example usage of this method for gaining priv-
Similar privilege escalation methodologies can be ileged access is the Super One-Click desktop applica-
found in legitimate device “rooting” applications such tion [42]. Super One-Click requires users to first enable
as Root Tools [11], Easy Root [6], and Unrevoked [45], ADB debugging in the device. Once enabled, the appli-
which take advantage of vulnerabilities in the phone to cation exploits the device using the previously defined
gain privileged access. Users can then use this access method to give the user privileged access.
to circumvent carrier controls over the use of a specific The main advantage of ADB-based attacks is the min-
software or upgrade to a newer version of Android that imal observable footprint left on the device: no new ap-
their carrier has yet to release [41]. plication needs to be installed on the device and a reboot
Deploying malicious applications with a benign fa- is not necessary. The lack of device modification in this
cade through the Android Market takes advantage of method makes it is much harder to trace than other at-
Google’s reactive philosophy toward malicious applica- tacks, and is unlikely to be detected by security applica-
tions. Once on the Android Market, the attacker’s ap- tions on unrooted devices.
plication can now reach a global audience. Because 4.4 Physical Access without ADB Enabled
there is no screening of applications, attackers are given
a pedestal from which to entice the user. On an obstructed device that does not have ADB en-
abled, the attacker may still take advantage of the de-
A remote attack may not even require the installation
vice’s recovery mode [41]. Since the attack does not
of a new application. Android’s use of commodity soft-
rely on a software vulnerability specific particular to a
ware components, such as the web browser and Linux
version of Android, the attack has more longevity than
base can be leveraged for an attack that requires no phys-
other exploits such as the WebKit and Linux exploits
ical access [38]. A concrete example of such an attack
mentioned above. The deployment method is device-
was deployed by Immunity Inc. for the penetration test-
specific leading to extensive fragmentation based on de-
ing tool CANVAS 6.65 [20]. In this attack the user visits
vice model and/or manufacturer.
a malicious website using the device’s built-in browser.
To use the recovery mode, the attacker must first cre-
The attacker then uses this request to take advantage of a
ate a customized recovery image. The main modifica-
vulnerability in the WebKit browser [46] (CSS rule dele-
tion vulnerability) to obtain a remote shell access to the 3 e.g., via Settings - Applications - Development - USB Debugging.
tion necessary for this image is to the init.rc and example, a malicious application remains observable by
default.prop files in the initrd section of the im- the user and may potentially be uninstalled in the future.
age. To give the attacker the necessary privileges, the
init.rc file must list the executables that they wish to 5 Mitigations
add with the rights necessary to be executed. Any exe- We propose six possible mitigations to the attacks seen
cutables necessary for the attack must also be added to in the previous section. Our proposals include reduc-
the initrd section of the image. ing the patch cycle for Android updates, creating a
Once the image is built and the attacker is able to gain trusted class of applications with privileged access, en-
physical access to the device, the attacker must then at- abling authentication on Android Market downloads and
tach the device to a computer through a USB connec- the ADB, leveraging existing host security technologies,
tion and run a manufacturer specific tool (e.g., fastboot and deploying a Trusted Platform Module (TPM) on An-
for HTC, RSDLite for Motorola, Odin for Samsung) to droid enabled devices.
flash the image to the recovery partition of the phone.
After the device has been flashed, the attacker then can 5.1 Reduce the Patch Cycle Length
access the recovery image using a device specific key In all but one of the exploits show in Section 4, attackers
combination (e.g., Power button while holding X for exploit some flaw in the operating system to gain root
Motorola Droid). When the device loads into the recov- privileges. Reducing the patch cycle length would mit-
ery partition the init.rc file is executed. init.rc igate these threats with greater effectiveness. Zero-day
can be modified to run any malicious code added to the exploits would still be possible, however the common
recovery image by the attacker, such as auto-installing lingering threat will be reduced.
a root-kit without attacker interaction. Alternatively, the While Google has already demonstrated willingness
attacker could update the default.prop file to en- to act quickly with out of band patch releases in reaction
able ADB, crafting init.rc to give executable rights to certain attacks (e.g., [34]), reducing complete patch
to an su executable (added previously to the custom re- cycles is a more difficult problem. Indeed, manufac-
covery image initrd). When the recovery image loads turers make changes to the Android source to create a
the attacker opens an interactive shell on the device us- competitive advantage. To reduce patch cycles, manu-
ing ADB. The attacker can now simply execute the su facturer modifications should not fundamentally change
executable to gain root access. the core components of Android, and thus should not re-
Installing a malicious recovery image takes advantage quire a lengthy time to port the patch. A fundamental
of the absence of any trusted boot system on Android separation between the core of Android and manufac-
systems, so that it is possible to make changes to the turer modifications should be established.
devices boot image and gain privileged access without
the need to provide any authentication to the device. 5.2 Privileged Applications
If an attacker is able to create a custom malicious re- To mitigate application attacks that take advantage of
covery image, it is feasible for this attacker to gain priv- Android’s permission model many solutions have been
ileged access on any device for which physical access proposed.
can be obtained. Installing a new recovery image and re- Barrera et al. suggest a restructuring of Android per-
booting the device is not a perfect vector as it can leave missions into a hierarchy to allow for finer grained
an extensive footprint sans subsequent attacker cleanup. permissions that can be simpler for users to under-
However, the recovery image replacement has negligi- stand [21]. Under a hierarchy, an application dis-
ble effect on the user’s experience. While an attacker playing advertisements that would traditionally re-
would almost certainly have a malicious payload, this quire INTERNET permission would need to have
technique is similar to methods described in [41]. INTERNET.ADVERTISING.adsite.com permis-
sion, which would limit its connection to a specific site
4.5 Physical access to unobstructed device and let the user know exactly what the permission is used
for.
If the device user has elected to not employ any kind In [27] Enck et al. propose lightweight application
of obstruction, whether or not ADB is enabled on the certification comparing the requested permissions of an
device is irrelevant, as any of the techniques described application to a set of security rules. If the application
above are possible if physical access to the device is does not pass any of the security rules, then possible ma-
available. The attacker need only turn the device on, licious activity is brought to the attention of the user.
download their malicious code, enable ADB on the de- Adding a certification mechanism to the Android frame-
vice, etc. The method of attack that the attacker chooses work would require modification of the Android security
now depends upon other metrics, such as overtness. For framework.
 Android’s application model could also be adjusted
to allow certain applications to obtain additional, priv- No Physical Access Physical Access
ileged device access. For example, Google could vali- No Privileged
date that certain software vendors create security soft- Access Needed Not Obstructed
ware and grant applications created by these vendors Privileged Access Needed Obstructed
additional API functionality. Applications signed by
No Privileged ADB Enabled
such a vendor could, for example, have read access to Access Needed
the filesystem in order to facilitate anti-virus scanning Application−Only Physical−ADB ADB Not
Enabled
beyond limited scope typically granted to applications. Application−Escalation
Such a configuration would allow users to install secu- Physical−Recovery
Privileged Access Needed
rity related applications without having to first root their
device. Because privileged applications will have unre-
stricted access to the device, these applications should Figure 3: Attack chart: Android attack goals and re-
be certified by some governing entity before they can be quirements.
downloaded. This certification process could also help
mitigate some weaknesses of an unmoderated market. device and once the connection is made, the session
With access to trusted security tools, users would be able could be maintained by preventing the screen from lock-
to monitor untrusted applications and provide appropri- ing while it is connected via USB. With ADB authenti-
ate feedback. With a market model split into trusted and cation, the attacker no longer has a backdoor to bypass
untrusted applications, Google could provide enhanced the lock mechanism’s authentication process, mitigating
security with minimal administrative overhead and min- the ADB attack against obstructed devices.
imal reduction in the openness of the platform.
5.6 Trusted Platform Module
5.3 Leveraging Existing Security Tech- To secure a device in a managed model scenario a root
nologies of trust must be established. Using a Trusted Platform
There are several existing operating system security en- Module (TPM) provides a ground truth on which device
hancements that could be ported to Android. In [37], security could be built, providing authentication of de-
Shabtai et al. experiment with adding SELinux to An- vice state. Using a TPM would mitigate the recovery
droid. An information-flow tracking system, Taint- image attack, which relies on the ability to change the
Droid, has been created by Enck et al. instrumenting An- boot image. Assuming signed bytecode and authenti-
droid [26] to monitor applications and understand how cation of the boot image, updates running unauthorized
they interact with the user’s sensitive information. A re- code would become extremely difficult.
alized implementation of TaintDroid could gives users
real-time information about how an application uses the
6 Conclusion
permissions it is granted. Generally, operating system Android was designed with a focus on security, however,
level software modifications such as adding a firewall or as new security features are added, new vulnerabilities
SELinux to Android involve porting existing technology become available for exploitation. This paper builds a
to the Android kernel and creating an application to fa- taxonomy of attacks on the Android OS. Figure 3 shows
cilitation administration. how an attacker could rely on this taxonomy to decide
which attack path to pursue, given their own capabilities
5.4 Authenticated Downloads (e.g., physical access available or not, ADB available or
Once an attacker has physical access to a device, adding not, etc).
malicious applications becomes simple and quick by We hope the present paper can further the discussion
posing as the legitimate user and downloading them on the security properties modern mobile operating sys-
from the Android Market. To ensure downloads are tems such as Android should possess. Mobile security is
made only by the user, the market should require authen- becoming a pressing challenge indeed.
tication before every transaction, similar to the model
currently used by the iPhone. Acknowledgments
This work is supported in part by CyLab at Carnegie
5.5 Authenticated ADB Mellon under grant DAAD19-02-1-0389 from the Army
Because of the power given through the ADB, it should Research Office, and by the National Science Founda-
not be accessible to unauthorized users. Android should tion under ITR award CCF-0424422 and IGERT award
require the device to be unlocked before ADB can be DGE-0903659, as well as a hardware donation by
used. Any legitimate user should be able to unlock the Google Inc.
References [18] Android most popular operating system in
[1] Android debug bridge.
http://developer. U.S. among recent smartphone buyers |
android.com/guide/developing/tools/ nielsen wire. http://blog.nielsen.com/
adb.html. nielsenwire/online\_mobile/android-
most-popular-operating-system-in-u-
[2] Android developers. http://developer. s-among-recent-smartphone-buyers/, Oct.
android.com/. 2010.
[3] Android developers sdk. http://developer. [19] Rooting the droid without rsdlite.
http:
android.com/sdk/android-1.1.html. //androidforums.com/droid-all-things-
[4] Android market statistics. http://www. root/171056-rooting-droid-without-
androlib.com/appstats.aspx. rsd-lite-up-including-frg83d.html,
Dec. 2010.
[5] Applications using webkit - webkit.
http:
//trac.webkit.org/wiki/Applications\ [20] Canvas: Owning android. http://partners.
%20using\%20WebKit. immunityinc.com/movies/Lightning\
_Demo\_Android.zip, Jan. 2011.
[6] Easy root. http://www.unstableapps.com/
buyme.html. [21] D. Barrera, H. Kayacik, P. van Oorschot, and
A. Somayaji. A methodology for empirical analy-
[7] Factsheet: The U.S. media universe | nielsen wire. sis of permission-based security models and its ap-
http://blog.nielsen.com/nielsenwire/ plication to android. In Proceedings of the 17th
online_mobile/factsheet-the-u-s- ACM conference on Computer and communica-
media-universe/. tions security, pages 73–84. ACM, 2010.
[8] Lookout mobile security - android market. [22] D. Brumley, P. Poosankam, D. Song, and J. Zheng.
https://market.android.com/details? Automatic patch-based exploit generation is possi-
id=com.lookout. ble: Techniques and implications. In IEEE Symp.
[9] Open handset alliance. http://www. S.& P. 2008, pages 143–157, May 2008.
openhandsetalliance.com/. [23] J. V. Camp. Only 36.2 percent of android devices
[10] Permission list is incorrect for apks built with an- run froyo. http://www.digitaltrends.com/
droid 1.6 sdk. https://code.google.com/p/ mobile/only-36-2-percent-of-android-
android/issues/detail?id=4101. devices-run-froyo/, Nov. 2010.

[11] Root tools.

https://market.android.com/ [24] T. Cannon. Android lock screen bypass.
details?id=com.jrummy.roottools. http://thomascannon.net/blog/2011/
02/android-lock-screen-bypass.
[12] Trojanized apps root android devices.
http:
//blog.trendmicro.com/trojanized- [25] C. Davies. Sprint htc hero android 2.1 update
apps-root-android-devices/. released. http://www.slashgear.com/
sprint-htc-hero-android-2-1-update-
[13] Unix system family tree: Research and bsd. released-1986138/, May 2010.
http://www.freebsd.org/cgi/cvsweb.
cgi/˜checkout˜/src/share/misc/bsd-
[26] W. Enck, P. Gilbert, B. Chun, L. Cox, J. Jung,
family-tree?rev=HEAD.
P. McDaniel, and A. Sheth. TaintDroid: an
information-flow tracking system for realtime pri-
[14] What is android. http://developer. vacy monitoring on smartphones. In Proceedings
android.com/guide/basics/what-is- of OSDI, 2010.
android.html.
[27] W. Enck, M. Ongtang, and P. Mcdaniel. On
[15] Zeus targets mobile users.
http://blog. lightweight mobile phone application certification.
trendmicro.com/zeus-targets-mobile- In ACM Conference on Computer and Communi-
users/. cations Security, pages 235–245. ACM, 2009.
[16] Just because it’s signed doesn’t mean it isn’t spying [28] D. Geer, R. Bace, P. Gutmann, P. Metzger,
on you. http://www.f-secure.com/weblog/ C. Pfleeger, J. Quarterman, and B. Schneier. Cy-
archives/00001190.html, May 2007. berinsecurity: The cost of monopoly. Computer
[17] Worm:symbos/yxe. http://www.f-secure. and Communications Industry Association, 2003.
com/v-descs/worm_symbos_yxe.shtml, May [29] E. Hardy. Andoird OS 2.1 upgrade for T-Mobile
2007. myTouch 3G, Motorola Cliq, Cliq XT coming
 in August. http://www.brighthand.com/ [41] T. Vidas, C. Zhang, and N. Christin. Towards
default.asp?newsID=16767, July 2010. a general collection methodology for android de-
[30] J. Herrman. Android 2.1 update finally live for vices. DFRWS 2011, Aug. 2011.
Motorola Droid. http://gizmodo.com/\# [42] A. Waqas. Root any android device and
!5505520/android-21-update-finally- samsung captivate with super one-click app.
live-for-motorola-droid, Mar. 2010. http://www.addictivetips.com/mobile/
root-any-android-device-and-samsung-
[31] K. J. Higgins. Researcher to release
captivate-with-super-one-click-app/,
smartphone botnet proof-of-concept code.
Oct. 2010.
http://mobile.darkreading.com/9287/
show/54cc009853e3f863244c0b267a73ae86, [43] T. Wimberly. Sprint releases android 2.1 for sam-
Jan. 2011. sung moment. http://androidandme.com/
2010/05/news/sprint-releases-android-
[32] K. Mahaffey. http://blog.mylookout.
2-1-for-samsung-moment/, May 2010.
com/2011/03/security-alert-malware-
found-in-official-android-market- [44] T. Wimberly. Top 10 android phones, best
droiddream/, Mar. 2011. selling get software updates first. http:
//androidandme.com/2010/11/news/top-
[33] L. Menchaca. AT&T sim-locked units and 10-android-phones-best-selling-get-
the Froyo update - direct2dell. http:
software-updates-first/, Nov. 2010.
//en.community.dell.com/dell-blogs/
Direct2Dell/b/direct2dell/archive/ [45] J. Wise. Unrevoked3 recovery reflash tool.
2010/12/09/at-amp-t-sim-locked- http://unrevoked.com/rootwiki/doku.
units-and-the-froyo-update.aspx, Dec. php/public/unrevoked3, Jan. 2011.
2010. [46] B. Woods. Researchers expose android webkit
[34] J. Oberheide. Remote kill and install on google browser exploit. http://www.zdnet.co.
android. http://jon.oberheide.org/blog/ uk/news/security-threats/2010/11/08/
2010/06/25/remote-kill-and-install- researchers-expose-android-webkit-
on-google-android/. browser-exploit-40090787/, Nov. 2010.

[35] B. Prince. Google android trojan, fbi raid linked

to operation payback lead security news. http:
//www.eweek.com/c/a/Security/Google-
Android-Trojan-FBI-Raid-Linked-to-
Operation-Payback-Lead-News-406931/,
Jan. 2011.
[36] J. Raphael. Android 2.2 upgrade list: Is
your phone getting Froyo? - Computerworld
Blogs. http://blogs.computerworld.com/
16310/android\_22\_upgrade\_list, June
2010.
[37] A. Shabtai, Y. Fledel, and Y. Elovici. Securing
Android-powered mobile devices using SELinux.
Security & Privacy, IEEE, 8(3):36–44, 2010.
[38] A. Shabtai, Y. Fledel, U. Kanonov, Y. Elovici,
S. Dolev, and C. Glezer. Google android: A com-
prehensive security assessment. Security Privacy,
IEEE, 8(2):35 –44, march-april 2010.
[39] T. Vennon. Android malware. A study of known
and potential malware threats. Technical report,
Technical Report White paper, SMobile Global
Threat Center, Feb. 2010.
[40] T. Vidas, N. Christin, and L. Cranor. Curbing an-
droid permission creep. W2SP 2011, May 2011.