U.S. patent application number 14/456719 was filed with the patent office on 2016-02-11 for detection of pileup vulnerabilities in mobile operating systems.
The applicant listed for this patent is Indiana University Research and Technology Corporation. Invention is credited to XiaoFeng WANG, Luyi XING.
Application Number | 20160044049 14/456719 |
Document ID | / |
Family ID | 55268319 |
Filed Date | 2016-02-11 |
United States Patent
Application |
20160044049 |
Kind Code |
A1 |
XING; Luyi ; et al. |
February 11, 2016 |
DETECTION OF PILEUP VULNERABILITIES IN MOBILE OPERATING SYSTEMS
Abstract
A system is provided for detecting pileup vulnerabilities
corresponding to mobile operating system updates. The system
includes: an exploit opportunity analyzer, configured to identify
pileup exploit opportunities corresponding to a plurality of mobile
operating system configurations based on mobile operating system
upgrades for each of the plurality of mobile operating system
configurations, wherein the identification of exploit opportunities
is based on information relating to pileup flaws; a risk database,
configured to store information regarding the identified pileup
exploit opportunities for a plurality of versions of each of the
plurality of mobile operating system configurations; and a scanner
application, configured to be executed by a mobile device,
configured to query identified exploit opportunities relating to a
particular mobile operating system configuration and version, and
to evaluate third-party applications installed at the mobile device
based on the identified exploit opportunities.
Inventors: |
XING; Luyi; (Bloomington,
IN) ; WANG; XiaoFeng; (Bloomington, IN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Indiana University Research and Technology Corporation |
Indianapolis |
IN |
US |
|
|
Family ID: |
55268319 |
Appl. No.: |
14/456719 |
Filed: |
August 11, 2014 |
Current U.S.
Class: |
726/23 |
Current CPC
Class: |
H04L 63/1433 20130101;
H04W 12/1208 20190101; G06F 21/56 20130101; H04L 63/14
20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06 |
Goverment Interests
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH AND
DEVELOPMENT
[0001] This invention was made with Government support under Grant
Numbers CNS1117106 and CNS1223495 awarded by the National Science
Foundation. The Government has certain rights in this invention.
Claims
1. A system for detecting pileup vulnerabilities corresponding to
mobile operating system updates, the system comprising: an exploit
opportunity analyzer, configured to identify pileup exploit
opportunities corresponding to a plurality of mobile operating
system configurations based on mobile operating system upgrades for
each of the plurality of mobile operating system configurations,
wherein the identification of exploit opportunities is based on
information relating to pileup flaws; a risk database, configured
to store information regarding the identified pileup exploit
opportunities for a plurality of versions of each of the plurality
of mobile operating system configurations; and a scanner
application, configured to be executed by a mobile device,
configured to query identified exploit opportunities relating to a
particular mobile operating system configuration and version, and
to evaluate third-party applications installed at the mobile device
based on the identified exploit opportunities.
2. The system according to claim 1, wherein the pileup flaws
include permission harvesting flaws corresponding to a malicious
app being able to gain a permission to be defined in a mobile
operating system update without receiving proper authorization for
gaining the permission.
3. The system according to claim 1, wherein the pileup flaws
include permission preempting flaws corresponding to a malicious
app being able to preemptively define a new permission that
corresponds to a permission to be defined in a mobile operating
system update.
4. The system according to claim 1, wherein the pileup flaws
include shared user ID (UID) grabbing flaws corresponding to a
malicious app being able to declare a shared UID corresponding to a
shared UID of an application to be added by a mobile operating
system update so as to block installation of the application to be
added.
5. The system according to claim 1, wherein the pileup flaws
include data contamination flaws corresponding to a malicious app
being able to contaminate data for an application to be added by a
mobile operating system update via the mobile operating system
update process.
6. The system according to claim 1, wherein the pileup flaws
include denial of services flaws corresponding to a malicious app
being able to define a permission tree so as to deny access to
resources associated with a permission to be defined by a mobile
operating system update that falls within the permission tree
defined by the malicious app.
7. The system according to claim 1, further comprising: a
vulnerability detector, configured to analyze mobile operating
system update logic used by particular mobile operating system
configurations to identify pileup flaws associated with each
particular mobile operating system configuration; and wherein the
risk database is further configured to store the information
relating to the pileup flaws and the exploit opportunity analyzer
is further configured to obtain the stored information relating to
the pileup flaws from the risk database.
8. The system according to claim 1, wherein the exploit opportunity
analyzer is further configured to receive mobile operating system
images corresponding to different versions for a mobile operating
system configuration and analyze pileup exploit opportunities based
on the pileup flaws and based on differences between the difference
versions of the mobile operating system configuration.
9. The system according to claim 8, wherein the risk database is
further configured to store information relating to the pileup
flaws and the exploit opportunity analyzer is further configured to
obtain the stored information relating to the pileup flaws for the
mobile operating system configuration from the risk database, and
wherein the analysis of pileup exploit opportunities is further
based on the obtained information relating to the pileup flaws for
the mobile operating system configuration.
10. The system according to claim 1, wherein the scanner
application is further configured to remove a third-party
application based on a result of the scanner application's
evaluation of the third-party application.
11. A method for identifying pileup exploit opportunities
associated with a plurality of mobile operating system
configurations, the method comprising: receiving, by a computing
device, a plurality of mobile operating system images corresponding
to the plurality of mobile operating system configurations and
multiple versions of the plurality of mobile operating system
configurations; identifying, by the computing device, items
susceptible to pileup flaws in each of a plurality of the multiple
versions of the plurality of mobile operating system
configurations; and causing, by the computing device,
identifications of the items susceptible to pileup flaws to be
stored in a risk database as identified exploit opportunities.
12. The method according to claim 11, wherein the pileup flaws
include: permission harvesting flaws corresponding to a malicious
app being able to gain a permission to be defined in a mobile
operating system update without receiving proper authorization for
gaining the permission; permission preempting flaws corresponding
to a malicious app being able to preemptively define a new
permission that corresponds to a permission to be defined in a
mobile operating system update; shared user ID (UID) grabbing flaws
corresponding to a malicious app being able to declare a shared UID
corresponding to a shared UID of an application to be added by a
mobile operating system update so as to block installation of the
application to be added; data contamination flaws corresponding to
a malicious app being able to contaminate data for an application
to be added by a mobile operating system update via the mobile
operating system update process; and denial of services flaws
corresponding to a malicious app being able to define a permission
tree so as to deny access to resources associated with a permission
to be defined by a mobile operating system update that falls within
the permission tree defined by the malicious app.
13. The method according to claim 11, further comprising:
receiving, from the risk database, information relating to pileup
flaws corresponding to each of the plurality of mobile operating
system configuration.
14. The method according to claim 13, wherein identifying items
susceptible to pileup flaws in each of a plurality of the multiple
versions of the plurality of mobile operating system configurations
is based on the received information relating to pileup flaws.
15. A non-transitory processor-readable medium having
processor-executable instructions stored thereon for scanning for
pileup vulnerabilities on a mobile device, the processor-executable
instructions, when executed by a processor of the mobile device in
accordance with a scanning application, facilitating the
performance of the following steps: querying a remote risk database
for pileup exploit opportunities corresponding to a current version
of a mobile operating system installed on the mobile device;
receiving identifications of pileup exploit opportunities
corresponding to the current version of the mobile operating
system; scanning non-system applications installed on the mobile
device to detect potentially malicious applications configured to
take advantage of the pileup exploit opportunities corresponding to
the current version of the mobile operating system; and responding
to detected potentially malicious applications by notifying a user
of the mobile device of the detected potentially malicious
applications or by removing the potentially malicious applications
from the mobile device.
16. The non-transitory processor-readable medium according to claim
15, wherein the identifications of pileup exploit opportunities
include pileup exploit opportunities associated with permission
harvesting flaws corresponding to a malicious app being able to
gain a permission to be defined in a mobile operating system update
without receiving proper authorization for gaining the
permission.
17. The non-transitory processor-readable medium according to claim
15, wherein the identifications of pileup exploit opportunities
include pileup exploit opportunities associated with permission
preempting flaws corresponding to a malicious app being able to
preemptively define a new permission that corresponds to a
permission to be defined in a mobile operating system update.
18. The non-transitory processor-readable medium according to claim
15, wherein the identifications of pileup exploit opportunities
include pileup exploit opportunities associated with shared user ID
(UID) grabbing flaws corresponding to a malicious app being able to
declare a shared UID corresponding to a shared UID of an
application to be added by a mobile operating system update so as
to block installation of the application to be added.
19. The non-transitory processor-readable medium according to claim
15, wherein the identifications of pileup exploit opportunities
include pileup exploit opportunities associated with data
contamination flaws corresponding to a malicious app being able to
contaminate data for an application to be added by a mobile
operating system update via the mobile operating system update
process.
20. The non-transitory processor-readable medium according to claim
15, wherein the identifications of pileup exploit opportunities
include pileup exploit opportunities associated with denial of
services flaws corresponding to a malicious app being able to
define a permission tree so as to deny access to resources
associated with a permission to be defined by a mobile operating
system update that falls within the permission tree defined by the
malicious app.
Description
BACKGROUND
[0002] Mobile operating systems (OSes) for mobile devices (e.g.,
smartphones) evolve quickly. For at least some mobile OSes, major
updates or new overhauls of entire systems are made available as
often as once every few months, bringing brand new mobile device
applications (apps) and enriched functionalities with each update.
Conventional wisdom is that such a vibrant ecosystem benefits the
mobile device users, providing enhanced security by plugging
loopholes in a timely manner, as well as providing enhanced
functionality.
[0003] Indeed, for years, major smartphone vendors and
system/software developers have leveraged convenient updating
mechanisms on mobile devices to push out fixes and enhance existing
protection. Such updates are becoming increasingly frequent (e.g.,
with respect to the Android mobile OS, the first 19 major updates
occurred on average about once every 3.4 months) and increasingly
complicated (e.g., hundreds of apps being added or replaced each
time by hundreds of different Android device vendors).
SUMMARY
[0004] Embodiments of the invention relate to detection of
vulnerabilities associated with the updating process for mobile
OSes. Due to the frequency of mobile OS updates, fragmentation of
mobile OSes (i.e., existence of many different versions of the
mobile OS co-existing at the same time, including multiple
iterations of a particular mobile OS, and further including
vendor-customized versions of a mobile OS), as well as the
complicated nature of mobile OS updates often involving replacement
and/or addition of tens of thousands of files on a live system, the
mobile OS updating process presents an opportunity for malicious
software (malware) to exploit security loopholes.
[0005] Specifically, embodiments of the invention focus on
detection of security-critical vulnerabilities associated with a
mobile OS update, referred to herein as "pileup" (privilege
escalation through updating) flaws, through which a malicious app
can potentially escalate its privileges, acquire system and
signature permissions, determine settings (e.g., protection
levels), substitute itself for new system apps, contaminate system
app data (e.g., the cache and cookies of a system's default web
browser), steal sensitive user information, change the user's
security configurations, prevent installation of critical system
services, etc. Pileup attacks are not aimed at the currently
installed mobile OS, but rather utilize vulnerabilities in an
updating mechanism for the mobile OS that allows a malicious app to
perform unauthorized activity on or otherwise affect a future,
updated iteration of the mobile OS.
[0006] In an embodiment, the invention provides a system for
detecting pileup vulnerabilities corresponding to mobile operating
system updates. The system includes: an exploit opportunity
analyzer, configured to identify pileup exploit opportunities
corresponding to a plurality of mobile operating system
configurations based on mobile operating system upgrades for each
of the plurality of mobile operating system configurations, wherein
the identification of exploit opportunities is based on information
relating to pileup flaws; a risk database, configured to store
information regarding the identified pileup exploit opportunities
for a plurality of versions of each of the plurality of mobile
operating system configurations; and a scanner application,
configured to be executed by a mobile device, configured to query
identified exploit opportunities relating to a particular mobile
operating system configuration and version, and to evaluate
third-party applications installed at the mobile device based on
the identified exploit opportunities.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0007] The invention will be described in even greater detail below
based on the exemplary figures. The invention is not limited to the
exemplary embodiments. All features described and/or illustrated
herein can be used alone or combined in different combinations in
embodiments of the invention. The features and advantages of
various embodiments of the present invention will become apparent
by reading the following detailed description with reference to the
attached drawings which illustrate the following:
[0008] FIG. 1 is a simplified block diagram illustrating components
of a mobile device in an exemplary environment;
[0009] FIGS. 2A-2E are flowcharts illustrating exemplary processes
for different pileup attacks;
[0010] FIG. 3 is a block diagram illustrating an exemplary system
architecture;
[0011] FIG. 4 is a flowchart illustrating an exemplary process for
identifying pileup exploit opportunities; and
[0012] FIG. 5 is a flowchart illustrating an exemplary process for
scanning a mobile device for pileup vulnerabilities.
DETAILED DESCRIPTION
[0013] Before getting into the details of embodiments of the
invention, it is helpful to understand various manners in which
pileup attacks are possible as a result of security vulnerabilities
in a mobile OS update process in the context of an exemplary
environment. It will be appreciated that the environment and
embodiments described below are exemplary, and that variations of
such environment and embodiments are also possible without
departing from the principles of the invention.
[0014] FIG. 1, which illustrates an exemplary environment in which
principles of the invention are applicable, depicts a simplified
schematic of a mobile device 100 (e.g., a smartphone), that
includes a processor 101 and a memory 102, with the memory having
installed thereon a mobile OS 110. The processor 101 is configured
to execute processor-executable instructions stored on the memory
associated with the mobile OS so as to facilitate execution of
various system apps 111 (e.g., relating to e-mail, web browsing,
camera, calendar, certain data storage, etc.) and third-party apps
112 (e.g., apps downloaded from third-party vendors and developers
from an app store or other repository). It will be appreciated that
the mobile device may further include many other components (e.g.,
power supply, touchscreen display, speakers, satellite-based
positioning unit, wireless communications transceivers,
communication ports, etc.), but such other components are omitted
from the depiction of FIG. 1 for simplicity.
[0015] In an exemplary embodiment, each app exists within its own
"sandbox" and has its own set of permissions and privileges within
the system, as well as its own location for data storage associated
with the app. An exception to this general rule is that certain
apps may possess a shared user ID (UID), which allows the OS to
assign multiple apps to the same UID and allows the apps to access
each other's data and potentially execute in a same process. Two
apps having a shared UID should be signed by the same party, and
have a declaration in their manifests identifying their shared
UID.
[0016] FIGS. 2A-2E are flowcharts illustrating different ways that
malicious apps may exploit pileup vulnerabilities to perform pileup
attacks on the mobile device depicted in FIG. 1 via an upgrade of
the mobile OS. The discovery by the inventors of the present
invention of these pileup flaws corresponding to mobile OS upgrades
is described with additional details and examples, in the context
of the Android mobile OS, in Luyi Xing et al., "Upgrading Your
Android, Elevating My Malware: Privilege Escalation through Mobile
OS Updating," presented at the 35th IEEE Symposium on Security and
Privacy, San Jose, Calif. (May 2014) (available online at
http://www.ieee-security.org/TC/SP2014/papers/UpgradingYourAndroid,Elevat-
ingMyMalware_c_PrivilegeEscalationThroughMobileOSUpdating.pdf),
which is incorporated by reference herein in its entirety and
referred to herein after as "the Xing Publication."
[0017] FIG. 2A illustrates a process for a "permission harvesting"
attack, and FIG. 2B illustrates a process for a "permission
preempting" attack. As mentioned above, each app has its own set of
permissions and privileges within the system. In an exemplary
embodiment, these permissions and privileges are categorized into
different protection levels. For example, in the Android system,
common protection levels include: normal (automatically granted to
apps when requested by the apps), dangerous (granted to an app only
upon user consent), signature (granted to apps signed with the same
certificate as one that already declares the permission), system
(granted to system apps), and signature or system (a combination of
signature and system protection that is granted to system apps or
apps signed with the same certificate). The "permission harvesting"
attack of FIG. 2A allows a malicious app to gain dangerous-level
permissions without user consent, and the "permission preempting"
attack of FIG. 2B allows a malicious app to tamper with the
definitions of new permissions and, for example, thereby gain any
level of permission (including signature-, system- and/or signature
or system-level permissions).
[0018] In FIG. 2A, the process starts with installation of a
malicious app on a current version of the mobile OS (stage 201).
The malicious app has declared for itself a dangerous-level
permission which has not yet been defined (and thus does not exist)
on the current version of the mobile OS, but will exist on a next
or future version of the mobile OS (by being newly defined during a
system update). Because this permission does not yet exist on the
current mobile OS, during installation of the malicious app on the
current mobile OS, the installation process ignores the declaration
of the dangerous-level permission, which is not recognized by the
current mobile OS. Subsequently, e.g., during the update of the
current mobile OS to the next version of the mobile OS (stage 203),
the update results in defining the new dangerous-level permission
for the next mobile OS. When apps are migrated to the next mobile
OS during the update process, which includes silently re-granting
dangerous-level permissions to which the apps have previously
received authorization, the update mechanism assumes that the
malicious app is authorized with respect to that newly defined
dangerous-level permission based on its declaration that it has
that dangerous-level permission. The update mechanism thus grants
the malicious app the newly defined dangerous-level permission even
though the user has never authorized the malicious app to have that
permission. Thus, with respect to the updated mobile OS, the
malicious app now possesses the dangerous-level permission without
proper authorization (stage 205).
[0019] Using the "permission harvesting" form of pileup attack, a
malicious app is able to gain dangerous-level permissions that are
newly defined during a mobile OS update. However, in this exemplary
environment, the malicious app cannot gain signature-, system-
and/or signature or system-level permissions through "permission
harvesting," as signature- and system-level permissions declared by
system apps cannot be granted to third-party apps due to the
system's rules.
[0020] The "permission preempting" attack depicted in FIG. 2B
allows a malicious app to gain any permission that is newly defined
during a mobile OS update, regardless of the protection level
associated therewith (the malicious app can even get permissions
that are to be defined as system-level or signature-level
permissions). The process starts with installation of a malicious
app on a current version of the mobile OS (at stage 211), where
instead of simply declaring that it has a particular permission,
the malicious app preemptively defines a permission for the current
mobile OS using the same name/identification for the permission as
a future permission to be newly defined in a next version of the
mobile OS. During the update of the current mobile OS to the next
version of the mobile OS (stage 213), the update mechanism
identifies existing permissions on the current mobile OS and places
them into a permissions list (including the permission defined by
the malicious app). When the update mechanism gets to the point in
the process where it should be adding the newly defined permission
in the system update package to the permissions list, it instead
determines that this intended newly defined permission has in fact
already been defined, and as a result skips over the step of adding
the proper definition for the new permission from the system update
package. Thus, on the next version of the mobile OS, the permission
that should have been newly defined is instead defined by the
malicious app (stage 215), which could have defined that permission
as having a normal-level of protection when it should have been at
a higher level of protection according to the system update
package. Alternatively, the malicious app could define a permission
that should have been normal-level at a higher level, such that
other apps that should have had the permission are now denied that
permission.
[0021] This "permission preempting" attack allows a malicious app
to gain access to resources that should have been protected with a
dangerous-, system-, signature- or system or signature-level
rating, or alternatively to deny access to resources by specifying
a relatively higher level of protection. Moreover, because the
permission is defined by the malicious app, deleting the malicious
app from the mobile OS will also cause the permission definition to
be deleted from the mobile OS, such that the permission becomes
unavailable across the whole system and no apps are able to gain
access to the resources associated with that permission.
[0022] FIG. 2C illustrates a process for a "shared UID grabbing"
attack. As mentioned above, certain apps may have shared UIDs,
which allows the apps to access each other's data and potentially
execute in a same process. The "shared UID grabbing" attack starts
with a malicious app being installed, with the malicious app having
a shared UID entry that matches a shared UID entry of a future app
that is yet to be installed (e.g., a system app utilizing the
shared UID that is to be installed during a future or next mobile
OS update) (stage 221). During the update of the mobile OS, when
the updating mechanism encounters two application packages with the
same shared UID, the updating mechanism checks to verify that the
app signatures are signed by the same party (stage 223). In the
case of the malicious app sharing the same shared UID as a
to-be-installed system app, this results in the malicious app
blocking the installation of the to-be-installed system app (stage
225) since the malicious app and the to-be-installed system app are
not signed by the same party.
[0023] In an exemplary environment, the "shared UID grabbing"
attack may further allow the existing malicious app the opportunity
to replace the to-be-installed system app with a malicious app.
During the mobile OS update process, the updating mechanism
replaces all application package files under the system directory
with new corresponding application packages. However, during
transition of a previously installed system app (not having a
shared UID) to an updated system app (having a shared UID) where an
existing malicious app grabs the shared UID, the previously
installed system app is deleted and installation of the updated
system app is blocked. This presents the opportunity for the
existing malicious app to download a malicious replacement app to
pose as the new system app that should have been installed.
[0024] FIG. 2D illustrates a process for a "data contamination"
attack. The "data contamination" attack allows a malicious
application to contaminate the data that is to be used by a future
app. The process begins with installation of a malicious app, where
the malicious app utilizes an application package name that is the
same as a future app to be installed (stage 231). Because there are
legitimate instances where preexisting non-system applications bear
the same name as new system applications to be installed as part of
an update (e.g., in the case of a non-system app developed by the
system provider being released first through an app store and later
incorporated into the system itself), the mobile OS update process
seeks to preserve data from preexisting apps bearing the same
application package name even where there is a new app with that
same name being installed as part of a mobile OS update (stage
233). Thus, when a malicious app adopts the same name as a future
app to be installed, the preexisting data provided by the malicious
app is incorporated as data to be used by the future app (stage
235), thereby contaminating the data of the future app.
[0025] For "data contamination" attacks, the malicious app no
longer exists on the system after the update of the mobile OS is
completed. However, the data associated with the legitimate app
that replaced the malicious app has been contaminated by the
malicious app. In certain exemplary environments, it should be
noted that this "data contamination" attack may not work with
respect to apps having shared UIDs (since the installation process
for new apps having shared UIDs may be different from the
installation process for new apps that do not have shared
UIDs).
[0026] FIG. 2E illustrates a process for a "denial of services"
attack based on the use of permission trees. The attack begins with
installation of a malicious app that defines a permission tree,
which is a base name (root) for a tree of permissions, where the
tree of permissions contains permissions that are to-be-defined in
a future mobile OS update (stage 241). For example, the malicious
app could define a new base/root of "com.example", which
corresponds to a tree containing permissions such as
"com.example.math1", "com.example.math1.add", "com.example.math2",
etc. During the update of the mobile OS, new apps to be installed
attempt to define new permissions that are part of the tree defined
by the malicious app (stage 243). However, because the entire tree
has previously been defined by the malicious app, these definitions
of new permissions that are part of the tree are rejected due to
those new permissions being declared by new apps which are part of
a different application package from the application package that
had declared the tree. This results in denial of access to the
resources guarded by the permissions that should have been defined
but were blocked by the malicious app's definition of the
permission tree (stage 245).
[0027] This "denial of services" attack may work even if there are
preexisting apps that already define permissions and/or permission
trees that are subsets of the permission tree defined by the
malicious app. For example, using the example above, even if an
existing system app had defined the permission tree
"com.example.math1", the malicious app can subsequently define the
permission tree "com.example" to perform the denial of services
attack with respect to all new apps registering permissions that
are part of the "com.example" tree, even those that are part of the
preexisting "com.example.math1" sub-tree.
[0028] In an exemplary Android-based environment, the updating
mechanism performing the update-related tasks discussed above with
respect to FIGS. 2A-2E is a Package Manager Service (PMS) for
installing, upgrading, configuring, and removing application
packages. However, it will be appreciated that other parts of the
Android system, such as the Activity Manager, Service Manager, User
Manager Service, Input Manager, etc., may be involved in these
update processes as well. Further, it will be appreciated that
other exemplary embodiments of the invention may be implemented in
the context of updates to mobile OS environments other than Android
as well.
[0029] Each of the potential pileup attacks discussed above with
respect to FIGS. 2A-2E corresponds to logical flaws in mobile OS
update processes (referred to herein as "pileup flaws"). Because
there are several different types of mobile OSes (e.g., Android,
iOS, Windows, etc.), and potentially thousands of mobile OS
manufacturer-specific and/or device-specific configurations (e.g.,
even considering just Android systems, each smartphone manufacturer
has customized configurations of the Android mobile OS, often with
further specific customizations on a device-by-device basis),
certain pileup attacks identified above may be applicable to
certain mobile OS configurations (or versions of those
configurations) while not being applicable to certain other mobile
OS configurations (or versions of those configurations). Thus, in
certain exemplary embodiments of the invention, a first aspect of
the system is to identify which pileup flaws correspond to which
mobile OS configurations and to which versions of those
configurations. Alternatively, in other exemplary embodiments of
the invention, it may simply be assumed that every kind of pileup
flaw is present in every mobile OS configuration and version.
[0030] In accordance with embodiments of the invention, based on
the pileup flaws corresponding to each mobile OS configuration,
pileup exploit opportunities can be identified on the basis of
those pileup flaws corresponding to each version of each mobile OS
configuration. For example, for a particular mobile OS
configuration (e.g., a particular device-specific mobile OS having
multiple versions), each successive mobile OS update may be
analyzed to determine which items in each mobile OS update are
susceptible to pileup attacks. In a particular example, given that
the mobile OS starts with version 1, newly defines a permission x
when updated to version 2, and then newly defines a permission y
when updated to version 3, it can be seen, for example, that
version 1 of the OS is vulnerable to a permission harvesting attack
with respect to permissions x and y, and that version 2 of the OS
is vulnerable to a permission harvesting attack with respect to
permission y.
[0031] A comprehensive record of identified pileup exploit
opportunities corresponding to each mobile OS configuration and
version thereof is stored at a risk database, which is accessible
over a wireless connection to a scanner application stored at a
mobile device. According to embodiments of the invention, the
scanner application is configured to determine the version and
configuration of the mobile OS installed at the mobile device, and
to query the risk database for identified exploit opportunities
corresponding to the version and configuration of the mobile OS
installed at the mobile device. The scanner application then uses
this information to scan third-party (i.e., non-system) apps
installed on the mobile device to detect whether any of the
third-party apps contains items corresponding to susceptible items
that were identified as exploit opportunities (e.g., third-party
apps that include permission declarations, permission definitions,
permission tree definitions, shared UID entries, and/or package
names that conflict with permission declarations, permission
definitions, permission tree definitions, shared UID entries,
and/or package names corresponding to a future mobile OS update).
Upon completion of the scan, the scanner app reports the results to
the user of the mobile device and/or takes further appropriate
action (e.g., removing apps identified as being malicious
apps).
[0032] FIG. 3 is a block diagram illustrating an exemplary system
architecture in an exemplary embodiment of the invention. The
architecture includes a pileup opportunity detection system 301,
which may, for example, be server-based and include a risk database
311, and further include one or more computing devices
corresponding to a vulnerability detector 310 and an exploit
opportunity analyzer 312. The architecture further includes
external source(s) 303 from which the exploit opportunity analyzer
312 obtains various mobile OS images 330 corresponding to different
mobile OS configurations and versions thereof (which the exploit
opportunity analyzer 312 uses in combination with information
regarding pileup flaws 320 stored at the risk database 311 to
identify exploit opportunities). The architecture also further
includes a mobile device 302 that has a pileup scanner app 340
installed.
[0033] The information regarding pileup flaws 320 corresponding to
each mobile OS configuration allows the exploit opportunity
analyzer 312 to determine what items to look for in each mobile OS
update corresponding to that mobile OS configuration. For example,
with respect to permission harvesting, permission preempting, and
denial of service attacks, the exploit opportunity analyzer 312
identifies the names of new permissions introduced by mobile OS
updates (and the point at which each new permission is introduced).
With respect to shared UID and data contamination attacks, the
exploit opportunity analyzer 312 identifies the names of new
application packages and shared UID entries corresponding thereto
(if applicable) introduced by mobile OS updates (and the point at
which each new application package is updated). In this manner, the
exploit opportunity analyzer 312 is able to comprehensively
identify where exploit opportunities for each mobile OS
configuration may be found. Using this pileup flaw information 320
in combination with particular mobile OS images 330 retrieved from
external source(s) 303, the exploit opportunity analyzer 312 is
able to identify, for example, new permissions (and the base/roots
thereof), shared UIDs, and application package names introduced in
each successive version of each
manufacturer-specific/device-specific mobile OS configuration (for
example, by comparing the mobile OS images 330 to one another to
identify differences, or by identifying new items defined within
mobile OS update packages). Identifications of the particular items
that are identified as being susceptible to pileup attacks are
stored as identified exploit opportunities 321 in the risk database
311.
[0034] FIG. 4 is a flowchart illustrating this process for
identifying exploit opportunities for a particular mobile OS
configuration, as discussed above with reference to FIG. 3. At
stages 401 and 402, the exploit opportunity analyzer computing
device obtains information regarding pileup flaws for a particular
mobile OS configuration (e.g., by accessing pileup flaws 320 from
the risk database 311 or by relying on an assumption that all
potential pileup flaws are applicable to a particular mobile OS
configuration), and obtains mobile OS images corresponding to
different versions of the mobile OS configuration. At stage 403,
based on the information regarding the pileup flaws for that mobile
OS configuration and the obtained mobile OS images, the exploit
opportunity analyzer identifies exploit opportunities by
identifying particular items that are susceptible to pileup attacks
(e.g., new permission definitions, new shared UIDs, and new package
names) as well as identifying the point at which such items present
exploit opportunities (i.e., prior to the new items being added via
updates). These identifications of exploit opportunities are then
stored to the risk database at stage 405.
[0035] Turning back to FIG. 3, given a set of identified exploit
opportunities 321 stored at the risk database 311, the pileup
scanner app 340 can be deployed at mobile devices such as the
mobile device 302. The pileup scanner app 340 determines the
version and configuration of the mobile OS installed at the mobile
device, and queries the risk database 311 for identified exploit
opportunities 321 corresponding to the version and configuration of
the mobile OS installed at the mobile device. The scanner app 340
then uses this information to scan the non-system apps installed on
the mobile device to detect whether any of these apps contains
items corresponding to susceptible items that were identified as
exploit opportunities. Upon completion of the scan, the scanner app
340 reports the results to the user of the mobile device (e.g.,
using a human-machine interface of the device such as the display
and speakers) and/or takes further appropriate action such as
distinguishing between legitimate apps versus malicious apps
detected by the scan as utilizing items susceptible to pileup
attacks (e.g., by cross-checking the detected app against a list of
legitimate non-system apps or checking a signature of the
non-system app), and/or removing apps identified as being malicious
apps.
[0036] FIG. 5 is a flowchart illustrating this process for scanning
the mobile device for pileup vulnerabilities as discussed above
with reference to FIG. 3. At stage 501, the scanner app determines
the mobile OS configuration and version of the mobile OS installed
at the mobile device. At stage 503, the scanner app queries the
risk database regarding exploit opportunities relevant to the
determined mobile OS configuration and version. At stage 505, the
scanner app scans non-system apps installed at the mobile device
based on the identified exploit opportunities received from the
risk database. For example, in an embodiment, if the risk database
indicates a new permission to be defined in a future mobile OS
version corresponding to that mobile OS configuration as an exploit
opportunity, the scanner identifies any non-system app installed on
the mobile device that declares the new permission, defines the new
permission, or defines a base or root relative to the new
permission. Similarly, in another example, if the risk database
indicates a new application package with no shared UID and/or a new
application package with a shared UID to be installed in a future
version of the mobile OS configuration as an exploit opportunity,
the scanner identifies any non-system app installed on the mobile
device that uses the same package name as the new application
package (with respect to the new application package with no shared
UID) and/or any non-system app installed on the mobile device that
has the same shared UID as the new application package with the
shared UID. At stage 507, the results of the scan may be provided
to the user, and/or other appropriate action may be taken (such as
removal of malicious apps).
[0037] In an exemplary embodiment, the scanner app is a non-system
app available for download, for example, through app distribution
avenues such as an app store. In another exemplary embodiment, the
scanner app is a system app, for example, that is utilized as a
part of each mobile OS update process to remove malicious apps
intending to perform pileup attacks before such malicious apps can
execute those attacks.
[0038] Turning back to FIG. 3, as mentioned above, it may simply be
assumed that each potential pileup flaw applies to every mobile OS
configuration. In this case, it will be appreciated that the
information regarding pileup flaws 320 does not necessarily need to
be stored in a risk database. The exploit opportunity analyzer 312
can be configured such that it simply assumes that every type of
potential update flaw (e.g., as discussed above with respect to
FIGS. 2A-2E) is present in the update logic used for each version
of each mobile OS configuration, and identifies exploit
opportunities corresponding thereto.
[0039] In certain embodiments, a vulnerability detector 310 is used
to identify update flaws in the update mechanisms used for each
version of each mobile OS configuration through a
computer-implemented flaw detection process. The vulnerability
detector 310 utilizes code comparison and code verification tools
to identify whether or not certain logical flows are present in the
computer code corresponding to the update mechanism used for mobile
OS updates. For example, by annotating a reference set of update
mechanism code (e.g., the PMS code for an Android mobile OS image)
with appropriate annotations and assertions, the vulnerability
detector 310 can determine whether or not the update procedure
utilized for that mobile OS configuration and version contains
particular pileup flaws. Additionally, by doing a differential
computation between different versions of the update mechanism
code, the vulnerability detector 310 can quickly and efficiently
determine whether such flaws are carried through successive
iterations of the update mechanism code. Alternatively, flaws may
also be identified manually via examination of the code for mobile
OS update mechanisms.
[0040] A compilation of information regarding pileup flaws 320 can
thus be built and stored in risk database 311, such that the
exploit opportunity analyzer 312 is able to access the risk
database 311 to determine which flaws are present in each version
of each mobile OS configuration. This allows the exploit
opportunity analyzer 312 to know, in particular, which items it
needs to look for. For example, for a particular version of a
particular mobile OS configuration where the "shared UID grabbing"
and "data contamination" attacks are not possible due to the use of
an update procedure for that mobile OS configuration/version that
precludes such attacks, the exploit opportunity analyzer 312 would
not consider new shared UIDs or new application package names
introduced by future mobile OS updates as exploit
opportunities.
[0041] Further details and experimental data regarding a particular
exemplary implementation of the vulnerability detector, risk
database, and scanner app in the context of various configurations
of the Android mobile OS are provided in the Xing Publication. As
can be seen from the results presented therein, embodiments of the
invention are able to comprehensively identify a plurality of
pileup-related exploit opportunities, and to utilize the scanner
app to successfully identify and remove malicious apps with
precision and speed.
[0042] It will be appreciated by those of skill in the art that the
execution of various computer-implemented processes and steps
described herein may occur via the computerized execution of
processor-executable instructions stored on a tangible
computer-readable medium, e.g., RAM, ROM, PROM, volatile,
nonvolatile, or other electronic memory mechanism. Thus, for
example, operations performed by the mobile device may be carried
out according to processor-executable instructions and applications
installed at the mobile device, and operations performed by the
exploit opportunity analyzer computing device may be carried out
according to processor-executable instructions and applications
installed at the exploit opportunity analyzer device.
[0043] All references, including publications, patent applications,
and patents, cited herein are hereby incorporated by reference to
the same extent as if each reference were individually and
specifically indicated to be incorporated by reference and were set
forth in its entirety herein.
[0044] The use of the terms "a" and "an" and "the" and "at least
one" and similar referents in the context of describing the
invention (especially in the context of the following claims) are
to be construed to cover both the singular and the plural, unless
otherwise indicated herein or clearly contradicted by context. The
use of the term "at least one" followed by a list of one or more
items (for example, "at least one of A and B") is to be construed
to mean one item selected from the listed items (A or B) or any
combination of two or more of the listed items (A and B), unless
otherwise indicated herein or clearly contradicted by context. The
terms "comprising," "having," "including," and "containing" are to
be construed as open-ended terms (i.e., meaning "including, but not
limited to,") unless otherwise noted. Recitation of ranges of
values herein are merely intended to serve as a shorthand method of
referring individually to each separate value falling within the
range, unless otherwise indicated herein, and each separate value
is incorporated into the specification as if it were individually
recited herein. All methods described herein can be performed in
any suitable order unless otherwise indicated herein or otherwise
clearly contradicted by context. The use of any and all examples,
or exemplary language (e.g., "such as") provided herein, is
intended merely to better illuminate the invention and does not
pose a limitation on the scope of the invention unless otherwise
claimed. No language in the specification should be construed as
indicating any non-claimed element as essential to the practice of
the invention.
[0045] Preferred embodiments of this invention are described
herein, including the best mode known to the inventors for carrying
out the invention. Variations of those preferred embodiments may
become apparent to those of ordinary skill in the art upon reading
the foregoing description. The inventors expect skilled artisans to
employ such variations as appropriate, and the inventors intend for
the invention to be practiced otherwise than as specifically
described herein. Accordingly, this invention includes all
modifications and equivalents of the subject matter recited in the
claims appended hereto as permitted by applicable law. Moreover,
any combination of the above-described elements in all possible
variations thereof is encompassed by the invention unless otherwise
indicated herein or otherwise clearly contradicted by context.
* * * * *
References