eScholarship provides open access, scholarly publishing services to the University of California and delivers a dynamic research platform to scholars worldwide.
Peer Reviewed Title:
Helping Developers Construct Secure Mobile Applications Author:
Chin, Erika Michelle
Acceptance Date: 2013
Series:
UC Berkeley Electronic Theses and Dissertations
Degree:
Ph.D., Computer ScienceUC Berkeley
Advisor(s):
Wagner, David A.
Committee:
Song, Dawn X., Carver, Brian W.
Permalink:
http://escholarship.org/uc/item/4x48p6rz
Abstract:
Copyright Information:
All rights reserved unless otherwise indicated. Contact the author or original publisher for any necessary permissions. eScholarship is not the copyright owner for deposited works. Learn more at http://www.escholarship.org/help_copyright.html#reuse
By
Erika Michelle Chin
A dissertation submitted in partial satisfaction of the requirements for the degree of
Doctor of Philosophy in Computer Science in the Graduate Division of the
University of California, Berkeley
Committee in charge: Professor David Wagner, Chair
Professor Dawn Song Professor Brian Carver
Copyright c 2013 by
Abstract
Helping Developers Construct Secure Mobile Applications by
Erika Michelle Chin
Doctor of Philosophy in Computer Science University of California, Berkeley
Professor David Wagner, Chair
Mobile phones are no longer static devices that simply make phone calls and send SMS messages. Modern smartphones are now closer to general purpose computers. They allow users to customize their phones by installing third-party applications that let them browse the web, check social networking sites, and do online banking. Platform manufacturers, such as Android, introduce new APIs to facilitate the creation of rich applications that interact with other applications, system resources, and external resources (such as web applications). Given the level of trust users put in their phones and the number of sensitive tasks they perform, it is important to understand and improve the security of mobile applications.
Android provides tools to enable rich interaction, but if developers do not know how to use them correctly, they will not use them securely. In this dissertation, we examine how mobile applications interact with each other and their environment. We uncover threats to application security due to developer confusion and general misuse of the features provided by the mobile platform. Specifically, we perform an in-depth analysis of how Android appli-cations interact with each other through inter-process communication mechanisms, how they interact with system resources through Android permissions, and how they interact with web content through WebViews. We build static analysis tools to identify vulnerable applications and measure the prevalence of the vulnerabilities. Through automated and manual analysis, we identify patterns that illustrate how developers misuse these features and make their app-lication vulnerable to attack. We further provide platform-level, API-level, and design-level solutions to help developers and platform designers build secure applications and systems.
Contents
Contents i
1 Introduction 1
2 Analyzing Application Communication in Android 6
2.1 Introduction . . . 6
2.2 Android Overview . . . 7
2.3 Intent-Based Attack Surfaces . . . 12
2.4 ComDroid . . . 18
2.5 Inter-application Communication Evaluation . . . 22
2.6 System Platform Changes . . . 30
2.7 Platform Evaluation . . . 36
2.8 Other Mobile Platforms . . . 41
2.9 Related Work . . . 42
2.10 Conclusion . . . 43
2.11 Acknowledgments . . . 44
3 Analyzing Android Permissions 45 3.1 Introduction . . . 45
3.2 The Android Permission System . . . 46
3.3 Permission Testing Methodology . . . 50
3.4 Permission Map Results . . . 53
3.5 Application Analysis Tool . . . 56
3.6 Application Analysis Results . . . 59
3.7 Related Work . . . 64
3.8 Conclusion . . . 65
3.9 Acknowledgments . . . 66
4 Analyzing Web Interaction in Android 67 4.1 Introduction . . . 67
4.2 Application and Web Interaction . . . 68
4.4 Bifocals . . . 73 4.5 Evaluation . . . 78 4.6 Suggested Improvements . . . 83 4.7 Related Work . . . 86 4.8 Conclusion . . . 86 5 Related Work 88 6 Conclusion 91 A 92 A.1 Manual Review . . . 92
A.2 Example Code . . . 92
A.3 System Broadcast Actions . . . 93
Acknowledgments
I would like to thank the numerous people who have supported me over the years. First and foremost, I would like to thank my family. I am fortunate to have such loving parents whose unwavering confidence, steadfast support, and gentle encouragement have enabled me to pursue my interests and realize my potential. I thank my siblings who have given me a great deal of support in many forms: from my sister who is always just a phone call away when I want to chat, to my brother who is always willing to give me honest feedback. I thank my aunts, with whom I have shared many memorable holidays and vacations full joy and laughter (and full of delicious food).
I would like to express my utmost gratitude to my advisor, David Wagner. His mentorship and invaluable insights have shaped me into the researcher I am today. He taught me how to critically examine systems, discover problems worthy of research, and provide effective evaluations of proposed solutions. His enthusiasm and encouragement have helped me take a step back when I am being overly critical of my own work. By example, he reinforced the importance of taking the time to give back to the community.
I would also like to thank my quals and dissertation committee members, Eric Brewer, Brian Carver, and Dawn Song who so kindly gave their time and attention to give me valuable feedback on my work.
Finally, I would like to thank my colleagues and officemates, Adrienne Felt, Cynthia Sturton, Devdatta Akhawe, Matt Finifter, and Joel Weinberger. We shared many laughs both in the office and out, and I value their friendship. Whether working on the same research or not, their presence has made down-to-the-wire paper submissions much less stressful.
I give many thanks to the students, faculty, and staff at the UC Berkeley Computer Science Department, without which this dissertation would not be possible.
Chapter 1
Introduction
Mobile phones have evolved from simple devices used for phone calls and SMS messages to sophisticated devices with full-fledged operating systems. Phone owners are no longer limited to the simple address book and other basic capabilities provided by the operating system and phone manufacturer. In fact, modern smartphones satisfy many of the same demands that desktop computers satisfy. Modern mobile phones provide wireless access, browser support, and the ability to customize the device by installing third-party applications. Users can check their email, update their social networking profiles, make bank transactions, and play mobile games, not only from their desktop computers, but also from their mobile phones. Mobile phones also provide unique capabilities not available on desktops. With access to GPS, users can get fine-grained, instant location updates. With access to the gyroscope, they now can have a portable portrait leveling tool.
It is not only the physical resources of smartphones that make them notably different from the traditional computer model. Modern mobile phones provide new paradigms and public APIs that allow developers to create applications with rich interactive functionality. These applications communicate with other applications, with protected resources provided by the phone, and with resources provided externally (e.g. across the network through web applications). For example, the Android platform provides a way for applications to ex-pose their data and services to other third-party applications through Android’s message passing service. These messages allow an application to invoke another application’s service while giving the end-user the experience of using a single rich, multifunctional, seamless application. These public APIs introduce new paradigms that help developers create rich applications.
Another unique feature of smartphones is the centralized application repository (e.g., Android Market [3], BlackBerry App World [5], and iTunes App Store [9]). This has changed the application landscape for both users and developers. For developers, it has lowered the bar to entry for dabbling developers (through low, one-time developer fees) and provided a way for them to distribute their applications. For users, the application repository provides a straightforward, centralized way for users to browse and install applications.
The combination of new design paradigms and the larger range in the skills of developers can lead to confusion and insecure code. We examine how mobile phone applications interact with each other and their environment and identify how using these rich features can lead to vulnerable applications. We help secure these applications by exposing common devel-oper mistakes, providing static analysis tools to detect vulnerabilities, suggesting platform changes, and recommending developer education and better API documentation.
We examine three features of modern smartphone platforms.
Intents
First, we examine how applications interact with each other. Intents are messages in An-droid’s inter- and intra-application message passing system. This application communication model promotes the development of rich applications. Android developers can leverage ex-isting data and services provided by other applications while still giving the impression of a single, seamless application. For example, a restaurant review application can ask other ap-plications to display the restaurant’s website, provide a map with the restaurant’s location, and call the restaurant. This communication model reduces developer burden and promotes functionality reuse.
Android’s message passing system can become an attack surface if used incorrectly. The content of messages can be sniffed, modified, stolen, or replaced by malicious third-party applications, which can compromise user privacy. Also, a malicious application can inject forged or otherwise malicious messages, which can lead to breaches of user data and vi-olate application security policies. We build a tool, ComDroid, that detects application
communication vulnerabilities and find that 60% of applications analyzed have at least one
vulnerability. We also find that developers commonly use the message passing system in a way that exposes both the message and the recipient to attack. We discuss insecure de-veloper practices, the tool we built to identify exposed surfaces, and the vulnerabilities we
found in the top 100 most popular applications in greater depth in the next chapter.
We further identify a subclass of communication vulnerabilities that arise due to devel-oper confusion between inter-application and intra-application communication. We find that
developers may publicly expose strictly internal messages. We find that31% of the flaws we
found with ComDroid are due to inter- vs. intra-application confusion. We further propose modifications to the Android platform to automatically detect and protect inter-application messages that should have been intra-application messages.
Permissions
Second, we examine how applications interact with protected resources. Dangerous resources, such as resources that cost money (SMS messages or phone calls), resources that contain private data (access to the user’s location or contacts), or device resources (bluetooth, WiFi), are protected by permissions. Developers must request these permissions upon application installation. As there is a disconnect between the permissions an application uses and the
permissions an application requests, it is possible to overprivilege an application (i.e., request more permissions than an application actually uses). This unnecessarily increases the capa-bilities of a successful attacker on an application. If an attacker can exploit a vulnerability in an application, it will receive access to any protected resources the application requested. We developed a framework for determining whether developers follow the principle of least privilege and request only the permissions that their application needs.
We analyzed 940 applications and found that 30.4% of applications are overprivileged.
Our findings also show that most applications are overprivileged by only 1 permission,
in-dicating that developers are trying to follow least privilege. Extraneous permission requests can be attributed to the lack of adequate documentation on the API permissions. Without this documentation, developers are left to guess which permissions are required. We have found that applications frequently have an extra permission that sounds similar to a per-mission they actually require. We have also found misleading advice on forums that say a permission is needed when it is not. The full details of our framework and analysis can be found in Chapter 3.
WebViews
Third, we examine how applications interact with web content. Mobile devices and platforms are a rapidly expanding, divergent marketplace. Application developers are forced to contend with a multitude of Android mobile phones and tablets; customized OS branches (e.g., Kindle Fire, Nook Tablet); and a score of competing platforms including iOS and Windows Phone. Android developers are responding to the challenge of supporting multiple platforms through the use of WebViews, which allow HTML content to be displayed within an application. At a high level, WebViews provide the same functionality as a web browser, but allow full customizability with respect to how and what content is displayed (e.g., navigation UIs, full screen, etc). These in-application browsers allow developers to write code in platform-neutral HTML and JavaScript that can be displayed by any Android device and version. Furthermore, application updates become simple. Developers merely update the HTML content downloaded by an application.
While convenient, these customized browsers can also pose a threat to application se-curity, as allowing web content to interact with the application increases the application’s attack surface. We show that these problems are real.
One unique feature of Android is that it provides a way for JavaScript in a WebView to invoke Android application code, if this is enabled by the application. In particular, the application developer can register an interface (an API to the mobile application) that can be called by the JavaScript. This allows the web page to access functionality and data exposed by the application. This may seem safe, as typically developers use WebViews to display trusted websites. However, it introduces a new risk [70]. If the user navigates the WebView to an untrusted malicious website, the malicious page may receive access to potentially sensitive application data. Similarly, if the application loads a page over HTTP and if the user is using an insecure WiFi network, a man-in-the-middle could inject malicious
content into the page and mount a similar attack. Allowing JavaScript to invoke application code breaks traditional browser security models.
In Chapter 4, we detail various WebView-based attacks and present our vulnerability
identification tool, Bifocals. We ran the tool on a data set of 864 applications. Among the
608 applications that contain WebViews, we find that over 20% of applications have the
potential to give websites access to code. Of these applications, we find 54% allow a user to
navigate to malicious JavaScript that could access application code.
Based on our findings, we recommend modifications to Android to address these risks.
Our experiments suggest that these modifications would protect more than 60% of the
vul-nerable applications.
Although all of these features are provided by the platform with the intention of easing developer burden and promoting rich, powerful applications, this functionality can come at the cost of application security if not applied correctly. We show that when the API is not clear or not designed with security in mind, developers will create insecure applications. We recommend several approaches that platform designers and application developers can take to avoid these vulnerabilities.
First, platform behavior can be modified to close the vulnerabilities. This approach shifts the implementation burden from individual application developers to the platform developer. Instead of relying on developers to resolve their vulnerabilities (and waiting for them to make the fixes), platform changes could take effect with the push of one over-the-air update and be applied to currently installed applications. Some of the application features are enabled by default. For example, in the the WebViews chapter, we see that JavaScript is granted access to the filesystem by default. This is an unnecessary policy that creates the potential for attack. Features should be turned off by default, and developers should opt in when they want special functionality. Similarly, in the Intents chapter, we see that components are automatically made public when the developer includes an IntentFilter. This behavior is invisible and unintuitive. Developers should explicitly declare their access intentions.
Second, we propose extensions to the API to enforce security or improve the clarity of the functionality. Altering the platform behavior may not always be a reasonable approach, especially if we want to avoid breaking backward compatibility. Extensions to the API (e.g., adding methods) would apply secure practices to new applications without changing the behavior of existing methods. This approach would not affect legacy applications, which is both a benefit and drawback. While it avoids breaking legacy applications, it also does not secure them. It also has the drawback of being slower to take effect, relying on the pace at which new API versions are adopted. In the Intents chapter, we suggest extending the API to separate internal communication from external communication.
Third, we recommend developer education. Unfortunately, security is rarely a primary goal of application developers. By creating clear API documentation and discussing security issues with using the APIs, developers may use the APIs as intended and take steps to avoid
the identified application vulnerabilities. In the permissions chapter, we recommend clear documentation on which APIs require which permissions in order to remove the guesswork by developers that contribute to overprivilege.
Fourth, we recommend that developers practice fundamental security principles such
as principle of least privilege and separation of privilege. By separating privileged and
unprivileged components, developers reduce the risk should a vulnerability be exploited. Finally, we provide static analysis tools that developers can use to identify vulnerabilities in their applications. Through these five approaches, we believe we can improve the security of mobile applications and subsequently the security of the mobile device.
Chapter 2
Analyzing Application Communication
in Android
2.1
Introduction
Android’s application communication model is designed to help promote the development of rich applications. Android developers can leverage existing data and services provided by other applications while still giving the impression of a single, seamless application. For ex-ample, a restaurant review application can ask other applications to display the restaurant’s website, provide a map with the restaurant’s location, and call the restaurant. This commu-nication model reduces developer burden and promotes functionality reuse. Android achieves this by dividing applications into components and providing a message passing system so that components can communicate within and across application boundaries.
Android’s message passing system can become an attack surface if used incorrectly. In this chapter, we discuss the risks of Android message passing and identify insecure developer practices. If a message sender does not correctly specify the recipient, then an attacker could intercept the message and compromise its confidentiality or integrity. If a component does not restrict who may send it messages, then an attacker could inject malicious messages into it.
We have seen numerous malicious mobile phone applications in the wild. For example, SMS Message Spy Pro disguises itself as a tip calculator and forwards all sent and received SMS messages to a third party [87]; similarly, MobiStealth records SMS messages, call his-tory, browser hishis-tory, GPS location, and more [14, 88]. This is worrisome because users rely on their phones to perform private and sensitive tasks like sending e-mail, taking pictures, and performing banking transactions. It is therefore important to help developers write secure applications that do not leak or alter user data in the presence of an adversary.
We examine the Android communication model and the security risks it creates, including personal data loss and corruption, phishing, and other unexpected behavior. We present ComDroid, a tool that analyzes Android applications to detect potential instances of these
vulnerabilities. We used ComDroid to analyze 20 applications and found 34 vulnerabilities
in12 of the applications.
Most of these vulnerabilities stem from the fact that Intents can be used for both intra-and inter-application communication, so we provide recommendations for changing Android to help developers distinguish between internal and external messages.
To automatically protect existing and future applications from these problems, we further propose a modification to the Android platform that heuristically infers unintended expo-sures and delivers those messages internally and prevents internal components from receiving external messages.
We find that99.4% and93.0% of applications are compatible with our sending and
receiv-ing changes, respectively. We find that our changes fix100% of intra-application
vulnerabili-ties found, which represents31.4% of all security flaws identified by ComDroid. Our findings
show that we can improve the security of applications with low backward-compatibility costs.
2.2
Android Overview
Android’s security model differs significantly from the standard desktop security model. Android applications are treated as mutually distrusting principals; they are isolated from each other and do not have access to each others’ private data. We provide an overview of the Android security model and inter-application communication facilities next.
Although other smartphone platforms have a similar security model, we focus on Android because it has the most sophisticated application communication system. The complexity of Android’s message passing system implies it has the largest attack surface. In Section 2.8, we compare and contrast Android to other mobile operating systems.
Threat Model
The Android Market contains a wide array of third-party applications, and a user may install applications with varying trust levels. Users install applications from unknown developers alongside trusted applications that handle private information such as financial data and personal photographs. For example, a user might install both a highly trusted banking application and a free game application. The game should not be able to obtain access to the user’s bank account information.
Under the Android security model, all applications are treated as potentially malicious. Each application runs in its own process with a low-privilege user ID, and applications can only access their own files by default. These isolation mechanisms aim to protect applications with sensitive information from malware.
Despite their default isolation, applications can optionally communicate via message passing. Communication can become an attack vector. If a developer accidentally exposes functionality, then the application can be tricked into performing an undesirable action. If a
developer sends data to the wrong recipient, then it might leak sensitive data. In this chapter, we consider how applications can prevent these kinds of communication-based attacks.
In addition to providing inter-application isolation, the Android security model protects the system API from malicious applications. By default, applications do not have the ability to interact with sensitive parts of the system API; however, the user can grant an application additional permissions during installation. We do not consider attacks on the operating system; instead, we focus on securing applications from each other.
Intents
Android provides a sophisticated message passing system, in which Intents are used to link
applications. An Intent is a message that declares a recipient and optionally includes data; an Intent can be thought of as a self-contained object that specifies a remote procedure to invoke and includes the associated arguments. Applications use Intents for both inter-application communication and intra-application communication. Additionally, the operating system sends Intents to applications as event notifications. Some of these event notifications are system-wide events that can only be sent by the operating system. We call these messages
system broadcast Intents.
Intents can be used for explicit or implicit communication. An explicit Intent specifies
that it should be delivered to a particular application specified by the Intent, whereas an implicit Intent requests delivery to any application that supports a desired operation. In other words, an explicit Intent identifies the intended recipient by name, whereas an implicit Intent leaves it up to the Android platform to determine which application(s) should receive the Intent. For example, consider an application that stores contact information. When the user clicks on a contact’s street address, the contacts application needs to ask another application to display a map of that location. To achieve this, the contacts application could send an explicit Intent directly to Google Maps, or it could send an implicit Intent that would be delivered to any application that says it provides mapping functionality (e.g., Yahoo! Maps or Bing Maps). Using an explicit Intent guarantees that the Intent is delivered to the intended recipient, whereas implicit Intents allow for late runtime binding between different applications.
Components
Intents are delivered to applicationcomponents, which are logical application building blocks.
Android defines four types of components:
• Activities provide user interfaces. Activities are started with Intents, and they can return data to their invoking components upon completion. All visible portions of applications are Activities.
• Services run in the background and do not interact with the user. Downloading a file or decompressing an archive are examples of operations that may take place in a
To Receiver sendBroadcast(Intent i)
sendBroadcast(Intent i, String rcvrPermission)
sendOrderedBroadcast(Intent i, String rcvrPerm, BroadcastReceiver rcvr,...) sendOrderedBroadcast(Intent i, String rcvrPermission)
sendStickyBroadcast(Intent i)
sendStickyOrderedBroadcast(Intent i, BroadcastReceiver receiver,...)
To Activity startActivity(Intent i)
startActivityForResult(Intent i, int requestCode)
To Service startService(Intent i)
bindService(Intent i, ServiceConnection conn, int flags) Table 2.1: A non-exhaustive list of Intent-sending mechanisms
Service. Other components canbind to a Service, which lets the binder invoke methods
that are declared in the target Service’s interface. Intents are used to start and bind to Services.
• Broadcast Receivers receive Intents sent to multiple applications. Receivers are trig-gered by the receipt of an appropriate Intent and then run in the background to handle the event. Receivers are typically short-lived; they often relay messages to Activities or Services. There are three types of broadcast Intents: normal, sticky, and ordered. Normal broadcasts are sent to all registered Receivers at once, and then they disap-pear. Ordered broadcasts are delivered to one Receiver at a time; also, any Receiver in the delivery chain of an ordered broadcast can stop its propagation. Broadcast Receivers have the ability to set their priority level for receiving ordered broadcasts. Sticky broadcasts remain accessible after they have been delivered and are re-broadcast to future Receivers.
• Content Providers are databases addressable by their application-defined URIs. They are used for both persistent internal data storage and as a mechanism for sharing information between applications.
Intents can be sent between three of the four components: Activities, Services, and Broadcast Receivers. Intents can be used to start Activities; start, stop, and bind Services; and broadcast information to Broadcast Receivers. (Table 2.1 shows relevant method sig-natures.) All of these forms of communication can be used with either explicit or implicit Intents. By default, a component receives only internal application Intents (and is therefore not externally invocable).
Component Declaration
To receive Intents, a component must be declared in the applicationmanifest. A manifest is
the manifest to specify what external Intents (if any) should be delivered to the application’s components.
Exporting a Component
For a Service or Activity to receive Intents, it must be declared in the manifest. (Broadcast
Receivers can be declared in the manifest or at runtime.) A component is consideredexported,
or public, if its declaration sets the EXPORTED flag or includes at least one Intent filter.
Exported components can receive Intents from other applications, and Intent filters specify what type of Intents should be delivered to an exported component.
Android determines which Intents should be delivered to an exported component by matching each Intent’s fields to the component’s declaration. An Intent can include a com-ponent name, an action, data, a category, extra data, or any subset thereof. A developer sends an explicit Intent by specifying a recipient component name; the Intent is then deliv-ered to the component with that name. Implicit Intents lack component names, so Android uses the other fields to identify an appropriate recipient.
An Intent filter can constrain incoming Intents by action, data, and category; the
op-erating system will match Intents against these constraints. An action specifies a general
operation to be performed, the data field specifies the type of data to operate on, and the
category gives additional information about the action to execute. For example, a compo-nent that edits images might define an Intent filter that states it can accept any Intent with
an EDIT action and data whose MIME type is image/*. For a component to be an eligible
recipient of an Intent, it must have specified each action, category, and data contained in the Intent in its own Intent filter. A filter can specify more actions, data, and categories than the Intent, but it cannot have less.
Multiple applications can register components that handle the same type of Intent. This means that the operating system needs to decide which component should receive the Intent. Broadcast Receivers can specify a priority level (as an attribute of its Intent filter) to indicate to the operating system how well-suited the component is to handle an Intent. When ordered broadcasts are sent, the Intent filter with the highest priority level will receive the Intent first. Ties among Activities are resolved by asking the user to select the preferred application (if the user has not already set a default selection). Competition between Services is decided by randomly choosing a Service.
It is important to note that Intent filters are not a security mechanism. A sender can assign any action, type, or category that it wants to an Intent (with the exception of certain actions that only the system can send), or it can bypass the filter system entirely with an explicit Intent. Conversely, a component can claim to handle any action, type, or category, regardless of whether it is actually well-suited for the desired operation.
Protection
Android restricts access to the system API with permissions, and applications must request the appropriate permissions in their manifests to gain access to protected API calls. Appli-cations can also use permissions to protect themselves. An application can specify that a caller must have a certain permission by adding a permission requirement to a component’s declaration in the manifest or setting a default permission requirement for the whole app-lication. Also, the developer can add permission checks throughout the code. Conversely, a broadcast Intent sender can limit who can receive the Intent by requiring the recipient to have a permission. (This protection is only available to broadcast Intents and not available to Activity or Service Intents.) Applications can make use of existing Android permissions or define new permissions in their manifests.
All permissions have a protection level that determines how difficult the permission is to acquire. There are four protection levels:
• Normal permissions are granted automatically.
• Dangerous permissions can be granted by the user during installation. If the permission request is denied, then the application is not installed.
• Signature permissions are only granted if the requesting application is signed by the same developer that defined the permission. Signature permissions are useful for re-stricting component access to a small set of applications trusted and controlled by the developer.
• SignatureOrSystem permissions are granted if the application meets the Signature re-quirement or if the application is installed in the system applications folder. Applica-tions from the Android Market cannot be installed into the system applicaApplica-tions folder. System applications must be pre-installed by the device manufacturer or manually installed by an advanced user.
Applications seeking strong protection can require that callers hold permissions from the
higher categories. For example, the BRICK permission can be used to disable a device.
It is a Signature-level permission defined by the operating system, which means that it will only be granted to applications with the same signature as the operating system (i.e., applications signed with the phone manufacturer’s signature). If a developer were to protect
her component with the BRICK permission, then only an application with that permission
(e.g., a Google-made application) could use that component. In contrast, a component protected with a Normal permission is essentially unprotected because any application can easily obtain the permission.
2.3
Intent-Based Attack Surfaces
We examine the security challenges of Android communication from the perspectives of In-tent senders and InIn-tent recipients. First, we discuss how sending an InIn-tent to the wrong application can leak user information. Data can be stolen by eavesdroppers and permis-sions can be accidentally transferred between applications. Next, we consider vulnerabilities
related to receiving external Intents, i.e., Intents coming from other applications. If a
com-ponent is accidentally made public, then external applications can invoke its comcom-ponents in surprising ways or inject malicious data into it. Last, we summarize guidelines for secure Android communication.
Throughout our discussion of component security, we focus our attention on exported components. Non-exported components are not accessible to other applications and thus are not subject to the attacks we present here. We also exclude exported components and broad-cast Intents that are protected with permissions that other applications cannot acquire. As explained in Section 2.2, Normal and Dangerous permissions do not offer components or In-tents very strong protection: Normal permissions are granted automatically, and Dangerous permissions are granted with user approval. Signature and SignatureOrSystem permissions, however, are very difficult to obtain. We consider components and broadcast Intents that are protected with Signature or SignatureOrSystem permissions as private.
Unauthorized Intent Receipt
When an application sends an implicit Intent, there is no guarantee that the Intent will be received by the intended recipient. A malicious application can intercept an implicit Intent simply by declaring an Intent filter with all of the actions, data, and categories listed in the Intent. The malicious application then gains access to all of the data in any matching Intent, unless the Intent is protected by a permission that the malicious application lacks. Interception can also lead to control-flow attacks like denial of service or phishing. We consider how attacks can be mounted on Intents intended for Broadcast Receivers, Activities, and Services. We also discuss special types of Intents that are particularly dangerous if intercepted.
Broadcast Theft
Broadcasts can be vulnerable to passive eavesdropping or active denial of service attacks (Figure 2.1). An eavesdropper can silently read the contents of a broadcast Intent without interrupting the broadcast. Eavesdropping is a risk whenever an application sends a public broadcast. (A public broadcast is an implicit Intent that is not protected by a Signature or SignatureOrSystem permission.) A malicious Broadcast Receiver could eavesdrop on all public broadcasts from all applications by creating an Intent filter that lists all possible actions, data, and categories. There is no indication to the sender or user that the broadcast has been read. Sticky broadcasts are particularly at risk for eavesdropping because they
!"#$%&
'()&
*+%&
,-.("&
!"#$%&
'()&
*+%&
,-.("&
Figure 2.1: Broadcast Eavesdropping (left): Expected recipients Bob and Carol receive the Intent, but so does Eve. Broadcast Denial of Service for Ordered Broadcasts (right): Eve steals the Intent and prevents Bob and Carol from receiving it.
persist and are re-broadcast to new Receivers; consequently, there is a large temporal window for a sticky broadcast Intent to be read. Additionally, sticky broadcasts cannot be protected by permissions.
Furthermore, an active attacker could launch denial of service or data injection attacks on ordered broadcasts. Ordered broadcasts are serially delivered to Receivers in order of priority, and each Receiver can stop it from propagating further. If a malicious Receiver were to make itself a preferred Receiver by registering itself as a high priority, it would receive the Intent first and could cancel the broadcast. Non-ordered broadcasts are not vulnerable to denial of service attacks because they are delivered simultaneously to all Receivers. Ordered broadcasts can also be subject to malicious data injection. As each Receiver processes the Intent, it can pass on a result to the next Receiver; after all Receivers process the Intent, the result is returned to the sending component. A malicious Receiver can change the result, potentially affecting the sender and all other receiving components.
When a developer broadcasts an Intent, he or she must consider whether the information being sent is sensitive. Explicit broadcast Intents should be used for internal application communication, to prevent eavesdropping or denial of service. There is no need to use implicit broadcasts for internal functionality. At the very least, the developer should consider applying appropriate permissions to Intents containing private data.
Activity Hijacking
In an Activity hijacking attack, a malicious Activity is launched in place of the intended
Activity. The malicious Activity registers to receive another application’s implicit Intents, and it is then started in place of the expected Activity (Figure 2.2).
!"#$%&
'()&
*+%&
!"#$%&
'()&
*+%&
Figure 2.2: Activity/Service Hijacking (left): Alice accidentally starts Eve’s component instead of Bob’s. False Response (right): Eve returns a malicious result to Alice. Alice thinks the result comes from Bob.
In the simplest form of this attack, the malicious Activity could read the data in the Intent and then immediately relay it to a legitimate Activity. In a more sophisticated active attack, the hijacker could spoof the expected Activity’s user interface to steal user-supplied data (i.e., phishing). For example, consider a legitimate application that solicits donations. When a user clicks on a “Donate Here” button, the application uses an implicit Intent to start another Activity that prompts the user for payment information. If a malicious Activity hijacks the Intent, then the attacker could receive information supplied by the user (e.g., passwords and money). Phishing attacks can be mounted convincingly because the Android UI does not identify the currently running application. Similarly, a spoofed Activity can lie to the user about an action’s completion (e.g., telling the user that an application was successfully uninstalled when it was not).
Activity hijacking is not always possible. When multiple Activities match the same
Intent, the user will be prompted to choose which application the Intent should go to if a default choice has not already been set. (Figure 2.3 shows the dialog.) If the secure choice is obvious, then the attack will not succeed. However, an attacker can handle this challenge in two ways. First, an application can provide a confusing name for a component to fool the user into selecting the wrong application. Second, the malicious application can provide a useful service so that the user willingly makes it the default application to launch. For example, a user might opt to make a malicious browser the default browser and never get prompted to choose between components again. Although the visibility of the Activity chooser represents a challenge for the attacker, the consequences of a successful attack can be severe.
If an Activity hijacking attack is successful, the victim component may be open to a
secondary false response attack. Some Activities are expected to return results upon
com-pletion. In these cases, an Activity hijacker can return a malicious response value to its invoker. If the victim application trusts the response, then false information is injected into the victim application.
Figure 2.3: The user is prompted when an implicit Intent resolves to multiple Activities.
Service Hijacking
Service hijacking occurs when a malicious Service intercepts an Intent meant for a legitimate Service. The result is that the initiating application establishes a connection with a malicious Service instead of the one it wanted. The malicious Service can steal data and lie about completing requested actions. Unlike Activity hijacking, Service hijacking is not apparent to the user because no user interface is involved. When multiple Services can handle an Intent, Android selects one at random; the user is not prompted to select a Service.
As with Activity hijacking, Service hijacking can enable the attacker to spoof responses (a false response attack). Once the malicious Service is bound to the calling application, then the attacker can return arbitrary malicious data or simply return a successful result without taking the requested action. If the calling application provides the Service with callbacks, then the Service might be able to mount additional attacks using the callbacks.
Special Intents
Intents can include URIs that reference data stored in an application’s Content Provider. In case the Intent recipient does not have the privilege to access the URI, the Intent sender can
set theFLAG_GRANT_READ_URI_PERMISSIONorFLAG_GRANT_WRITE_URI_PERMISSIONflags on
the Intent. If the Provider has allowed URI permissions to be granted (in the manifest), this will give the Intent recipient the ability to read or write the data at the URI. If a malicious component intercepts the Intent (in the ways previously discussed), it can access the data
!"#$%&
'("")*+&
,-./"#$&$)0-)1%123&
Figure 2.4: Intent Spoofing. A malicious application Mallory sends an Intent to an exported component Alice. Alice does not expect to receive a message from Mallory.
URI contained in the Intent. If the data is intended to be private, then an Intent carrying data privileges should be explicitly addressed to prevent interception.
Similarly, pending Intents delegate privileges. A pending Intent is made by one
app-lication and then passed to another appapp-lication to use. The pending Intent retains all of the permissions and privileges of its creator. The recipient of a pending Intent can send the Intent to a third application, and the pending Intent will still carry the authority of its creator. If a malicious application obtains a pending Intent, then the authority of the Intent’s creator can be abused.
Intent Spoofing
A malicious application can launch an Intent spoofing attack by sending an Intent to an
exported component that is not expecting Intents from that application (Figure 2.4). If the victim application takes some action upon receipt of such an Intent, the attack can trigger that action. For example, this attack may be possible when a component is exported even though it is not truly meant to be public. Although developers can limit component exposure by setting permission requirements in the manifest or dynamically checking the caller’s identity, they do not always do so.
Malicious Broadcast Injection
If an exported Broadcast Receiver blindly trusts an incoming broadcast Intent, it may take inappropriate action or operate on malicious data from the broadcast Intent. Receivers often pass on commands and/or data to Services and Activities; if this is the case, the malicious Intent can propagate throughout the application.
Broadcast Receivers that register to receive Intents with system actions are particularly
at risk of malicious broadcast injection. As discussed in Section 2.2, some Intents can only be broadcast by the operating system to inform applications about system events. These Intents contain action strings that only the operating system may add to broadcast Intents. (See Appendix A.3 for examples of system action strings). However, if a Broadcast Receiver registers to receive a system broadcast, the component becomes publicly accessible. In this case, a malicious application can send an Intent explicitly addressed to the target Receiver, without containing the system action string. If the Receiver does not check the Intent’s
action, then the Receiver will be tricked into performing functionality that only the system should be able to trigger.
Malicious Activity Launch
Exported Activities can be launched by other applications with either explicit or implicit Intents. This attack is analogous to cross-site request forgeries (CSRF) on websites [28, 60]. In most cases, a malicious Activity launch would just be an annoyance to the user because the target Activity’s user interface would load. However, three types of Activity launching attacks are possible. First, launching an Activity can cause it to affect application state or modify data in the background. If the Activity uses data from the Intent without verifying the origin of the Intent, the application’s data store could be corrupted. Second, a user can be tricked. For example, a user might click on a “Settings” screen in a malicious application, which directs the user to a screen in a victim application. The user might then make changes to the victim application while believing she is still interacting with the malicious application. Third, a victim Activity could leak sensitive information by returning a result to its caller upon completion.
Malicious Service Launch
If a Service is exported and not protected with strong permissions, then any application can start and bind to the Service. Depending on the duties of a particular Service, it may
leak information or perform unauthorized tasks. Services sometimes maintain singleton
application state, which could be corrupted.
A malicious Service launch is similar to a malicious Activity launch, but Services typically rely on input data more heavily than Activities. Consequently, a malicious launch attack where the Intent contains data is more likely to put a Service at risk. Additionally, there are more opportunities for a bound Service to return private data to its caller because Services often provide extensive interfaces that let their binders make many method calls.
Secure Communication Guidelines
Developers should be cautious about sending implicit Intents and exporting components. When sending private data, applications should use explicit Intents if possible. Internal communication can and should always use explicit Intents. If it is not possible to use explicit Intents, then the developer should specify strong permissions to protect the Intent. Results returned by other components in response to Intents need to be verified to ensure that they are valid results from an expected source.
To make components more secure, developers should avoid exporting components unless the component is specifically designed to handle requests from other applications. Develop-ers should be aware that declaring an Intent filter will export the component, exposing it to attack. Critical, state-changing actions should not be placed in exported components. If a
single component must handle both inter- and intra-application requests, perhaps that com-ponent should be divided into separate comcom-ponents, one for each type. If a comcom-ponent must be exported (e.g., to receive system broadcasts), then the component should dynamically check the caller’s identity prior to performing any operations. The return values of exported components can also leak private data, so developers should check the caller’s identity prior to returning sensitive values. Intent filters are not security measures and can be bypassed with explicit Intents. Requiring Signature or SignatureOrSystem permissions is an effective way of limiting a component’s exposure to a set of trusted applications. See Appendix A.2 for examples of how to create secure code.
2.4
ComDroid
We provide a tool, ComDroid, to detect potential vulnerabilities in Android applications. Applications for the Android platform include Dalvik executable (DEX) files that run on Android’s Dalvik Virtual Machine. We first disassemble application DEX files using the publicly available Dedexer tool [79]. ComDroid parses the disassembled output from Dedexer
and logs potential component and Intent vulnerabilities. We list the types of warnings
ComDroid produces, separated by component and Intent type in Table 2.2.
Permission Map
Every permission can be associated with one of the four protection levels described in
Sec-tion 2.2. We consider both system-defined permissions (found in the system’s Android
Manifest [4]) and application-defined permissions (found in application manifests). We view Normal and Dangerous permissions as easy to obtain (or “weak”) and consider components protected with those permissions as public.
Intent Analysis
ComDroid examines Intent creation and transmission to detect the kinds of vulnerabilities outlined in Section 2.3. To do this, ComDroid statically analyzes disassembled output from Dedexer. Static analysis has commonly been used for bug finding [35, 68, 90]. ComDroid specifically performs flow-sensitive, intraprocedural static analysis, augmented with limited interprocedural analysis that follows method invocations to a depth of one method call. ComDroid parses translated Dalvik files and tracks the state of Intents, IntentFilters,
reg-isters, sinks (e.g., sendBroadcast(), startActivity(), etc.), and components. For each
method that uses Intents (whether it is passed an Intent parameter, instantiates an Intent, or otherwise receives an Intent), ComDroid tracks the value of each constant, string, class, Intent, and IntentFilter. When an Intent object is instantiated, passed as a method param-eter, or obtained as a return value, ComDroid tracks all changes to it from its source to its
Unauthorized Intent Receipt
Intent type Potential vulnerability
Sent Broadcasts Broadcast Theft (without data)
Broadcast Theft (with data)
Sent Activity requests Activity Hijacking (without data)
Activity Hijacking (with data)
Sent Service requests Service Hijacking (without data)
Service Hijacking (with data) Intent Spoofing
Component type Potential vulnerability
Exported Broadcast Receivers Broadcast Injection (without data)
Broadcast Injection (with data)
System Broadcast without Action Check
Exported Activities Activity Launch (without data)
Activity Launch (with data)
Exported Services Service Launch (without data)
Service Launch (with data)
Table 2.2: The list of different vulnerabilities associated with each type of Intent and com-ponent. “Without data” indicates the Intent involved in the attack does not contain extra data, whereas “with data” indicates the Intent does contain extra data in it and thus may additionally be vulnerable to data leakage or injection.
sink. An Intent sink is a call that transmits an Intent to another component, such as the
calls listed in Table 2.1.1
For each Intent object, we track (1) whether it has been made explicit, (2) whether it has an action, (3) whether it has any flags set, and (4) whether it has any extra data. For each sink, we check whether it is possible for any implicit Intent object to flow to that sink. Some Intent-sending mechanisms allow the sender to specify a permission that restricts who the Intent can be delivered to; our analysis records this information.
ComDroid issues a warning when it detects an implicit Intent being sent with weak or no permission requirements. Intents sent through the sink may be vulnerable to action-based attacks (e.g., broadcast denial of service or Activity/Service launching). If any of these Intents contain extra data, then they may also be vulnerable to eavesdropping. We issue warnings with “without data” and “with data” tags to distinguish action-based attacks from eavesdropping. Intents containing data in excess of an action, categories, component name, or package name are considered as having extra data and therefore open to both the action-and data-based attacks.
1We do not consider
stopService()as a vulnerable sink. If a Service is maliciously stopped, it can be
Component Analysis
ComDroid’s component analysis decides whether components might be susceptible to an Intent spoofing attack. ComDroid examines the application’s manifest file and translates Dalvik instructions to get information about each component. For each component, Com-Droid determines whether the component is public based on the presence of Intent filters or
the EXPORTED flag.
Activities and Services are always declared in the manifest. Some Receivers are also declared in the manifest. An Activity can be multiply declared in the manifest using an Activity alias, which presents an existing Activity as a separate component with its own permission, Intent filters, etc. We treat Activities and their aliases as separate components for the purpose of our analysis because an alias’s fields can increase the exposure surface of the component. Also, typically one Activity is marked as a main, launching Activity that the system opens when an application is started. This Activity is public but is generally less likely to be attackable, therefore we do not issue an exposure warning for this case.
Receivers can also be dynamically created and registered using
registerReceiver(Broad-castReceiver receiver, IntentFilter filter). The Intent filter is specified at
regis-tration time and can be changed each timeregisterReceiveris called, so we consider each
registration of a Receiver as a unique component.
If a public component is protected with no permission or a weak permission, ComDroid generates a warning about a potential Intent spoofing attack (malicious Broadcast injec-tion, malicious Activity launch, or malicious Service launch, depending on the component type). Again, we further separate the warnings into “without data” and “with data” warn-ings. Attacks without additional data only invoke the victim component; attacks with data additionally supply the victim component with malicious data. Both are attack surfaces, but attacks with data can potentially give an attacker more control and more opportunities to influence application state or pollute application databases. If the component receives an Intent and only reads the action, categories, component name, or package name, then it is considered to not use extra data. Otherwise, it is considered to use extra data.
ComDroid separately issues warnings for Receivers that are registered to receive system broadcast actions (actions only sent by the system). For these warnings, the solution is to
add a call to android.content.Intent.getAction() to verify that the protected action is
in the Intent (authenticating the sender of the Intent). This is in contrast to other Intent spoofing attacks where the more common solution is to make the component private.
ComDroid also notes when it appears that unique Intent actions are being used to com-municate in place of explicit Intents. If ComDroid finds a public component that registers to receive Intents with a non-Android action string and also finds components that transmit implicit Intents with the same action string, ComDroid issues a warning. We call this “action misuse” to alert the developer that he or she may be using actions insecurely.
Limitations and Discussion
We currently track Intent control flow across functions, but we do not distinguish between
paths through if and switch statements. Instead, we follow all branches. This can lead to
false negatives; e.g., an application might make an Intent explicit in one branch and implicit in another, and our tool would always identify it as explicit. In retrospect, it would have been better to track both. Additionally, our tool does not yet detect privilege delegation through pending Intents and Intents that carry URI read/write permissions; we leave this for future work. Despite these limitations, our experimental results (Section 2.5) indicate that our analysis identifies many actual application vulnerabilities.
It is important to note that ComDroid issues warnings but does not verify the existence of attacks. Some Intents and components are intentionally made public without restriction, for the purpose of inter-application collaboration. It is not possible to automatically infer the developer’s intention when making a component public. We defer to the developer to examine his or her own program and verify the veracity of the warnings. ComDroid supplies the location of the potential vulnerability (filename, method, and line number), the type (malicious Activity launch, broadcast theft, etc.), and whether data leakage/injection could be involved. It could further be extended to explicitly recommend a fix for developers (e.g., make the Intent explicit).
Although ComDroid is intended primarily as a tool for developers, it takes DEX files as input instead of source code. We made this choice due to the difficulty of obtaining source code for most applications. Using DEX files, we can examine the programming practices of the most popular applications in the Android Market. The use of DEX files also allows third parties (such as anti-virus vendors) to conduct security audits. That said, ComDroid requires the user to manually investigate the warnings, which may be difficult for third parties to do quickly (especially on a large scale). Ideally, ComDroid would be used by the developers themselves or security teams contracted by the developers, since they are familiar with the code or have access to the source code.
We considered a dynamic analysis approach to ComDroid as an alternative to our static approach. A dynamic analysis tool would have the benefit of confirming a vulnerability by exploiting it at run-time (although it still may not be able to make the human distinction of whether the bug is severe or not), but it may be challenging to explore the application state space to obtain full coverage. Static analysis has the benefit of discovering vulnerabilities that may not have been exposed at runtime. It is worth investigating a combined static and dynamic tool in future research to leverage the benefits of both approaches.
Type of Exposure Percentage
Broadcast Theft 44 %
Activity Hijacking 97 %
Service Hijacking 19 %
Broadcast Injection 56 %
System Broadcast w/o Action Check 13 %
Activity Launch 57 %
Service Launch 14 %
Table 2.3: The percentage of applications that had at least one warning per exposure type
2.5
Inter-application Communication Evaluation
We ran ComDroid on the top50popular paid applications and on50of the top100 popular
free applications on the Android Market [3].2 We report ComDroid’s warning rates and
discuss common application weaknesses. We emphasize that ComDroid issues warnings
about potential security issues; manual review is needed to determine the functionality of the Intent or component and decide whether the exposure can lead to a severe vulnerability.
We manually examined 20 applications to check ComDroid’s warnings, evaluate our tool,
and detect vulnerabilities.
Automated Analysis
ComDroid detected a total of 1414 exposed surfaces across 100 applications. There were
401 warnings for exposed components and 1013 warnings for exposed Intents. In Figure 2.5
we show what fraction of sent Intents are implicit; on average, about 40% are implicit. In
Figure 2.6, we show the frequency of exposed components out of the total number of
com-ponents for each application, separated by component type. 50%of Broadcast Receivers are
exposed, and most applications expose less than 40% of Activities to external applications.
Our tool does not generate a warning for an application’s primary launcher Activity; conse-quently, many applications that show zero exposed Activities warnings may have one public launcher Activity. There is no clear distribution for the exposure of Services because few applications have multiple Service components.
We also show the breakdown of warnings by type in Figure 2.7. Intuitively, there is more Intent communication between Activities so there are more exposure warnings for Activity-related Intents than Broadcast- and Service-Activity-related Intents combined.
Table 2.3 shows the percentage of applications that have at least one of a given type of surface exposure. Of sending-related vulnerabilities, 44% of applications have
Broadcast-2Specifically, we considered the applications ranked 51-100 for the free applications. Dedexer was not
0! 2! 4! 6! 8! 10! 12! 0 ! 5! 10 ! 15 ! 20 ! 25 ! 30 ! 35 ! 40 ! 45 ! 50 ! 55 ! 60 ! 65 ! 70 ! 75 ! 80 ! 85 ! 90 ! 95 ! 100 ! # of Applications !
Implicit / Total Intents (%)!
Figure 2.5: Histogram showing the percentage of implicit Intents out of total Intents for each application. 0! 5! 10! 15! 20! 25! 30! 35! 40! 45! 0 ! 5! 10 ! 15 ! 20 ! 25 ! 30 ! 35 ! 40 ! 45 ! 50 ! 55 ! 60 ! 65 ! 70 ! 75 ! 80 ! 85 ! 90 ! 95 ! 100 ! # of Applications !
Exposed Component Warnings / Total Components (%)!
Activities! Services! Receivers!
Figure 2.6: Histogram showing the percentage of components with warnings out of total components for each application.
!"#$%&$'() *+,-.)/01) 2&345(6) 758$&95:;.)<=1) >,"45&,) 758$&95:;.) ?1) !"#$%&$'() @:8,&3#:.)/A1) >6'(,B) !"#$%&$'()CDE:.) /1) 2&345(6) F$D:&+.) /01) >,"45&,)F$D:&+.) /1) !"#$%&$'()*+,-) 2&345(6)758$&95:;) >,"45&,)758$&95:;) !"#$%&$'()@:8,&3#:) >6'(,B)!"#$%&$'()CDE:) 2&345(6)F$D:&+) >,"45&,)F$D:&+)
Figure 2.7: Breakdown of warnings by type.
related warnings. Of these applications, none of them restrict the broadcast in any way or make the Intent explicit.
Although 97% of applications have Activity hijacking warnings, on average only 27.7% of Intents that involve starting an Activity are open to an Activity hijack. This is promising as it shows that developers are making a majority of their Activity communications explicit. 19% of applications contain Service hijacking warnings.
Over 56% of applications have a Broadcast Receiver that may be vulnerable to a Broad-cast injection attack. Broken down by number of exposed Receivers per application (Fig-ure 2.8), we see that most applications expose one or two Receivers, if any.
13% of applications have a public Receiver that accepts a system Broadcast action but does not check that the Intent actually contains that action (a definite bug that may also lead to a serious vulnerability).
57% of applications have at least one Activity that may be vulnerable to a malicious Activity launch. The other 43% only expose the main launching Activity. We display the break down of these malicious Activity launch warnings by number of malicious launch warnings per application (Figure 2.9). On average, applications have one exposed Activity in addition to the launch Activity. This is good news, as it seems that most applications are limiting their Activities from exposure. We can also see a handful of applications expose 11 to 20 Activities and can benefit from further investigation. Finally, 14% of applications have at least one Service that may be vulnerable to malicious Service launches.
Our results indicate that Broadcast- and Activity- related Intents (both sending to and receiving from) play a large role in application exposure.
0
!
10
!
20
!
30
!
40
!
50
!
60
!
0
!
1
!
2
!
3
!
4
!
5
!
6
!
7
!
8
!
9
!
10
!
11-15
!
# of Applications
!
# of Exposed Broadcast Receivers
!
Figure 2.8: Histogram showing the number of Broadcast Receivers with warnings per appli-cation.
0
!
5
!
10
!
15
!
20
!
25
!
30
!
35
!
40
!
45
!
0
!
1
!
2
!
3
!
4
!
5
!
6
!
7
!
8
!
9
!
10
!
11-15
!
16-20
!
# of Applications
!
# of Exposed Activities
!
Manual Analysis
We randomly selected 20 applications from the 100 mentioned earlier, and then we
manu-ally inspected ComDroid’s warning for these applications to evaluate how many warnings correspond to vulnerabilities. In this section, we present the findings of our manual analysis and discuss three example applications with vulnerabilities. See Appendix A.1 for the list of applications reviewed.
ComDroid generated 181 warnings for the 20applications. We manually reviewed all of
them and classified each warning as a vulnerability, not a vulnerability, or undetermined. We define a vulnerability as a component or Intent that exposes data or functionality that can be detrimental to the user. For example, an unprotected broadcast is only a vulnerability if it includes sensitive user data or if its theft results in a DoS to a legitimate service. Similarly, Activity launching is only a vulnerability if the victim Activity toggles state or operates on the Intent data in a way that negatively affects the application. Negative consequences may be context-dependent; consider an application that sends a user to another application to view a website. Normally, it will not matter if the website Activity is hijacked, but the hijacking could lead to phishing if the user expects to enter payment information at the website. We further divide vulnerabilities into two types: (1) dangerous vulnerabilities that do not rely on user interaction and (2) spoofing vulnerabilities that might occur if the user is tricked. We also separately note commonly found unintentional bugs. We classify warn-ings as bugs when the developer appears to be misusing or misunderstanding the Android communication design. This category includes action misuse and system broadcasts without action verification.
In order to detect vulnerabilities, we reviewed the disassembled code of the application components with warnings. We also installed the applications and interacted with them to dynamically observe their Intents. When necessary, we built “attack” code to confirm or disprove vulnerabilities. This review process does not reflect a developer’s experience with ComDroid because developers would have access to the source code and knowledge of the application’s intended functionality, which we did not have.
Of the181 warnings, we discovered20definite vulnerabilities,14spoofing vulnerabilities,
and16common, unintentional bugs (that are not also vulnerabilities). Of the20applications
examined, 9 applications contain at least 1 definite vulnerability and 12 applications have
either definite or spoofing vulnerabilities. This demonstrates the prevalence of insecure
Intent communication. Table 2.4 shows the number of vulnerabilities and warnings for each category.
ComDroid has an overall vulnerability and bug detection rate of 27.6%. Broken down by Unauthorized Intent Receipt vulnerabilities/bugs and Intent Spoofing vulnerabilities/bugs, it has a rate of 22.6% and 38.6%, respectively. As shown in the table, Activity hijacking has the highest number of false positives, with a lower detection rate of 15.2%. Examining only the broadcast-related vulnerabilities (theft, injection, and system broadcasts without action check), ComDroid has a detection rate of 61.2%.
