University of Southern California Dissertations and Theses

Reducing inter-component communication vulnerabilities in event-based systems

(USC Thesis Other)

Reducing inter-component communication vulnerabilities in event-based systems

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content Reducing Inter-Component Communication Vulnerabilities in Event-Based Systems by Youn Kyu Lee A Dissertation Presented to the FACULTY OF THE USC GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (COMPUTER SCIENCE) December 2017 Copyright 2017 Youn Kyu Lee Dedication To My Dear and Loving Family Inkil Lee, Soook Kim, and Jeoungkyu Lee ii Acknowledgments I’ve always dreamed of this moment ever since I began my long journey to become a PhD. The last five years of my grad life have been the most exciting time of my life. However, it was not without countless moments of doubting myself and fearing uncertainties lying ahead. I cannot imagine having done this without the support of so many great, loving people around me. Although the cover of this dissertation prints my name, their help, guidance and inspiration are everything that made this milestone possible. I am forever grateful to everyone who has been there for me. I would especially like to thank my advisor, Nenad Medvidovic, for his invaluable guidance and mentorship. Whenever I was going through struggles—whether it be research, language or cultural differences—he has always trusted me and patiently encouraged me even when I made mistakes. It was daunting and frustrating when my conference papers were rejected twice. What picked me up most was the confidence and faith he had in me whenever he said “Youn, we can make it.” I could grow as a scholar because he has always guided and inspired me to become a hard-working researcher, engineer, and presenter. I would also like to thank the members of dissertation committee, Professor William G.J. Halfond and Professor Sandeep Gupta for the constructive comments they have given me on my research. This dissertation would not have been of this quality without their meticulous guidance. My sincere appreciation goes to the members of the SoftArch research lab. I am grateful to have met Jae, my mentor and best friend, who has always encouraged me from the very beginning iii to proceed with my research and helped me prepare everything I needed to survive and become a scholar. Many thanks to Reza who has offered me his insights and advice to help form concrete ideas for my research. I should not forget to thank Ivo, Josh, and Farshad who supported me during the early years to adapt into PhD. life. Thank you, Arman, sitting right next to me in the lab, he helped me at all times, not to mention awesome research we pulled off together. Duc has shown and inspired me to enjoy Ph.D life and Daniel has always gladly answered my questions and done my small and big favors. Yixue has been a great, fun-to-talk-to cohort and we share so many great experiences. Roohy, without his devout help, SEALANT would not have come into the world. Pooyan has always motivated me with his creative and yet great questions. I’d like to thank Sue for sharing her experiences about grad school life with me. My special thanks goes out to Lizsl, who has been the best program advisor and a good friend. I cannot imagine having done this without her help and encouraging support. I should not forget to mention Lebron James and his team, Cleveland Cavaliers. I have been thrilled to watch their hustle play and I will always remember the days I wrote my papers watching their great games. My heartfelt thanks to one-of-a-kind best friend Eun Jung, who has supported me through thick and thin. Her positivity and energetic vibes have picked me up from time and again when I faced hardships. I would not have pulled off this journey without her selfless and caring support. I’d also like to thank many friends in KGSA, Slam-Dunk and K-town which have made my past five years cheerful and joyful. Last but not least, my sincere gratitude goes out to my family. I am lucky and grateful to have my father Inkil Lee, my mother Soook Kim and my younger brother Jeoungkyu Lee, who have always had faith in me and supported me with everything they had. My grandfather Hayong Lee iv and grandfather-in-law Imsik Kim to whom I promised to bring a Ph.D degree unfortunately passed away a few years ago. I wish they would be proud of me from above, knowing that I finally made it. v Table of Contents Dedication ii Acknowledgments iii List Of Tables viii List of Figures ix Abstract x Chapter 1 Introduction 1 1.1 Motivation and Problem Description 2 1.2 Insights and Hypotheses 6 1.3 The Proposed Solution and The Contributions 8 1.4 Structure of This Dissertation 10 Chapter 2 Foundations 11 2.1 Background 11 2.1.1 Event-Based Systems 11 2.1.2 Android Communication Model 13 2.1.3 Program Analysis 14 2.1.4 Visualization 14 2.2 Event Attacks 15 2.2.1 Definition 15 2.2.2 Example of Event Attack: Web Application 16 Chapter 3 Approach 19 3.1 A Taxonomy for Security Flaws in Event-Based Systems 21 3.1.1 Methodology 21 3.1.2 Taxonomy 24 3.1.3 Relationship between Security Flaws and Event Attacks 29 3.2 SEALANT 34 3.2.1 Design 36 3.2.2 Implementation 48 3.3 SCUTUM 50 3.3.1 Design 50 vi 3.3.2 Implementation 60 3.4 ViVA 61 3.4.1 Design 61 3.4.2 Implementation 69 Chapter 4 Evaluation 72 4.1 Evaluation of SEALANT 74 4.1.1 Applicability and Accuracy 74 4.1.2 Effectiveness 78 4.1.3 Performance 83 4.1.4 Usability 86 4.2 Evaluation of SCUTUM 90 4.2.1 Accuracy 90 4.2.2 Applicability 92 4.2.3 Performance 93 4.3 Evaluation of ViVA 96 4.3.1 Usability 96 4.4 Threats to Validity 101 Chapter 5 Related work 103 5.1 Security in Event-Based Systems 103 5.2 Security in Android 105 5.3 Security in Web Applications 107 5.4 Visualization 109 Chapter 6 Conclusion 110 References 113 vii List Of Tables 2.1 Seven Types of Event Attacks 15 3.1 EBS Security Flaws, Event Attacks, and Existing Solutions 32 3.2 Attributes of component and intent in ICC graph 41 4.1 Applying SEALANT on the 135 Apps in My Core Test Suite 75 4.2 Analyzer’s Performance on Different Number of Apps 84 4.3 Differences in Execution Times (in milliseconds) 85 4.4 Difficulty, Confidence, and Response Time per Dialog Type 88 4.5 Four Subject Systems and Results 92 4.6 The Number of Identified Vulnerabilities and The Level of Difficulty per Session 98 viii List of Figures 1.1 Event Attacks in Android 3 3.1 Security Flaw Taxonomy for EBS 25 3.2 Overview of SEALANT’s Operation 37 3.3 An Operational Process of Analyzer 39 3.4 The Architecture and Operation of Interceptor 45 3.5 An Operational Process of SCUTUM 52 3.6 An Event Flow Graph 54 3.7 Overview of ViVA’s Architecture 64 3.8 User Interface of ViVA’s Prototype for Prism-MW 66 3.9 User Interface of ViVA’s Prototype for Android 68 4.1 SCUTUM’s Performance on Different Number of Components 94 ix Abstract Event-based system (EBS) has become popular because of its high flexibility, scalability, and adaptability. These advantages are facilitated by its reliance on implicit invocation and implicit concurrency. Specifically, in EBS, components may not know the consumers of the events they publish, nor do they necessarily know the producers of events they consume. This communication mechanism is based on non-determinism in event processing, which can introduce inherent security vulnerabilities into a system referred to as event attacks. Event attack is a particular type of attack that can abuse, incapacitate, and damage a target system by exploiting the system’s event-based communication model. Different types of event attacks have been identified in a range of domains to date. It is hard to prevent event attacks because they are administered in a way that does not differ from ordinary event-based communication in general. While a number of techniques have focused on security threats in EBS, they do not appropriately resolve the event attack problems or suffer from inaccuracy in detecting and preventing event attacks. Furthermore, fundamental security flaws, which can be exploited by event attacks, have not been clearly identified yet. In order to address the risk of event attacks, this dissertation presents four main approaches: (1) a new taxonomy for security flaws in EBS, which can serve as a basis for resolving event attack problems; (2) SEALANT (Security for End-users of Android via Light-weight ANalysis Techniques), a novel protection mechanism for Android, one of the most widely used event-based x platforms; (3) SCUTUM (SeCUrity for evenT-based systems implemented Using MOM platforms), a novel vulnerability detection technique for EBSs that are implemented by using message-oriented middleware platforms; and (4) ViVA (Visualizer for eVent-based Architectures), a new visualization technique for monitoring and identifying security vulnerabilities in EBS. This dissertation presents the results from empirical and analytical evaluation on the proposed approaches. SEALANT’s extensive evaluation demonstrates that it detects and blocks event attacks with high accuracy in a corpus of over 1,100 real-world apps, it suffers from fewer false alarms than existing techniques in several representative scenarios, its performance overhead is negligible, and end-users do not find it challenging to adopt. SCUTUM has been evaluated on 25 open-source benchmark apps and eight real-world EBSs, and exhibited higher precision and recall in vulnerability detection than those of existing techniques. To evaluate ViVA, a user study involving 30 participants was conducted. The results indicated that the participants were able to identify more vulnerabilities that expose the target EBS to event attacks by using ViVA, compared to those identified by using existing techniques. xi Chapter 1 Introduction An event-based system (EBS) developed by using a message-oriented middleware (MOM) platform is prevalent because it is highly scalable, easy to evolve, and has low coupling that makes it suitable especially for highly heterogeneous distributed systems [65,76,77,88,104,181]. In EBS, components (interchangeably referred to as “event-clients” or “event-agents”) invoke each other implicitly by publishing event messages (simply referred to as “events”) instead of directly calling other components via explicit references. Accordingly, components may not know the consumers of the events they publish, nor do they necessarily know the producers of events they consume. This communication mechanism is based on the non-determinism in event processing, which inherently exposes an EBS to security threats referred to as event attacks. An event attack abuses, incapacitates, and damages an EBS by exploiting the system’s event- based communication model. For example, a malicious component can publish a spoofed event that is indistinguishable from a legitimate event, or can intercept or eavesdrop on an event containing sensitive information, which potentially poses serious security issues to a system. The risk of event attacks is increased especially when components comprising a system are not pre-defined or types of components are not clearly delineated (e.g., Android framework [7]), which allows a 1 malicious component to behave as a legitimate component. Different types of event attacks haven been identified to date [56,57,62,68,74,91,153,170,178,183], such as spoofing, eavesdropping, and collusion, which will be elaborated in the following chapter. The goal of this dissertation is to address all types of event attacks identified to date by (1) identifying and classifying security flaws in EBS, which can serve as a basis for resolving event attack problems, (2) detecting security flaws that are vulnerable to event attacks from EBSs including those implemented by using MOM platforms as well as Android which is the most widely used mobile platform, and (3) monitoring and controlling vulnerable event communication channels at runtime. In the remainder of this chapter, I will first provide motivating examples of event attacks. I will then discuss the challenges of as well as existing works regarding preventing event attacks. After that, I will provide my insights and hypotheses. Finally, I will introduce my proposed approaches for addressing event attacks. 1.1 Motivation and Problem Description Motivating Examples of Event Attacks: Android Applications In the Android framework, components communicate by exchanging a particular type of event called intent [74]. Details of Android’s communication model will be elaborated in Section 2.1.2. As motivating examples of event attacks, This section will present simplified examples of the three well-known types of event attack in Android applications (“app”s): intent spoofing, unauthorized intent receipt, and privilege escalation [68,74]. Intent spoofing is depicted in Figure 1.1(a) and Listings 1.1 and 1.2. Figure 1.1(a) shows component M1 from malicious app MalApp1 that may send an intent to component V2 from victim 2 Component V3 VicApp2 Component V1 MalApp1 VicApp1 (b) unauthorized intent receipt (a) intent spoofing (c) privilege escalation Component V2 Component M1 Component V4 MalApp2 Component M2 Component V5 Component V6 Component V7 Component V8 MalApp3 Component M3 VicApp4 VicApp3 P1 P1 Figure 1.1: Event Attacks in Android Listing 1.1: Component V2 of VicApp1 1 public class V2 extends Activity { 2 public void onStart() { 3 Intent i = getIntent(); 4 String recipient = i.getStringExtra("Recipient"); 5 String amount = i.getStringExtra("Amount_USD"); 6 sendMoneyToRecipient(recipient, amount); }} Listing 1.2: Component M1 of MalApp1 1 public class M1 extends Activity { 2 public void onCreate ( Bundle savedInstanceState ) { 3 Intent i = new Intent(); 4 i.setClassName("com.VicApp1", "com.VicApp1.V2"); 5 i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); 6 i.putExtra("Recipient", ATTACKERS_ACCOUNT_NUMBER}); 7 i.putExtra("Amount_USD", 1000000); 8 startActivity(i); }} Listing 1.3: Component V3 of VicApp2 1 public class V3 extends Activity { 2 public void onClick(View v) { 3 LocationManager m = (LocationManager) getSystemService(Context.LOCATION_SERVICE); 4 Location location = 5 m.getLastKnownLocation(LocationManager.GPS_PROVIDER); 6 Intent i = new Intent() ; 7 i.setAction ("ShowLocation"); 8 i.putExtra ("Location", location.toString()); 9 sendBroadcast(i); }} 3 app VicApp1 in order to exploit VicApp1’s functionalities (e.g., transferring money to a recipient). Listing 1.1 shows where VicApp1’s vulnerability resides: V2 is designed to transfer money to a recipient specified by an incoming intent from component V1. Listing 1.2 illustrates how M1 of MalApp1 sends an explicit intent that specifies V2 as its destination component, along with the attacker’s account number as the recipient, V2, as it receives the intent, will send money to the attacker. Unauthorized intent receipt is illustrated in Figure 1.1(b) and Listing 1.3. In Android, if an intent is broadcast without proper permission restrictions, a malicious component can receive it by declaring attributes matching those of the intent. Component V3 of VicApp2 from Figure 1.1(b) is designed to broadcast intents to components in the same app such as V4. Listing 1.3 shows V3’s code that broadcasts an implicit intent on a click event, with the action attribute ShowLocation and the location information. Although not an intended receiver, malicious component M2 of MalApp2 is able to eavesdrop by listening to ShowLocation intents and to obtain the end-user’s current location. Privilege escalation is depicted in Figure 1.1(c). Component V6 of VicApp3 provides a sensitive API that is protected with permission P1. While component V8 of VicApp4 is granted P1, M3 of MalApp3 is not, which means that M3 is restricted to directly access the API of V6. Nonetheless, M3 can still invoke the API in an indirect way, via V8 which is not protected by any permissions and can be triggered by any component via an explicit intent regardless the component belongs to the same app (e.g., V7) or another app (e.g., M3). By triggering V8, M3 is able to access the sensitive API of V6 without acquiring P1. The above examples demonstrate that the event attacks are administered in a way that does not differ from ordinary intent exchanges between apps. For instance, recall the first example from Listing 1.2: the attack took place when MalApp1 sent an intent by calling startActivity(), which 4 is a standard Android method for sending an intent. This makes the identification and restriction of event attacks especially challenging. Moreover, since event interaction can be performed in an essentially invisible way (e.g., via sendBroadcast() or through transitive paths), it is difficult for end-users to recognize when the attacks are actually committed. An app developer’s caution may minimize the risk of the attacks, but it requires error-prone manual effort, while end-users may still download other unsafe apps that were created or modified by malicious developers. Challenges of Preventing Event Attacks Prevention of event attacks is challenging because it is (1) not easy to anticipate the surfaces that are vulnerable to event attacks, (2) hard to distinguish malicious components from ordinary ones, and (3) hard to distinguish malicious event communication from ordinary communication. Furthermore, event-based communication is hard to analyze because components publish and consume events via ambiguous interfaces where they accept any type of events in principle and depend on individual components to implement functionality that correctly generates, filters, dispatches, and processes events. Accordingly, existing security analysis techniques for general software systems cannot be directly used to prevent event attacks. Existing Approaches for Preventing Event Attacks A number of techniques have focused on security issues in EBS including event attacks. However, fundamental security flaws in EBS, which can be exploited by event attacks, are not clearly identified yet. Moreover, existing works have not been able to appropriately resolve the event attack problems. Specifically, existing techniques for minimizing security threats in EBSs, such as role-based access control [55,62] and encryption of events [153], make certain assumptions 5 about the components engaged in event-based interactions, namely, they assume that it will be known which components are “safe”. However, these techniques cannot properly handle the event- related security threats when the types of components are not clearly delineated, such as Android framework [7]. Recently, while several recent approaches have focused specifically on the security of Android [56,74,93,122,130,133,150,163,190,200], those approaches either target the aspects of Android that do not pertain to event attacks or suffer from inaccuracy (e.g., false positives or false negatives) in preventing event attacks. 1.2 Insights and Hypotheses The goal of this dissertation is to protect EBSs from event attacks. The rest of this section presents the hypotheses that this dissertation tests in order to overcome the challenges of preventing event attacks and the limitations of existing approaches. Hypothesis 1 Insight1A:Anadversarymayaccesssensitiveresourcesbytakingadvantageofthenon-deterministic nature of event communication in EBS. Insight 1B: While an event consumption during runtime is non-deterministic, the corresponding source code where publication and consumption happen is deterministic. Hypothesis 1: By analyzing the source code of components in a system, a static analysis approach can report event communication channels that are vulnerable to event attacks with high precision and recall. 6 Hypothesis 2 Insight 2A: In EBSs using MOM platforms, an event broker administers event communication. Insight 2B: Existing prevention techniques (e.g., role-based access control and policy enforcement) suffer from inaccuracy (i.e., false positives/negatives) in preventing event attacks. Hypothesis 2: Inducing event brokers to control event routing based on the static analysis results will prevent event attacks with higher accuracy than existing techniques. Hypothesis 3 Insight 3: End-users are typically expected to make several types of security-related choices (e.g., installation of an app) during their use of a mobile system. Hypothesis 3: A non-expert end-user can make event communication control choices that prevent an event attack at a high rate that is statistically significant. Hypothesis 4 Insight 4A: Non-deterministic nature and implicit invocation in EBS’s communication reduce the understandability of the system. Insight 4B: Software visualization supports the understanding of a target system’s structure and behavior as well as the exploration of security vulnerabilities. Hypothesis 4: A runtime monitoring with visualization enables engineers to detect more vulnera- bilities and unexpected behaviors in a target EBS than existing techniques. 7 1.3 The Proposed Solution and The Contributions To address all types of event attacks identified to date, this dissertation contributes four main approaches as follows: 1. A new taxonomy for security flaws in EBS—This can serve as a basis for resolving event attack problems. Built upon previously identified security flaws in general software systems [192], the taxonomy classifies particular types of inherent flaws within EBS [56,57,62,68,74,91,153, 170,178,183]. The taxonomy also provides the relationships among the security flaws, event attacks that can exploit those flaws, and existing solutions targeting event attacks. 2. SEALANT (Security for End-users of Android via Light-weight ANalysis Techniques): This is a novel protection mechanism for Android, one of the most widely used event-based platforms [3], suffering from event attacks. SEALANT aims to help Android end-users protect their devices against event attacks. To this end, SEALANT provides a combined technique of static analysis and dynamic event control to enable accurate blocking of event attacks. SEALANT statically identifies vulnerabilities between components which belong to different apps through a novel combination of data-flow analysis and compositional pattern matching. Based on the identified vulnerabilities, SEALANT automatically monitors each instance of event communication during runtime, enabling end-users to block it, as needed. 3. SCUTUM (SeCUrity for evenT-based systems implemented Using MOM platforms): Since Android uses its system-specific communication model which is vulnerable to particular types of event attack, a generalized solution is required to protect other types of EBSs. SCUTUM is a novel vulnerability detection technique for EBSs that are implemented by using MOM platforms (e.g., event-based web apps using Java Message Service [31]). SCUTUM statically 8 identifies security vulnerabilities that expose the system to event attacks from a target EBS by performing vulnerable-flow analysis and pattern matching on event communication channels. 4. ViVA (Visualizer for eVent-based Architectures): This is a new visualization technique for monitoring and inspecting a target EBS. ViVA effectively aids engineers to identify security vulnerabilities that expose the system to event attacks by visualizing target EBS’s architectural information and runtime event communication between components. This dissertation presents different types of empirical and analytical evidence on how the proposed techniques successfully address event attacks. The proposed solutions, SEALANT, SCUTUM, and ViVA have been successfully implemented and evaluated on real-world EBSs. I evaluated SEALANT’s ability to identify vulnerable event communication channels among a set of 1,150 real-world Android apps and to selectively block those channels. The results indicate that SEALANT was able to identify vulnerable event communication channels with high accuracy, while it was able to capture and block event communication via each identified channel with perfect accuracy. I also assessed SEALANT’s effectiveness via comparative analysis against existing techniques. The results show that SEALANT suffered from fewer false alarms while blocking the same or greater number of vulnerable event communication. In addition to this, I performed a user study and survey involving 189 Android end-users in employing SEALANT. Overall, the end-users were able to effectively use SEALANT to block vulnerable event communication and did not find it burdensome to use. Finally, I examined SEALANT’s performance by measuring its analysis time using different numbers of apps, and the resource overhead imposed by its runtime event control. SEALANT was scalable to a large number of apps, while it required nominal additional resources. I evaluated SCUTUM’s ability to identify vulnerable event communication channels from 33 EBSs that are implemented by using different MOM platforms. SCUTUM was able to identify 9 vulnerable event communication channels with higher accuracy, compared to existing techniques. I also assessed SCUTUM’s performance by measuring its analysis time using different numbers of components. The result shows that SCUTUM was scalable to analyzing the apps containing large numbers of components. Lastly, I evaluated ViVA’s ability to assist engineers to identify vulnerabilities from EBSs. The results of user study involving 30 engineers indicate that they were able to detect more vulnerabilities that expose the target EBS to event attacks by using ViVA than those identified by using existing solutions. 1.4 Structure of This Dissertation The remainder of this dissertation is structured as follows: Chapter 2 defines the fundamental concepts and definitions on which this dissertation is based. The proposed solutions are discussed in Chapter 3. Chapter 4 describes the evaluation followed by Chapter 5 which covers the related work. Finally, Chapter 6 concludes the dissertation. 10 Chapter 2 Foundations This chapter describes the background and definitions of the key concepts on which this dissertation is founded. Section 2.1 introduces the basic concepts of the following the relevant domains: event-based systems, Android communication model, program analysis, and visualization. Section 2.2 provides definitions for different types of event attack and describes an example. 2.1 Background 2.1.1 Event-Based Systems Event-based systems (EBSs) developed by using message-oriented middleware (MOM) platforms are widespread. MOM licenses are a fast-growing [64], multi-billion-dollar market [3]. The event-based software architectural style [182] has been widely used in both user-interface software (e.g., Android apps [7]) and wide-area apps such as financial markets, logistics, and sensor networks (e.g., web apps [31]). EBSs are popular because they are highly scalable, easy to evolve, and have low coupling that makes them suitable especially for highly heterogeneous distributed system [65,76,77,88,104,181]. These popular attributes are basically led by EBS’s communication model. 11 In EBSs, components (i.e., the units of computation and data; interchangeably referred to as “event-client” or “event-agents”; hereafter, “component”) communicate asynchronously with each other by using messages [143]. A message typically describes one or more observed events. Event is an occurrence of anything that can be observed by a component (e.g., a change of component’s state or a change in the environment of system) [160]. An event and its corresponding message are often conflated in literature for convenience. In this dissertation I will use the term “event” to refer to these concepts broadly. A connector is an architectural element tasked with effecting and regulating interactions among components [182]. Although there exist several connector types, in this research, a connector always refers to an event-based distribution connector [182] that distributes events to associated components. In this dissertation, the term “event broker” will be used to refer to this concept broadly. In EBSs, components do not have explicit references to each other and are only able to invoke broker directly [160]. Consequently, addition, removal, and updating of components can be achieved relatively easily during runtime [151]. A component can be an event producer or a consumer, or both. Communication between components is processed via “source” and “sink” [95]: source is an event interface invoked to publish events by a producer component; sink is an event interface that an event broker invokes to transfer an event to a consumer component. When a producer publishes an event, the event broker routes the event to the appropriate consumers based on the system configuration, along with routing and filtering policies [160]. When the event broker transfers an event to a component’s sink, the component consumes the event. Each sink declares an event type and only allows processing of events that match its declared type. In this dissertation, I will target the following three event types commonly used in today’s EBSs [143]: (1) nominal, (2) subject-based and (3) attribute-based. Nominal event types are explicitly declared in a system’s programming 12 language and subsequently enforced at compile-time. In subject-based event typing, each event type is defined through a string value that captures an event’s name. Similar subject-based event types can be organized into naming hierarchies (e.g., Weather/USA/LA). In attribute-based event typing, an event type is defined through a set of attributes, where each attribute is a pair of name and value. Event types can be redefined into more specific event subtypes. 2.1.2 Android Communication Model Android has become one of the most widely adopted mobile operating systems today [3]. Android uses a particular event-based communication model where components that comprise the apps communicate by exchanging events called intents [13]. An intent is a particular type of event that declares a recipient or attributes, and optionally includes data, which is similar to a remote procedure invocation with optional arguments [74]. Android allows intent exchanges between components within a single app (intra-app) as well as across different apps (inter-app) in order to enable apps to leverage each other’s functionalities and data [13]. Intents can be used for explicit or implicit communication [13]. An explicit intent specifies its recipient component, while an implicit intent does not name a recipient component and instead declares attributes, such as action, category, and data type [13]. For example, considering an app that provides the information of popular restaurants, when a user clicks on a restaurant’s street address, the app needs to ask another app to display a map of that location. To complete this operation, the restaurant app can send an explicit intent directly to a specific map app, such as Google Maps, or it can broadcast an implicit intent that would be delivered to any other apps that provide map functionalities (e.g., Bing Maps or Waze). 13 2.1.3 Program Analysis Program analysis is the process of automatically analyzing the behavior of software programs regarding properties such as correctness, robustness, and vulnerability [146]. In general, program analysis is considered to be static when the analysis is performed without executing the software; otherwise, considered to be dynamic [146]. Strictly speaking, this distinction is inaccurate because there exist analysis methods that provide special inputs to software to study their execution, such as symbolic execution [121]. However, in this dissertation, I will follow the general distinction, as the aforementioned particular analysis methods are out of scope for this research. 2.1.4 Visualization Visualization is a widely-used method for understanding software systems as it can transform the raw data generated by the systems into a form which is more intuitive to human comprehension [126]. According to Card et al. [71], visualization is the use of computer-supported, interactive, visual representations of abstract data to amplify cognition. Visualization can help engineers in several ways. Specifically, engineers can more readily understand the system’s overall architecture by studying the visualization than by inspecting the original source code or the raw data [96]. Moreover, visualization can effectively inform engineers of outliers such as security vulnerabilities by highlighting them, which could be costly with raw data [96]. Visualization for security analysis is generally provided in the form of depicting enormous amounts of log data generated at runtime in more efficient and comprehensible ways such as diagrams or graphs [137]. 14 2.2 Event Attacks 2.2.1 Definition Event attacks represent the security problems caused by non-determinism in EBS’s event processing, which engineers and end-users encounter. Event attacks abuse, incapacitate, and damage the system by exploiting event-based communication. Different types of event attacks have been identified throughout various domains, such as mobile apps and web apps [58,67,68,74,83,130,157,163,176, 185,207]. The research to date has identified the following types of event attack in Table 2.1. Table 2.1: Seven Types of Event Attacks Type Name Description A1 Spoofing A malicious component can send an event that spoofs a target component in order to exploit the target’s functionality or data [74]. A2 Interception A malicious component can intercept an event which is supposed to be sent to other components; and can send back inappropriate replies [74]. A3 Eavesdropping A malicious component can eavesdrop an event that contains sensitive data which is supposed to be only open to particular components [130]. A4 Confused deputy A malicious component can indirectly access a target component by accessing the other component which can access the target component [68]. A5 Collusion More than two malicious components can collude to exploit the functionalities or resources of a target component [68]. 15 A6 Flooding A malicious component can send an overwhelming amount of events that makes a target component malfunction [83]. A7 Delaying A malicious component (or event broker) can intentionally delay a series of event interactions to make a target component malfunction [207]. Since event attacks are administered in the same manner as ordinary event exchanges and malicious components disguise themselves as benign, it is hard to block event attacks. Preventing event attacks becomes more challenging especially when it is unable to predict which components will compromise the system (e.g., as is the case in Android and J2EE apps). In this case, since it is hard to guarantee that all components in the system are benign or safe from security threats, existing techniques that require pre-defined access distribution (e.g., role-based access control [62]) cannot be used to prevent event attacks. While Android system was designed to enforce permission-based access control [7], some types of event attacks bypass the permission checks (i.e., confused deputy and collusion [67,68]). Strict limitation on event communication may address some of these security threats, but it can decrease the flexibility of comprising EBS. Although developers are required to follow security policies in building a system, they tend to make mistakes [28]. Practice has also shown that engineers are often completely unaware of potential threats, placing the responsibility on end-users to protect themselves in using the system. 2.2.2 Example of Event Attack: Web Application In this section, I will present a simplified example of event attack which can be launched on an event-based web app. Listing 2.1 and 2.2 illustrate eavesdropping attack. An app App1 follows 16 Listing 2.1: Component Vic in App1 1 public class Vic { 2 ... 3 String s = getSensitiveInfo(); 4 Topic topic = (Topic)ctx.lookup("CustomTopic"); 5 TopicConnection con = factory.createTopicConnection(); 6 TopicSession session = con.createTopicSession(false,Session.AUTO_ACKNOWLEDGE); 7 TopicPublisher publisher = session.createPublisher(topic); 8 Message e1 = session.createMessage(); 9 e1.setJMSType("TextMessage"); 10 e1.setName("ReplyInfo"); 11 e1.setStringProperty("Sensitive", s); 12 publisher.publish(e1); 13 } Listing 2.2: Component Mal in App1 1 public class Mal { 2 ... 3 String m; 4 Topic topic = (Topic)ctx.lookup("CustomTopic"); 5 TopicConnection con = factory.createTopicConnection(); 6 TopicSession session = con.createTopicSession(false,Session.AUTO_ACKNOWLEDGE); 7 TopicSubscriber subscriber = session.createSubscriber(topic); 8 subscriber.setMessageListener(new MessageListener(){ 9 protected void handleMessage(Message e2){ 10 if (e2.getName().equals("ReplyInfo")){ 11 m = e2.getStringProperty("Sensitive"); 12 }}} event-based communication model and is implemented by using Java Message Service [31], a Java MOM platform for message-based communication between components. App1 is corrupted to contain an unintended component Mal (in Listing 2.2) so that event attacks can be launched. Listing 2.1 and 2.2 show where App1’s vulnerability resides. In this app, all events are published through “CustomTopic”. Component Vic in App1 (in Listing 2.1) publishes an event e1 through CustomTopic without any particular protection such as access restrictions. e1 has two attributes— one with the name “Name” (whose value is “ReplyInfo”) and one with the name “StringProperty” (whose value is “Sensitive”)—while containing sensitive information (i.e., s). By listening to 17 “CustomTopic” and declaring attributes “ReplyInfo” and “Sensitive”, Mal can eavesdrop on the event sent from Vic and obtain the sensitive information. As shown in this example, since event attacks appear to be ordinary event interactions, existing malware inspection techniques, especially the techniques that rely on signature-based detection [48, 168,194], may not be able to detect event attacks. Moreover, since publishing and consuming events can be processed via ambiguous interfaces, existing flow-analysis techniques will be unable to accurately analyze implicit invocation between components. Furthermore, since routing event is performed in an essentially invisible and non-deterministic way, it is difficult to expect when and where the event attacks are actually launched. 18 Chapter 3 Approach To resolve the threat of event attacks, this dissertation proposes the four different approaches as follows: 1. A taxonomy for security flaws in EBSs, which can serve as a basis for resolving event attack problems. 2. SEALANT (Security for End-users of Android via Light-weight ANalysis Techniques), a technique that aims to protect Android end-users from event attacks. This solution targets attack types A1-A5. 3. SCUTUM (SeCUrity for evenT-based systems implemented Using MOM platforms), a tech- nique that detects security vulnerabilities that expose the system to event attacks from EBSs implemented by using MOM platforms. This solution targets attack types A1-A5. 4. ViVA (Visualizer for eVent-based Architectures), a visualization technique for inspecting security vulnerabilities in EBS. While this solution primarily targets the attack types A6 and A7, it also help engineers detect other types of event attacks, A1-A5. 19 The rest of this chapter describes my approaches toward solving problems related to the observa- tions and hypotheses that I discussed in Chapter 1. Section 3.1 depicts the taxonomy for security flaws in EBS. Section 3.2, Section 3.3, and Section 3.4 describe SEALANT, SCUTUM, and ViVA, respectively. 20 3.1 A Taxonomy for Security Flaws in Event-Based Systems To secure a software system, developers (or administrators) are required to determine what kinds of security flaws 1 exist in the system, how relatively important each flaw is, and what kind of techniques can be employed to handle each flaw. A security flaw taxonomy—an ordered system that indicates natural relationships of security flaws—can provide a basis for developers to make better decisions in securing their target software system. For the past three decades, many lists and taxonomies of security problems have been studied [50,113,115,116,125,155,173,179,186] for various purposes (e.g., classifying types of attacks [113,116], target systems [50], and flaws per software life cycle [155]). However, despite the prevalence of event-based system (EBS), a security taxonomy for EBSs has not been extensively studied yet. In order to effectively resolve security threats—event attacks in particular—that target EBSs, it is required to have systematic identification and classification of EBS’s fundamental security flaws that may introduce the vulnerabilities into a system. Since EBSs have particular attributes that general software systems do not bear, such as implicit invocation in event communication, the existing lists or taxonomies are not directly applicable to EBSs. 3.1.1 Methodology While EBSs have particular attributes that general software systems do not bear, they can inherit security issues from general software systems. Hence, I decided to build a taxonomy upon the existing taxonomies that targeted general software systems. Firstly, I targeted the taxonomies that classify software security flaws. The advantage of this type of taxonomy lies in the convenience of identifying strategies to remedy security problems, which is the final goal of this research. For example, depending on the type of flaw, developers can 1 A flaw is a defect in a system which can result in a security violation [192]. 21 figure out applicable solutions among those existing and the flaws that lack appropriate solutions. According to the review of security flaw taxonomies [108,111,117], the outdated taxonomies tend to be less elaborative than recently published taxonomies or some of them are adapted to the latest ones [50,125,192]. Thus, among the selected taxonomies, I filtered out the taxonomies published before the year 2000. The taxonomies that only focused on implementation-level errors were also excluded in order to consider design-oriented security flaws. Consequently, a set of candidates remained. Among those candidates, “software security flaw taxonomy” by Weber et al. [192] was selected as a starting point to create a taxonomy. Weber’s taxonomy classifies the flaws based on the genesis (i.e., how they were introduced to the system). Specifically, this taxonomy is distinguished from others due to its major division between “intentional” and “inadvertent” flaws, which is pertinent to classifying security flaws in EBS. Since EBS generally provides an extensible infrastructure, unintended external source code can be included in the system. It implies that a developer’s intention is an important determiner in classifying EBS’s security flaws. For example, although Android framework was not originally designed to contain security flaws, if a malicious Android app, intentionally designed as malicious, is installed on the system, the system will contain “intentional” security flaws. I adapted the Weber’s taxonomy based on a large body of existing work for security issues in EBSs [47,54,55,59,62,70,78,91,142,144,152–154,161,170,174, 175,177,178,180,183,197–199] as well as Android security issues that originated from its event-based communication [49,52,56–58,60,61,68,69,72–75,79,80,82,84,85,85–87,89,90,93,98,100,101,107,109, 114,120,122,130–132,136,147–150,163,165,167,169,171,190,193,195,196,200,202–204,206,208,209,211]. From those publications, I first extracted the security flaws each approach tries to address or introduce as an example. Then I clustered the flaws based on the similarity of ways they can be exploited. 22 Finally, I examined whether each of those flaws is related to its counterpart in Weber’s taxonomy. The detailed process is as follows: According to the existing research [52,56,60,61,68,69,72,73,78–80,84,86,87,98,107,109,120,136, 150,163,169,170,190,200,203,204,208], EBSs may contain malicious code that allows different types of external access, such as malicious url. These types of flaws belong in the same category as “Trapdoor” in Weber’s taxonomy. Prior research defined and introduced a particular concurrency problem which only exists in EBS, referred to as event anomalies [167]. Since Weber’s taxonomy defines “Concurrency” flaws, whichonlyincludedtime-of-checktotime-of-use(TOCTTOU)errors, Iexpanded the scope of their characteristics and changed the name of the category to “Inadequate Concurrency” in order to deliver more precise definition. The existing approaches indicated that components in EBS may communicate via covert (i.e., non-system-standard) communication channels [68,69, 82,165]. Although some types of “Covert Channels” flaws were defined in Weber’s taxonomy, I extended them to include newly identified covert channels such as battery and vibrator in mobile devices. Authentication issues were also identified in EBSs, in the form of permission grant and authentication in multi-domain event based systems [47,69,150,196,203,204,208,211]. I extended “Inadequate Authentication” in Weber’s taxonomy to include those authentication-related flaws. From Android apps, new types of resource leaks such as resource leaks via wifi and SQLite database were introduced [53,55,56,61,62,73,78,89–91,114,144,153,154,163,170,171,190,195,196,209], which can be added to “Resource Leak” in Weber’s taxonomy. I changed the name of the category “Inadequate Resource Management” in order to define broader scope. I also found that the flaws some approaches try to resolve fall under “Logic/Time Bomb” in Weber’s taxonomy [61,73,163]. The existing EBS research introduced the flaws where multiple components are involved colluding to exploit the system [53,56,60,61,68,69,82,84,89–91,148,149,165,170,195,209]. Also, the majority of security 23 attacks in EBS is basically caused by extensible event communication channels of EBS [47,52–58,60, 62,68,69,72,74,82,93,100,101,122,130–132,148,149,152,153,161,170,174,193,195,206,209]. Since Weber’s taxonomy does not include them, I provided extensions of “Conspirator” and “Open Event Channels”, respectively. I also added “Unsafe Events” and “Unsafe Event Interface” considering the cases in which those open event channels are unintentionally introduced to the system [47,52,52,53, 53,54,54,55,55,56,56,57,57,58,58,60,60,62,62,68,69,72,74,74,75,82,85,85,93,93,98,100,101,122,130– 132,144,148,148,149,149,152,152,153,153,154,161,161,170,170,171,174,174,193,193,195,206,209]. Note that to guarantee the completeness of taxonomy, all the flaws extracted from the existing publications were incorporated into a new taxonomy. However, drawing from the flaws in the Weber’s taxonomy, I excluded those that are not introduced in these existing publications in order to build a taxonomy specialized for EBS. 3.1.2 Taxonomy The security flaw taxonomy for EBS is shown in Figure 3.1. Since EBS is a particular type of software system, it incorporates some flaws that general software systems contain. Note that the boxes highlighted in red (F1, F4, F6, F9, F10) indicate the flaws adapted from the existing ones [192] to better reflect a system’s event-based characteristics, and the boxes highlighted in blue (F2, F5, F7, F8) indicate the flaws I added because they are specifically caused by event-based communication. Finally, the green box (F3) indicates the flaw whose definition remains unchanged from the existing one [192]. In particular, the dashed boxes (F2, F5, F6, F7, F8, F10) indicate the flaws that can be exploited by event attacks and represent the focus of this dissertation. It is important to note that every flaw in this taxonomy was validated by existing publications regarding security of EBS and Android [47,49,52,54–58,60–62,68,69,72–75,78–80,82,84,85,85–87,89–91,93,98,100,101,107, 24 Security Flaw Inten0onal Malicious Trapdoor Conspirator Logic / Time Bomb Non-Malicious Covert Channel Open Event Channel Inadvertent Event Communica0on Inadequate Concurrency Unsafe Events Unsafe Event Interfaces System Configura0on Inadequate Authen0ca0on Inadequate Resource Management F1 F2 F3 F6 F7 F8 F4 F5 F9 F10 Figure 3.1: Security Flaw Taxonomy for EBS. The Red boxes indicate the flaws adapted from the original one. The Blue boxes indicate the newly added flaws. The Green box indicates the flaw unchanged from the original one. The circled label indicates the assigned number for each flaw. 109,114,120,122,130–132,136,142,144,147–150,152–154,161,163,165,167,169–171,174,175,177, 178,180,183,190,193,195–200,202–204,206,208,209,211]. In this taxonomy, a software system is defined as a combined system that comprises both application-level and framework-level elements (i.e., middleware) where an operating system is considered as a sub-component of the system. Since the taxonomy considers both design and implementation-level flaws, I will use “developer” as a 25 term that represents both system designer and programmer. Also, a component is defined as an architectural unit that can communicate with each other using system-defined events. The goal of this classification is to provide a basis for deciding which security strategies to use in a particular context. The taxonomy is first divided by a developer’s intention (Intentional and Inadvertent) because different security strategies can be used to reduce each type of flaw. For example, in a target EBS, if most of the security flaws are unintentionally and inadvertently introduced, exhaustive source code reviews and testing can be utilized to reduce the flaws [125]. However, in case when most of the security flaws are intentionally introduced to an EBS, it would be more effective to minimize the proportion of externally-developed source code in the system by restricting access of external components (e.g., restrictive installation of third-party apps on Android system) or by incorporating more trustable MOM platforms. Intentional flaws are classified as Malicious and Non-Malicious. The Malicious flaws indicate the flaws that were deliberately inserted. If any part of system was incorporated from an unreliable source, it might intentionally contain the following flaws: • F1. Trapdoor [52,56,60,61,68,69,72,73,78–80,84,86,87,98,107,109,120,136,150,163,169,170, 190,200,203,204,208]: A system may contain the source code that allows someone to gain illicit access to the system possibly in both application and framework-level. • F2. Conspirator [53,56,60,61,68,69,82,84,89–91,148,149,165,170,195,209]: A system may comprise components that collude to exploit the system functionalities or access sensitive resources. For example, in Android system, a component belonging to an app that can access to Internet and a component belonging to an app that can access contact information could collude to send out the contact information through Internet [68]. Furthermore, a component can help the other component to indirectly access sensitive resources. 26 Non-Malicious flaws are side-effects of features that were deliberately added to the system. In general, developers are not aware of non-malicious flaws, but those are classified as intentional because those were designed into the system by avoidable design decisions. • F4. Covert Channel [68,69,82,165]: Even if two components are not permitted to communicate via system-standard communication channels (e.g., event-based communication), they can communicate through side-effects of operations authorized for them. This can happen either by means of manipulating storage, or by modulating the time which various operations take to perform. As EBSs can be deployed in various environments, such as mobile devices, the types of covert channels are diversified. For example, in Android system, shared hardware resources such as audio volume, vibrator, and battery can be used as a communication channel between malicious components [162]. • F5. Open Event Channel [47,52–58,60,62,68,69,72,74,82,93,100,101,122,130–132,148,149,152, 153,161,170,174,193,195,206,209]: This flaw exists when a component intentionally exposes its event communication channel in order to communicate with other components. Specifically, a component can advertise the type of event it can dispatch or open its event interfaces in order to share its functionality or data with other components. Although it would make a system more scalable and expandable, there always exists a threat where malicious components can exploit the event communication channels in undesirable ways. For example, Android components can dispatch system-defined events to share their functionalities with others, but malicious components can intercept those events and exploit the functionalities [74]. Inadvertent flaws indicate software bugs. Although these can be detected and removed through testing, someflawscanremainundetectedandlatercauseproblemsduringoperationandmaintenance 27 of the system. Inadvertent flaws are classified based on the parts where the flaws reside in. Event- Based Communication flaws represent the flaws that can be caused by the design or implementation of a system’s event-based communication. • F6. Inadequate Concurrency [74,167]: A particular form of concurrency flaw exists in EBS, called event anomalies [167]. In general, EBS’ components randomly process the events that were received simultaneously. Specifically, if two different components simultaneously send the events that can access the same memory location (e.g., a variable containing state or data) of the target component, there is no guarantee that any one of the two events will be processed prior to the other. This flaw may allow spoofed events sent from malicious components to corrupt the victim component’s memory location. • F7. Unsafe Events [52–58,60,62,74,75,85,93,98,100,122,130,132,144,148,149,152–154, 161,170,171,174,193]: This flaw exists when an event containing sensitive information is not appropriately protected. For example, if a component broadcasts an event containing sensitive information without any particular protection, malicious components may intercept or eavesdrop on the event and peek at the sensitive information [74]. • F8. Unsafe Event Interface [47,52–58,60,62,68,69,72,74,82,85,93,101,131,148,149,152,153, 161,170,174,193,195,206,209]: If a component’s event interface has no appropriate filtering in handling received events, the component can be exposed to spoofed events. In case when a component contains sensitive functionalities that can be triggered in response to receiving events through the unsafe interface, a malicious component can inject spoofed events to the exposed event interface thereby causing the target component to malfunction or operate in undesirable ways [74]. 28 System Configuration flaws indicate those that can be caused by a system’s configuration and deployment. • F9. Inadequate Authentication [47,69,150,196,203,204,208,211]: This flaw exists when a system does not completely authenticate each component (e.g., checking whether each component has sufficient permissions to send or receive events). This may allow malicious components to exploit event interactions in the system (e.g., intercepting or corrupting events). Furthermore, in multi-domain EBS, since the system may comprise multiple event brokers from different domains, identification and authentication of components may not be uniform across the event broker networks [53], which may allow unsafe access between components. • F10. Inadequate Resource Management [53,55,56,61,62,73,78,89–91,114,144,153,154,163, 170,171,190,195,196,209]: This flaw is caused when a system allocates some resources to a component and releases them in an untimely manner. For example, if resource allocation is not appropriately designed, a malicious component can monopolize the system resources, which can result in denial of service. Furthermore, inadequate dynamic allocation may lead to convert channels where malicious components can communicate to each other [119]. The remaining flaw in green box indicates the flaw inherited from Weber’s taxonomy [192]: Logic/Time Bomb [61,73,163] flaw indicates a piece of source code designed to disrupt the system when certain conditions are satisfied. 3.1.3 Relationship between Security Flaws and Event Attacks The identified security flaws in EBS can be exploited by different types of attacks including event attack. To effectively counter each type of event attack, which is the final goal of this research, I have 29 identified the relationship between the flaws and event attacks. Then I examined existing solutions that have been proposed to protect the flaws from event attacks. In this section, I formulate each type of event attack, demonstrate the relationship between the flaws and event attacks, and assess existing solutions. As introduced in Section 2.2, event attacks represent the security problems faced by developers or users due to EBS’s non-determinism in event processing. Recall the seven types of event attacks: Spoofing (A1), Interception (A2), Eavesdropping (A3), Confused deputy (A4), Collusion (A5), Flooding (A6), and Delaying (A7). To clearly characterize each type of event attack, I defined a formal characterization for event attacks as follows: C: a set of components V: a victim component M: a malicious component f: sensitive functionality s: sensitive information e: an event x !y: an event communication channel for sending an event from x to y x = )y: an event sent from x to y • A1. Spoofing For V 1 ;V 2 ;M 1 2C where V 1 6=V 2 6=M 1 and9(V 1 e !V 2 ) and (V 2 contains f) and (M 1 e = )V 2 ): M 1 sent a spoofed e to V 2 in order to exploit f in V 2 . • A2. Interception For V 1 ;V 2 ;M 1 2 C where V 1 6= V 2 6= M 1 and9(V 1 e ! V 2 ) and (e contains s) and (V 1 e = ) M 1 )^:(V 1 e = )V 2 ): M 1 intercepted e which supposed to be sent to V 2 in order to obtain s. 30 • A3. Eavesdropping For V 1 ;V 2 ;M 1 2 C where V 1 6= V 2 6= M 1 and9(V 1 e ! V 2 ) and (e contains s) and (V 1 e = ) M 1 )^ (V 1 e = )V 2 ): M 1 eavesdropped on e which supposed to be only open to V 2 in order to obtain s. • A4. Confused deputy For V 1 ;V 2 ;M 1 2C where V 1 6=V 2 6=M 1 and @(M 1 e !V 1 ) and (V 1 contains f) and (M 1 e 1 = ) V 2 )^ (V 2 e 2 = )V 1 ): M 1 accessed V 1 by accessing V 2 which can access V 1 in order to exploit f in V 1. • A5. Collusion For V 1 ;M 1 ;M 2 2 C where V 1 6= M 1 6= M 2 and @(M 1 e ! V 1 ) and (V 1 contains f) and (M 1 e 1 = )M 2 )^ (M 2 e 2 = )V 1 ): M 1 colluded with M 2 which can access V 1 in order to exploit f in V 1. • A6. Flooding ForV 1 ;V 2 ;M 1 2C whereV 1 6=V 2 6=M 1 and9(V 1 e !V 2 ) and (M 1 e = )V 2 )^:(V 1 e = )V 2 )^ (the numberofeisoverwhelminglygreaterthantheaveragenumberofe): M 1 sentanoverwhelming number of e in order to hinder V 1 from accessing V 2 . • A7. Delaying For V 1 ;V 2 ;V 3 ;M 1 2 C where V 1 6= V 2 6= V 3 6= M 1 and9(V 1 e ! M 1 e 1 ! V 2 e 2 ! V 3 ) and (V 1 e = )M 1 e 1 = )V 2 e 2 = )V 3 )^(the time interval between e and e 1 is overwhelmingly higher than the time interval betweene 1 ande 2 ): M 1 delayed publication ofe 1 in order to makeV 2 andV 3 malfunction. Each security flaw in EBS can be exploited by different types of event attacks as depicted in Table 3.1. To protect each type of security flaw from event attacks, various solutions have 31 Table 3.1: EBS Security Flaws, Event Attacks, and Existing Solutions Security Flaw in EBS Event Attacks Existing Solutions F1.Trapdoor - - F2.Conspirator A5 Detection of information leaks [57,130], Detection and control of collude apps [68] F4.Covert Channel - - F5.Open Event Channel A1-7 Encryption of events [153], Policy enforcement [57,68,174] F6.Inadequate Concurrency A1 Detection of event anomalies [167] F7.Unsafe Events A2,3,7 Role-based access control [53,62], Encryption of events [153], Detection of vulnerable components [56,57,74], Policy enforcement [57,68,174] F8.Unsafe Event Interfaces A1,4,6 Role-based access control [53,62], Detection of vulnerable components [56,57,74], Policy enforcement [57,68,174] F9.Inadequate Authentication A1-7 Security policy validation [62,158] F10.Inadequate Resource Management A6, A7 Analysis of runtime events and resources [127,172] been studied throughout different EBS platforms (e.g., OASIS [55] and Android [24]). Table 3.1 also presents the representative solutions that protect each security flaw from the corresponding event attacks. As indicated in Table 3.1, neither security flaws F1 nor F4 are the target of event attacks. They can be resolved by general security solutions such as a signature-based detection [48,168,194] or an identification of covert channels [68]. The flaw F2 can be exploited by the attack A5, but the threat can be minimized by detecting sensitive information flows between components [57,130] or controlling unsafe event communication between components [67,68]. The flaw F5 can be exploited by multiple types of event attacks (A1-7). Existing research tried to minimize the threats using encryption of events, but it requires “safe” key distribution between components and additional resources that may be a burden to particular environments (e.g., mobile devices) [153]. While 32 enforcing security policies [57,68,174] has also been proposed, a coarse-grained policy may fail to prevent event attacks. For the flaw F6, which is vulnerable to the attack A1, a static analysis for event anomalies detection [167] can help developers identify and fix the flaw. The flaw F7 can be a target of the attacks A2, A3, and A7. Although role-based access control and encryption of events [53,62,153] may prevent the attacks, those techniques require certain assumptions about the components engaged in event-based interactions, namely, they assume that “benign” components will be known. In other words, these approaches cannot properly deal with event-related security threats when the types of components are not clearly delineated and a malicious component can behave as a legitimate component. Though existing research has focused on the detection of the attacks A2 and A3 in Android apps [56,57,74], they either target limited types of attacks or do not provide actual prevention mechanisms. The flaw F8, which is vulnerable to the attacks A1, A4, and A6, can be resolved by the same solutions as the flaw F7. The flaw F9 is exposed to all types of event attacks, because the possibility of malicious component’s existence in a system can be increased if the system’s authentication mechanism is not well-defined. This threat can be minimized by validating a system’s security policies [62,158]. The flaw F10, which is vulnerable to the attacks A6 and A7, can be covered by analyzing and monitoring a system’s runtime event interactions or resource usages [127,172]. Overall, existing solutions have limitations in detecting flaws and preventing event attacks. Since the prevention-type solutions are based on the assumption that the types of components are clearly delineated, they can be coarse-grained in case it is unclear to pinpoint the benign components. Although detection-type solutions provide relatively finer-grained results in identifying the flaws vulnerable to event attacks, they suffer from inaccuracy and scalability issues in their analysis. 33 3.2 SEALANT Contemporary mobile computing devices store private information of the users ranging from phone numbers and addresses to highly sensitive information such as banking credentials. Although mobile operating systems (OSs) implement various security measures to protect user information from attackers, many of the OSs still suffer from known security vulnerabilities. As Android also bears the same problems [2], it is important to examine this issue for the following reasons. First, Android is the most widely used mobile OS today [12]. Second, Android provides a native development framework in addition to the base OS services, in the process also raising the OS-level vulnerabilities to the level of application (app) development. Third, it follows event-based communication model which is vulnerable to event attacks. I target a well-known vulnerability residing in the design of Android’s communication model [2], in whichcomponentsinasingleapporacrossmultipleappscommunicatebyexchangingaparticulartype of event, called intent (see Section 2.1.2). As depicted in Section 1.1, inter-component communication (ICC) via intent exchange can expose a vulnerable surface to several types of event attacks (referred to as “inter-app attacks” in Android domain, thereby using the same term in this section), including intent spoofing [74], unauthorized intent receipt [74], and privilege escalation [67], corresponding to event attack A1, A2-3, and A4-A5, respectively. Different versions of Android have not provided framework-level protection from those attacks to date, but have expected developers to do so at the app-level. This exposes end-users to the risk of attacks, yet most users will be unable to distinguish malicious from benign behaviors because a malicious app sends and receives intents in a way that appears as if those are ordinary intent exchanges. For example, a malicious app can eavesdrop on the data carried in a broadcast intent (unauthorized intent receipt) without interrupting the broadcast. It is hard for an end-user to detect such a passive attack and recognize when the attacks 34 are actually committed. An app developer’s caution may minimize the risk of the attacks, but it requires error-prone manual effort, while end-users may still download other unsafe apps. Although security violations such as these have been studied in computer networks and distributed systems [62,91,153,170,178,183], those techniques cannot be directly applied to Android due to the specificsofitscommunicationmechanismandfeatures. Forexample, role-basedaccesscontrol[62,170] has been applied in Android as a form of permission grants; however, it can be violated by privilege escalation attacks. Encryption [153,178], another popular technique, is not a good fit for Android due to encryption-key distribution issues and limited mobile resources. Meanwhile, techniques specifically targeting Android have either not focused on these issues or have been unable to adequately resolve them. Specifically, a large volume of research has focused on ICC vulnerabilities in Android [56,68,69,74,82,122,130,133,149,150,163,193]. However, existing detection techniques target only certain types of inter-app attacks [58,122,130,193] and/or do not support compositional analysis of multiple apps [74,133,149]. The state-of-the-art techniques [58,122,130] employ data-flow analyses that rely on lists of frequently used Android API methods [164], but tend to overlook ICC vulnerabilities caused by custom methods. Moreover, these analyses [122,130,193] have been shown to experience scalability problems when applied on large numbers of apps [57]. Meanwhile, the runtime protection techniques suffer from acknowledged frequent “false alarms” [58,68] because of the coarse granularity at which they capture ICC information. Additionally, these techniques assume a degree of expertise in Android security [68,82,150,163]. While certain techniques [57,58] combine vulnerability detection with runtime protection to aid ordinary end-users, they also suffer from potentially large numbers of false alarms. 35 3.2.1 Design To overcome the challenges and the shortcomings of the existing approaches, I designed SEALANT (Security for End-users of Android via Light-weight ANalysis Techniques), a technique that aims to enable ordinary end-users to protect against all of the aforementioned inter-app attacks. SEALANT identifies vulnerable ICC paths between a given set of apps, inspects each intent sent via those paths at runtime to detect potential attacks, and enables end-users to block the intent on-the-fly. SEALANT is distinguished from the existing research because (1) it simultaneously prevents multiple types of Android inter-app attacks—with the current implementation focusing on intent spoofing, unauthorized intent receipt, and privilege escalation, (2) it extends the detection coverage via a novel combination of static data-flow analysis and compositional ICC pattern matching, (3) it causes fewer false alarms than existing techniques through a finer-grained characterization of ICCs, (4) it supports compositional analysis scaling to a number of apps, and (5) it integrates static detection with runtime monitoring and control of vulnerable ICC paths. Note that I made two assumptions in order to manage the scope of this research. First, the bundled apps that come with a factory-setting Android device are not malicious. Second, I did not consider other unorthodox channels of inter-app communication that do not use intents such as file locks (as in [68]), sockets, or the file system (as in [69]). 3.2.1.1 Overview SEALANT recognizes each instance of ICC as a relation between a sender, a receiver, and an intent. When an intent from a sender component matches an intent that can be received by a receiver component (either explicitly or through an intent filter), SEALANT reports an ICC relation. SEALANT builds an ICC graph in which vertices are components and edges are the ICC relations. 36 End-user “ Analyzer” “Interceptor” App#1 App#2 App#3 Application Layer Framework Layer . . . *.APK SEALANT Component Modified Android Component 2. 4. 6. 5. 1. 3. SEALANT List ActivityManager End-user’s device Figure 3.2: Overview of SEALANT’s Operation It then extracts all possible vulnerable ICC paths in the ICC graph and monitors them at runtime. When an instance of ICC matches one of the extracted vulnerable paths, SEALANT may block it based on the user’s choice. SEALANT comprises two key components as depicted in Figure 3.2: (1) Analyzer uses static analysis to generate a list of vulnerable ICC paths between apps, and runs on a user’s computer or as an online service; (2) Interceptor extends Android to perform runtime monitoring and enable advanced ICC control such as blocking of specific ICCs identified by Analyzer. Together, these components enable an end-user to either allow or block the inter-app intents sent via vulnerable ICC paths on-the-fly. In developing SEALANT (in particular, its Interceptor), I elected to modify Android over two other alternatives—instrumenting the installed apps’ bytecode and acquiring 37 administrator privileges, i.e., “rooting”—because (1) once my approach is applied to a device, it does not require altering any of the installed apps, and (2) rooting itself is undesirable as it introduces serious vulnerabilities [14]. SEALANT’s overall process is as follows (see Figure 3.2): 1. Analyzer processes the APK 2 files of the installed apps and identifies the vulnerable ICC paths between them. 2. Analyzer can optionally contact expert users to confirm specific vulnerable paths that should be monitored. 3. Analyzer feeds the highlighted vulnerable ICC paths to the Interceptor in a pre-defined format (SEALANT List). 4. Atruntime, wheneveranintentissent, Interceptor capturestheinformationofthecorresponding ICC path (e.g., sender’s name) from Android’s ActivityManager. 3 5. If the captured path information matches one of the vulnerable paths in the SEALANT List, Interceptor contacts the end-user to determine whether to propagate the intent. 6. Based on the end-user’s choice, Interceptor will instruct the ActivityManager either to block or to route the intent. 3.2.1.2 Analyzer Analyzer performs static analysis on APK files in four phases as depicted in Figure 3.3: (1) analyze target apps, (2) build ICC graph, (3) find vulnerable paths, and (4) generate SEALANT List. 2 APK is an archive file format that distributes and installs Android apps. 3 ActivityManager is the Android component that governs ICC. 38 . . . App#1.APK App#2.APK App#3.APK SEALANT List Analyze Target Apps Find Vulnerable Paths Generate SEALANT List Build ICC Graph Figure 3.3: An Operational Process of Analyzer Analyzer is novel in that it returns multiple types of vulnerable ICC paths in a single pass and distinguishes different types of threats, which enables tailor-made countermeasures. It does so by focusing, both, on the data-flow between components and on compositional patterns of ICCs derived from published literature [74]. This enables Analyzer to identify a larger number of vulnerable paths and path types than existing techniques (e.g., paths involving custom methods). Its summary-based model enables analyzing a number of apps at a time, as well as reusing prior analysis results when apps are installed, updated, or removed. (1) Analyze Target Apps. Analyzer extracts and summarizes each app’s architectural information by analyzing the APK file. The summary includes components, intents, intent filters, and permissions. Analyzer extracts each component’s name, package, permissions held or required, and exported status. To communicate across apps, an Android component must have its exported status set to true or contain an intent filter. Analyzer only considers exported components in creating ICC graphs. Note that a component can receive intents from other apps, only if its exported attribute is set or contains at least one intent filter. Analyzer extracts each intent’s attributes (i.e., target component, action, categories, and data) using string constant propagation [95] in order 39 to determine string values at statements. If an attribute’s value cannot be determined, Analyzer conservatively assumes it to be any string. Once extraction is completed, Analyzer examines each component’s vulnerability. A vulnerable component is the one containing an intra-component path between an ICC call method and a sensitive method. An ICC call method is a standard Android method for sending or receiving intents (e.g., startActivity()) [24]. A sensitive method is an Android API method that can access sensitive user information (e.g., getLastKnownLocation()) or trigger a sensitive operation (e.g., sendTextMessage()) [51,164]. Analyzer identifies the relevant paths by employing a static taint analysis that tracks data-flows between methods [49]. If the direction of an intra-component path is from an ICC call method to a sensitive method, Analyzer sets the component’s vulnerability type to Active, because the component is vulnerable to attacks such as intent spoofing and privilege escalation. If the intra-component path is from a sensitive method to an ICC call method, the vulnerability type is Passive, representing attacks such as unauthorized intent receipt. If a component has no intra-component path between a sensitive method and an ICC call method, its vulnerability type is set to null. In Figure 1.1(b), for example, the vulnerability type of V3 is Passive, because the location data directs from getLastKnownLocation() to sendBroadcast(). If a component has multiple intra-component paths, Analyzer creates separate component models for each path. By managing a summary-based model of each app, Analyzer is scalable to inspecting a number of apps in a single pass, as evaluated in Section 4.1.3.1. Furthermore, when apps are installed or updated subsequent to running Analyzer, Analyzer extracts only the architectural information from the newly updated apps and reuses the prior analysis results on the rest. (2) Build ICC Graph. With the extracted information, Analyzer builds an ICC graph based on the rules from Android’s API reference documentation [13]. It defines an edge as a tuple <s, r, 40 Table 3.2: Attributes of component and intent in ICC graph Entity Attributes Description component Name The name of the component Pkg The name of the package to which the component belongs VulType The type of vulnerability (i.e., Active, Passive, or null) VulMeth The name of the sensitive method (e.g., sendTextMessage()) PermUse The name of the permission that the component holds PermReq The name of the required permission to access the component intent Target The name of the component to which the intent is directed IntentAttr The intent’s attributes: action, category, data type, and data scheme Sender The name of the component which sends the intent SenderPkg The name of the package to which the sender component belongs i>, where s is a sender and r a receiver component, and i is an intent between them. Component and intent are entities that manage summarized information as shown in Table 3.2. Since the extraction of architectural information is performed in a conservative way (specifically, relying on attributes of intents), the set of edges may include false positives. However, this will not affect SEALANT’s runtime accuracy because no ICC instances to be routed via those edges will ever be initiated. (3) Find Vulnerable Paths. Analyzer implements Algorithm 1 on the ICC graph to identify vulnerable paths. Analyzer marks an edge as vulnerable (1) if it has a vulnerable component at one or both ends, or (2) if it forms a particular compositional pattern. To find vulnerable transitive ICC paths, Analyzer recursively identifies a set of connected edges that can access a vulnerable component by calling the PathFinder method (Algorithm 2). x y indicates attribute y of entity x (see Table 3.2), and x:y represents element y in edge x. 41 Algorithm 1: Identifying vulnerable ICC paths Input: G ( an ICC graph Output: VulPaths ( a set of vulnerable paths 1 Let IAC be a set of IAC edges in G 2 Let ICC be a set of ICC edges in G 3 Let s be a sender component 4 Let r be a receiver component 5 foreach e2IAC[ICC do 6 s ( e:sender 7 r ( e:receiver 8 if (r VulType = \Active") then 9 if e2IAC then 10 add (feg;PermCompare(s;r;r VulMeth )) to VulPaths 11 PathFinder(s;r;feg) 12 else if (s VulType = \Passive") and (e2IAC) then 13 add (feg; \unauthorized intent receipt") to VulPaths 14 else if (e2IAC) then 15 foreach (g2ICC) do 16 if (r =g:receiver) then 17 add (feg; \intent spoofing") to VulPaths 18 else if (s =g:sender)^ (e:intent =g:intent) then 19 add (feg; \unauthorized intent receipt") to VulPaths Algorithm 2: PathFinder Input: s;r ( component, E ( a list of distinct edges Output: updated VulPaths 1 foreach f2IAC[ ICC do 2 if (f:receiver =s) and (8e2E, e:receiver6=f:sender) then 3 append f to E 4 if (9e2E;e2IAC) then 5 add (E;PermCompare(f:sender;r;r VulMeth )) to VulPaths 6 PathFinder(f:sender;r;E) 7 remove the last element of E Analyzer first parses edges into two sets: inter-app (IAC) for edges between components belonging to different apps, and inter-component (ICC) otherwise. Algorithm 1 iterates over each edge e in IAC[ICC (lines 5-19) and considers four different cases that cover all types of vulnerable paths I 42 target in this research: the first two cases identify paths that involve vulnerable components; the latter two cases identify paths based on previously identified compositional patterns [74]. Case 1 (line 8) occurs when e directs to a receiver vertex whose vulnerability type is \Active". If e is an IAC edge, Algorithm 1 determines the type of attack by calling PermCompare(c 1 ;c 2 ;m) (line 10), a method that returns the type of attack by comparing the permissions of components c 1 and c 2 , where m is a sensitive method that forms an intra-component path with an ICC call method within c 2 . If c 2 holds a permission that c 1 does not, and the permission is required to use m [51], PermCompare returns “privilege escalation”; otherwise, it returns “intent spoofing”. Once the type of attack is determined, Algorithm 1 addsfeg to the set VulPaths that contains all detected vulnerable ICC paths (line 10), and then calls PathFinder to identify transitive ICC paths (line 11). As depicted in Algorithm 2, PathFinder iterates over each edge f2IAC[ICC, to check if f connects to the previously identified edge’s sender component s, and if f’s own sender is a newly visited component (line 2). If so, PathFinder appends f to the list of distinct connected edges E (line 3). If E contains an inter-app edge (e2IAC), PathFinder determines the type of attack by calling PermCompare, and adds E to VulPaths (line 5). PathFinder recursively identifies other components that are connected to a vulnerable component through edges in the ICC graph. It stops its processing when it visits all transitively connected components to the original edge’s receiver r or reaches an already visited component. When it finishes iterating, PathFinder removes the last element from E to enable correct exploration of additional transitive paths. Case 2 (lines 12-13 in Algorithm 1) deals with the situation when the vulnerability of e:sender is Passive ande2IAC, which may result in leaking sensitive information between apps through e. If so, the type of attack is set to “unauthorized intent receipt” andfeg is added to VulPaths (line 13). 43 Case 3 (lines 14-17) occurs when edges e2IAC and g2ICC (e6=g) both lead to the same receiver vertex. It represents a pattern of attack in which g is an intended access within an app, but e can be an unintended access from a malicious component across apps. In this case, the type of attack is set to “intent spoofing” and the edgefeg is added to VulPaths (line 17). Case 4 (lines 18-19) occurs when edgese andg share the same sender and intent. If g represents an originally intended receipt within the app and e an unintended receipt across apps, Algorithm 1 will set the type of attack to “unauthorized intent receipt” and appendfeg to VulPaths (line 19). (4) Generate SEALANT List. As the last step, Analyzer generates the SEALANT List based onVulPaths, the output from the previous phase. Analyzer first normalizes the output by checking for redundant paths. It then transforms the information about identified paths into a pre-defined format that is compatible with SEALANT’s Interceptor component. The SEALANT List contains two types of information: (1) independent vulnerable ICC paths, each of which comprises information about two components and an intent that connects them, and (2) independent vulnerable transitive ICC paths, each of which comprises multiple ICC paths listed in the order of their connection in the ICC graph. 3.2.1.3 Interceptor Interceptor monitors and analyzes each instance of ICC. Whenever an ICC is requested, Interceptor checks whether it is specified in the SEALANT List. Interceptor’s ICC control strategy is distin- guished from competing techniques due to its finer-grained characterization of ICC paths based on (1) sender, (2) receiver, and (3) intent. As evaluated in Sections 4.1.1.3 and 4.1.2, this increases the accuracy in blocking ICCs. 44 MalApp1 Component M1 { … startActivity(intent i) … Application Layer Framework Layer intent i from “who” send “what” to “whom” Component V2 { … onStart(){ … End-user Block intent i Interceptor Component Modified Android Component VicApp1 ListProvider 2. 3. 5. 1. 4. 6. ChoiceDatabase Blocker Class Activity … startActivity(intent i) … ActivityManager 1. Figure 3.4: The Architecture and Operation of Interceptor Interceptor resolves two challenging issues: (1) extracting each component’s information at runtime to effectively prevent malicious ICCs, while (2) minimizing the impact on Android’s functionality. Interceptor captures a sender component’s information by instrumenting the framework- level class of each type of component (e.g., Activity) in the Android framework, while it captures an intent’s and a receiver’s information by extending a core component that governs intent routing (i.e., ActivityManager). Interceptor minimizes the impact on Android by avoiding removal of standard components or modification of core methods (further discussed in Sections 3.2.2 and 4.1.3.2). Architecture. Interceptor extends the Android framework with four components, as depicted in Figure 3.4. Three components—Blocker, ChoiceDatabase, and ListProvider—are newly added, while one—ActivityManager—is a modification of an existing Android component. 45 • Blocker interacts with end-users and performs Interceptor’s core functionalities: monitoring, matching, and blocking. Blocker directly communicates with ActivityManager to obtain the detailed information of each instance of ICC, and to possibly induce ActivityManager to block a particular instance of ICC. Blocker imports the SEALANT List from ListProvider, and refers to the previously made choices from ChoiceDatabase. • ActivityManager controls every instance of ICC processed through the Android framework, by collaborating with other Android components (e.g., PackageManager). I extended Activity- Manager to capture the information of each ICC instance (sender and receiver components, and intent’s attributes), share the information with Blocker, and block a particular instance of ICC upon Blocker’s request. • ChoiceDatabase stores end-user choices (to block or route) for each vulnerable ICC path. Stored choices are automatically applied when the same ICC is requested, and can be removed upon end-user’s request. When a new SEALANT List is imported, ChoiceDatabase expunges only the choices that correspond to the updated or removed apps. • ListProvider imports and maintains the SEALANT List. When a SEALANT List is installed in the pre-defined space of the user device (e.g., external SD card), ListProvider imports it and maintains the specified information as a permanent condition until a new SEALANT List is introduced. Operation. Figure 3.4 illustrates the interaction among Interceptor’s four components. For clarity, the depicted six-step scenario is based on the example from Listings 1 and 2, but it is reflective of Interceptor’s operation in general. 46 1. When M1 of MalApp1 tries to send intent i by calling startActivity(), request is routed to ActivityManager. 2. ActivityManager extracts sender’s (i.e., M1’s) information and searches for components permit- ted to receive intent i. If a receiver is identified (i.e., V2 of VicApp1), ActivityManager passes the ICC information to Blocker. 3. After receiving information about the ICC, Blocker first examines ChoiceDatabase. If a choice for the ICC already exists, Blocker induces ActivityManager to act (block or route the ICC) without engaging the end-user. 4. In case no corresponding choice exists in ChoiceDatabase, Blocker scans the SEALANT List provided by ListProvider. 5. If the information about the requested ICC matches that in the SEALANT List, Blocker will give the user four options: (1) allow the ICC once, (2) block it once, (3) allow it always, and (4) block it always. If the user selects options (3) or (4), her choice will be stored in ChoiceDatabase. 6. If the end-user chooses to allow (resp. block) the requested ICC, Blocker will instruct ActivityManager to send intent i to V2 (resp. trap it). Interceptor’s Strategy for Blocking ICCs. Interceptor is engaged between the times when an intent is first requested and when it is actually dispatched to its destination. Interceptor’s operation may thus cause a delay in processing intents, which may be exacerbated by the number of vulnerable ICC paths in the SEALANT List. However, since Android’s ICC is performed via asynchronous API calls, I hypothesize that this delay will not significantly impact the system’s operation. In Section 4.1.3.2, I empirically evaluated Interceptor’s performance overhead. 47 In case when an end-user has blocked a requested ICC, the apps that are involved in the ICC will not get any response to their request back from the framework. Since Android implements ICCs asynchronously, those apps will simply “skip” the corresponding operation without causing runtime crashes. To block a vulnerable transitive ICC, Interceptor begins by matching the first path of the vulnerable transitive ICC path and setting its transitive_flag to true. This flag is managed per each vulnerable transitive ICC path and remains true as long as the subsequently requested ICCs match the subsequent paths in the vulnerable transitive path. Once the last path of the vulnerable transitive ICC path is reached, Interceptor alerts the end-user and resets transitive_flag to false. In the example from Figure 1.1(c), let us assume that the vulnerable transitive ICC path M3! V8! V6 is in the SEALANT List. If M3 launches V8 via an intent, Interceptor will set transitive_flag to true. Then, if V8 launches V6 via an intent, Interceptor will alert the user and reset the flag. 3.2.2 Implementation I have implemented SEALANT’s Analyzer as a stand-alone Java application that receives as input a set of Android apps in APK files, and exports a SEALANT List in the pre-defined XML format. Analyzer’s implementation combines approximately 3,000 newly written SLOC with three off-the- shelf tools. The tools are used in the first of Analyzer’s four phases (recall Section 3.2.1.2). Analyzer integrates two static analysis tools, IC3 [147] and COVERT [56], to extract architectural objects from apps. I employed both tools because neither of them alone discovers all of the needed information: IC3 misses outbound intents in certain scenarios [147], while COVERT only returns coarse-grained intent information that excludes certain attributes (e.g., data type) [56]. Analyzer orchestrates 48 the two tools together and combines their outputs in order to generate a more complete list of architectural objects. In identifying intra-component paths between ICC call methods and sensitive methods, Analyzer uses FlowDroid [49], a highly precise intra-component taint analysis tool for Android. I implemented SEALANT’s Interceptor on top of Android Open Source Project (AOSP) 4.4.4 KitKat[7], whichisthemostpopularversionofAndroid[27]today. Idirectlymodifiedthesourcecode of several standard Android components including ActivityManagerService, ActivityManagerNative, and IntentFirewall. In total, I introduced about 600 SLOC spread over 10 classes. To minimize the impact on the original functionality of Android, I did not remove any standard components or methods. Our modification was limited to parts of Android that are usually a layer beneath manufacturers’ customizations, and can easily be applied to Android versions 4.4 and later without significant changes. I was able to successfully run Interceptor’s system image, both, on the Android emulator [19] and on a Google Nexus 7 device. Since framework-level components in Android do not provide a user interface (UI), I also implemented an Android app that provides a UI to perform (1) pushing the SEALANT List from an external SD card to Interceptor’s ListProvider, (2) removing the list from ListProvider, and (3) removing previous choices from Interceptor’s ChoiceDatabase. Running SEALANT requires compiling Interceptor’s source code with the provided drivers, and installing the image files using the freely available Android debug bridge [6] and Fastboot [20]. This cost can be minimized by bundling SEALANT with Android. SEALANT’s code, required drivers, and compiled tools are available at http://softarch.usc.edu/sealant/. 49 3.3 SCUTUM Event-based systems (EBSs) implemented by using MOM platforms are widely used. They are implemented in various types of systems such as web apps or SOA-based systems [112,141] by using different types of MOM platforms such as Java Message Service [31], Siena [32], CORBA [34], c2.fw [138], and Prism-MW [135]. However, as shown in Section 2.2.2, those systems can be exposed to the risk of event attacks. For example, a user may use a corrupted EBS which contains malicious components, or a developer may build an EBS by utilizing externally developed components that are actually malicious. For those cases, malicious components can launch unintended behaviors through event communication, such as eavesdropping on sensitive information or exploiting the system’s functionalities. Existing program inspection techniques neither focus on event attacks nor correctly detect vulnerabilities across components [40,43,48,168,194]. Specifically, existing vulnerable-flow analysis techniques do not support implicit invocation between components and are not scalable to analyzing systems comprising large numbers of components [40,43,130]. While a large body of research has studied detecting vulnerabilities that expose Android apps to event attacks [56,74,93,122,130, 133,150,163,190,200], they cannot be directly applied to other EBSs, because Android uses its system-specific communication model, APIs, and component life-cycles. 3.3.1 Design To overcome aforementioned challenges and the shortcomings of the existing approaches, I designed SCUTUM (SeCUrity for evenT-based systems implemented Using MOM platforms), a technique that automatically detects target EBS’s vulnerabilities that expose the system to event attacks (types A1-A5). SCUTUM is an instantiation of generalized Analyzer’s technique, a static analysis 50 module of SEALANT. Specifically, SCUTUM is based on the generalized version of Analyzer’s flow-analysis and pattern matching (introduced in Section 3.2.1.2), which can be applicable to EBSs implemented by using MOM platforms. Like Analyzer, SCUTUM statically identifies vulnerable event communication channels by examining control-/data-flow across components as well as event communication patterns between components. SCUTUM basically adapts Analyzer by considering three main challenges as follows: • Ambiguous event communication channels: EBS’s inherent attributes hamper the ex- traction of event communication channels via which events are exchanged between components. Specifically, implicit invocation between components makes it difficult to determine where each event will flow into, and EBS’s event interfaces do not explicitly reveal the events to be consumed. Furthermore, depending on the types of MOM platform, different event interfaces can be used. To handle this, SCUTUM leverages Eos [95], a technique that statically extracts event types and their attributes based on the characteristics of underlying MOM platform. • Scalableflowanalysis: Tocheckwhethersensitivedataleaksorunintendedaccesstosensitive functionality can be launched, control-/data-flow analysis on methods in each component is required. However, in case when an EBS comprises a large number of components and methods, flow analysis on every method in the EBS may not be scalable. According to Safi et al. [167], on average, EBSs contain over 35 methods to be analyzed, which could consume hours for a real-world EBS. Although several flow-analysis techniques have been proposed for Android apps [49,56,58,130], considering the fact that mobile platforms limit the size of apps [35], those techniques may not scale well with large-scale EBSs containing methods with larger size and higher complexity. SCUTUM provides a size reduction algorithm which enables SCUTUM’s analysis to scale well with identifying vulnerabilities from large-scale EBSs. 51 Sensitive APIs System Implementation System Con3iguration Search Sensitive Methods Extract PETs/CETs Sensitive Components A Set of PETs/CETs Boundary Components Build Event Flow Graph Prune Event Flow Graph Reduced Event Flow Graph Vulnerability Flow Analysis Vulnerable Event Channels Extraction Reduction Identi3ication Vulnerability Pattern Analysis Figure 3.5: An Operational Process of SCUTUM • Inconstant distinction of components. Event attacks are launched across the components that have different trust level. Although Android uses a consistent mechanism for distinguishing among the trust levels of app components (i.e., each “app” has different trust level), other EBSs may use different types of distinction depending on their system configuration. For example, the trust level of externally-developed components can be different from that of component developed in-house. To handle this, SCUTUM introduces the concept of trust boundaries. A trust boundary is defined as a unit for dividing components based on each component’s trust level. Components that have the same trust level belong to the same trust boundary, and a trust boundary can be set per each component as well as a group of components. 52 SCUTUM operates in three distinct phases—Extraction, Reduction, and Identification— as depicted in Figure 3.5. The inputs to SCUTUM are the target EBS’s (1) implementation, (2) configuration, and (3) sensitive APIs. The configuration includes the information regarding the underlying MOM platform (i.e., the methods for event communication and the base class for events) and trust boundaries. The information of underlying MOM platform can be derived from the API specification of the platform, which only needs to be identified once per platform. Regarding some of the existing platforms, such information has been already derived to be publicly accessible [95,167]. Trust boundaries can be easily derived by clustering components based on a developer’s trust level regarding each component. While prior work has categorized a set of sensitive Android APIs, the set is not equally valid in other MOM platforms. In addition, there is no complete set for those platforms. Accordingly, SCUTUM requires a set of sensitive APIs as an input. While this relies on the expectation that developers can provide this input accurately, identifying this input is fairly straightforward to them because so far as the components developed in-house are concerned, they might know particular APIs that handle important data or sensitive functionalities. Furthermore, even if a developer is not fully knowledgeable about the sensitive APIs in the target system, she can refer to the existing sets of APIs [23] which are generally considered as sensitive. According to the results of evaluation in Section 4.2.2, SCUTUM’s analysis, relying on setter and getter methods which are generally considered as sensitive, indicated a fairly high precision (=85.67%) in identifying vulnerabilities. In the remainder of this section, I will discuss each of the three phases in detail. Extraction. In this phase, SCUTUM inspects target system’s implementation and extracts two types of information that will be used in the later phases: (1) The first type includes published event types (PET) and consumed event types (CET) accessed by each component, which can be used to infer event communication channels between components [95,167]. To this end, SCUTUM 53 Boundary Component Sensitive Component Component Intra-Boundary Event Communication Channel Inter-Boundary Event Communication Channel a b c d e f OB OB & IB OB & IB IB s1 s2 c1 c2 c1 c3 c1 Boundary_1 c4 b1 b3 b2 b4 Figure 3.6: An Event Flow Graph leverages Eos [95,167]. Eos performs static analysis on the target system’s implementation to provide ingredients SCUTUM uses in subsequent analysis: every component’s PET and CET along with corresponding attributes from the system implementation. In Listing 2.1, an example of PET published at line 12 isf(Name : \ReplyInfo"); (StringProperty : \Sensitive")g; (2) The second type of information is the location where each sensitive API is accessed or called. For each method in a given list of sensitive APIs, SCUTUM identifies the component where the method is called along with its location in the system implementation. Reduction. To identify vulnerable event communication channels, SCUTUM considers both inter- and intra-component flows by combining the extracted event types with each component’s control-flow graph (CFG). However, for a large-scale EBS, generating and traversing every compo- nent’s CFG may not be scalable. To address this, SCUTUM builds an event flow graph (EFG), which provides a macro perspective of target EBS (see Figure 3.6), and examines the EFG to prune the components that are unnecessary for subsequent analyses. 54 In an EFG, components are connected by the edges that represent event communication channels between pairs of components. An edge is determined by matching PET and CET, while having a direction to which an event is being sent. For the component where a sensitive API is called, SCUTUM checks if its sensitive API is reachable from or to its event interfaces—consuming event interface (CEI) and publishing event interface (PEI)—via its call graph (CG). If yes, SCUTUM labels the component as a sensitive component (see Figure 3.6). SCUTUM also labels the components that form an event communication channel across trust boundaries as boundary components. If a boundary component’s PEI for event communication across trust boundaries is reachable from its CEI or sensitive API via CG, SCUTUM sets its attribute as outflow-boundary (OB). Conversely, if its CEI for event communication across trust boundaries is reachable to its PEI or sensitive API via CG, its attribute is set to be inflow-boundary (IB). SCUTUM then prunes the components that are not associated with vulnerable event communi- cation by implementing Algorithm 3 on EFG. For example, in Figure 3.6, component s1 publishes two different types of events (i.e., a and c) each of which initiates different subsequent event com- munication (i.e., b and d-e, respectively). Considering the fact that event attacks exploit (1) event communication across trust boundaries and (2) event communication that flows into or from sensitive APIs, event communication channels for c, d, and e are not essentially vulnerable to event attacks, because they are not involved in the event communication across trust boundaries. Thus, SCUTUM removes the components that are connected with those event channels (i.e., components c1, c2, and c3) from EFG in order to reduce the overhead in subsequent flow analyses. As evaluated in Section 4.2.3, SCUTUM’s pruning operation increases its scalability in analyzing large-scale EBSs. Algorithm 3 iterates over each component c in G (lines 5-9) and considers two different cases in which each set of consecutive event communication channels (i.e., a set of connected edges) 55 Algorithm 3: Pruning Event Flow Graph Input: G ( an EFG Output: ReducedG ( a reduced EFG 1 Let S G be a set of sensitive components in G 2 Let OB G be a set of outflow-boundary components in G 3 Let IB G be a set of inflow-boundary components in G 4 Let SC be a set of components 5 foreach c2G do 6 if (c2S G ) then 7 add TraverseEventChannels(c;OB G ) to SC 8 else if (c2IB G ) then 9 add TraverseEventChannels(c;S G ) to SC 10 foreach d2G do 11 if (d62SC) then 12 remove d from G 13 return ReducedG ( G can be vulnerable to event attacks: (1) The first case is for a set of event communication chan- nels directed from a sensitive component to an outflow-boundary component (lines 6-7). If c is a sensitive component, Algorithm 3 calls TraverseEventChannels to identify the components that are involved in the connected edges from c to each outflow-boundary component (line 7). TraverseEventChannels(n;A) traverses all sets of connected edges directed from a component n to each component in a set of components A. It then returns every component involved in those edges to the set of components SC until no connected edge exists or an edge forms a loop. For example, from the EFG in Figure 3.6, the components s1, c4, and b1 will be returned toSC, but the components c1, c2, and c3 will not. (2) The second case is for a set of event communication channels from an inflow-boundary component to a sensitive component (lines 8-9). Algorithm 3 traverses the edges from an inflow-boundary component c to every component in S G , and returns the involved components to SC. Once every component in G is examined, Algorithm 3 removes the components that do not belong to SC from G (lines 10-12), and returns a pruned graph ReducedG (line 13). 56 Algorithm 4: Identification of Vulnerable Communication Channels Input: G ( an EFG Output: VulCF ( a set of vulnerable event communication channels 1 Let S G be a set of sensitive components in G 2 Let OB G be a set of outflow-boundary components in G 3 Let IB G be a set of inflow-boundary components in G 4 Let SM c be a set of sensitive methods in a component c2G 5 Let l = [c 1 ;c 2 ;:::c n ] be a list of connected components from component c 1 2S G to component c n 2OB G or from component c 1 2IB G to component c n 2S G 6 Let t2 (PET c [CET c ) where8c2G 7 foreach l2G do 8 if ((c 1 2S G )^ (c n 2OB G )) then 9 foreach s2SM c1 do 10 t ( identifyFlow(c 1 ;s;PEI c1 ; \out";l:remove(c 1 )) 11 add getOutFlowChannel(t) to VulCF 12 if ((c n 2S G )^ (c 1 2IB G )) then 13 foreach s2SM cn do 14 t ( identifyFlow(c n ;s;CEI cn ; \in";l:remove(c n )) 15 add getInFlowChannel(t) to VulCF 16 return VulCF Identification. SCUTUM identifies vulnerable event communication channels by implementing Algorithm 4 on the pruned EFG. Algorithm 4 iterates over each list of connected components (i.e., l in G), which directs from a sensitive component to a boundary component or reverse (lines 7-15). Two different cases are considered depending on the direction of l: (1) The first case is for l which directs from a sensitive component to an outflow-boundary component (lines 8-11). Algorithm 4 checks if an intra-component flow exists between a sensitive methods and PEI ofc 1 (=the starting component ofl) by callingidentifyFlow with the flag as “out” (line 10). To illustrate this case, consider the component Vic in Listing 2.1. Since Vic is a sensitive component and an out-flow boundary component, SCUTUM checks if an intra-component flow exists between its sensitive method getSensitiveInfo and its PEI publish by calling identifyFlow. As depicted in Algorithm 5, identifyFlow checks if a given component (=c) contains an intra- component flow between given two methods (i.e., m 1 and m 2 ). In case when a given flag is “out”, 57 Algorithm 5: identifyFlow(c, m1, m2, flag, l) Input: c ( a component, m 1 ;m 2 ( a method, flag ( a flag, l ( a list of components Output: t2 (PET c [CET c ) 1 Let Nodes(m) be a set of nodes in the CFG of m 2 Let ConsumeM(c 1 ;n 1 ;c 2 ) be r2CEI c2 that receives an event t, where t2PET c1 is dependent on a node n 1 3 Let PublishM(c 1 ;n 1 ;c 2 ) be r2PEI c2 that publishes an event t, where a node n 1 is dependent on t2CET c1 4 Let getPET (c;m) be t2PET c that is published via m 5 Let getCET (c;m) be t2CET c that is consumed via m 6 if flag = \out" then 7 if u2Nodes(m 2 ) is directly or transitively control or data dependent on v2Nodes(m 1 ) then 8 if l6=fg then 9 n(l:head 10 r(ConsumeM(c;u;n) 11 foreach q2PEI n do 12 identifyFlow(n;r;q; \out";l:remove(n)) 13 else 14 return getPET (c;m 2 ) 15 else 16 return 17 if flag = \in" then 18 if u2Nodes(m 1 ) is directly or transitively control or data dependent on v2Nodes(m 2 ) then 19 if l6=fg then 20 n(l:tail 21 r(PublishM(c;v;n) 22 foreach q2CEI n do 23 identifyFlow(n;r;q; \in";l:remove(n)) 24 else 25 return getCET (c;m 1 ) 26 else 27 return it inspects every node in the CFGs of m 1 and m 2 , and checks if a node in m 2 is dependent on a node in m 1 (line 7-16). If yes, Algorithm 5 recursively checks an intra-component flow from CEIs to PEIs of subsequent components in l (lines 8-12). If the flows exist throughout every component in l, Algorithm 5 returns PET which can be published via m 2 by calling getPET (line 14); Otherwise it returns null (line 16). For the reverse case when flag is “in” (line 17-27), Algorithm 5 checks the flow from nodes inm 2 to nodes inm 1 , and recursively identifies intra-component flows from PEIs to 58 CEIs of subsequent components in l (lines 19-23). If the flow exists throughout every component in l, it returns CET which can be consumed via m 1 by calling getCET (line 25); Otherwise, it returns null (lines 27). If identifyFlow returns PET (i.e., t) which is not null, Algorithm 4 identifies the event commu- nication channel where the returned PET is published by calling getOutFlowChannel, and add the channel to VulCF, a set of vulnerable event communication channels (lines 10-11 in Algorithm 4). Coming back to the example in Section 2.2.2, since Vic contains an intra-component flow from getSensitiveInfo to publish, the PET (i.e., f(Name : \ReplyInfo"); (StringProperty : \Sensitive")g) will be returned by Algorithm 4. Finally, the communication channel between Vic and Mal will be added to VulCF. (2) The second case is for l which directs from an inflow-boundary component to a sensitive component (lines 12-15). Algorithm 4 checks if an intra-component flow exists between a sensitive method s and CEI of c n (=the last component of l) by calling identifyFlow with the flag as “in” (line 14). If identifyFlow returns CET (i.e., t) which is not null, Algorithm 4 identifies the event communication channel where the returned CET is consumed by calling getInFlowChannel, and add the channel to VulCF (line 15). SCUTUM also performs pattern analysis on the event communication channels in EFG based on the previously identified patterns [74]. SCUTUM considers four different patterns as follows: (c: a component, T: a trust boundary, x = )y: an event communication channel exists from x to y) 1. For components c 1 and c 2 2T 1 ;c 3 2T 2 ; c 1 6=c 2 6=c 3 : (c 3 = )c 2 )^ (c 1 = )c 2 ) 2. For components c 1 and c 2 2T 1 ;c 3 2T 2 ; c 1 6=c 2 6=c 3 : (c 1 = )c 3 )^ (c 1 = )c 2 ) 3. For components c 1 2T 1 ; c 2 and c 3 2T 2 ; c 1 6=c 2 6=c 3 : (c 1 = )c 2 )^ (c 2 = )c 3 )^:(c 1 = )c 3 ) 59 4. For components c 1 and c 2 2T 1 ;c 3 2T 2 ; c 1 6=c 2 6=c 3 : (c 1 = )c 2 )^ (c 2 = )c 3 )^:(c 1 = )c 3 ) The patterns are based on the assumption that event communication within the same trust boundary is intended access, but event communication across the boundaries can be unintended access from a malicious component. Specifically, in case of the pattern 1,c 3 = )c 2 can be spoofing. For the pattern 2, c 1 = )c 3 can be interception or eavesdropping. For the pattern 3 and 4, c 1 = )c 2 = )c 3 can be confused deputy or collusion. If a given EFG contains event communication channels that match any of these patterns, SCUTUM returns the corresponding channel(s) to VulCP, a set for vulnerable event communication channels. Finally, SCUTUM returns all the identified event communication channels inVulCF andVulCP. While the channels belonging to both sets can be considered as the most vulnerable, other ones also need to be inspected and protected in order to minimize the threats of event attacks in a target EBS. 3.3.2 Implementation I have implemented SCUTUM as a stand-alone Java app that uses the target EBS’s bytecode as input and exports a list of identified vulnerable communication channels. SCUTUM’s implementation combinesapproximately2,000newlywrittenSLOCwiththeoff-the-shelftools, Eos[95]andSoot[187]. Eos is used in the extraction phase (recall Section 3.3.1) to extract PET and CET from target EBS. Soot is used to generate CGs and CFGs of the components within a target EBS. 60 3.4 ViVA Event-based system’s (EBS’s) non-determinism in its runtime event processing [94] is exposed to event attacks, because the order of or time interval between processing events is not strictly regulated in general. While SEALANT’s Analyzer and SCUTUM are able to detect most types of vulnerabilities that expose the system to event attacks (specifically, types A1-A5), they may overlook some types of vulnerabilities that are not statically analyzable, such as flooding and delaying (types A6 and A7). Because those types of vulnerabilities do not explicitly appear in program source code, a systematic runtime analysis on event communication is required. Although a number of techniques have been proposed to analyze the event communication between components [95,167] or to detect security vulnerabilities in EBS [58,58,74,122,122,130, 130,133,149,193], they do not support runtime event monitoring with systematic representation, which hinders engineers from effectively identifying security vulnerabilities. I posit that, with the aid of appropriate runtime monitoring and visualization, engineers can improve their understanding of target EBS so that they can identify more security vulnerabilities from target EBS. 3.4.1 Design To overcome aforementioned challenges and the shortcomings of the existing approaches, I designed ViVA (Visualizer for eVent-based Architectures), a visualization technique that aids engineers to understand runtime event communication between components and identify security vulnerabilities that expose the system to event attacks. While ViVA primarily targets flooding and delaying, it also helps engineers identify other types of vulnerabilities (e.g., types A1-A5). ViVA has four key features: (1) ViVA initially depicts the entire architecture including the key architectural elements, such as components, connectors, and the relationships among them; (2) ViVA 61 presents the events that are exchanged between the components, along with the order in which these events are generated during runtime. ViVA also supports monitoring whether particular events or a particular order of event exchanges occur; (3) To deal with the overwhelming number of events and event communication channels between components that EBSs commonly have, ViVA provides a feature of filtered visualization that focuses only on information regarding components and events in which engineers state an explicit interest; (4) ViVA displays security vulnerabilities between components, which were detected by both static analysis and runtime monitoring. 3.4.1.1 Overview ViVA relies on the integration of three key techniques: runtime visualization, message-log replay, and combined static and dynamic analysis. I elaborate on each in this section. Runtime Visualization. Runtime visualization is a powerful method for understanding a software system as it can transform the raw data generated by a running system into a form that is more intuitive for human comprehension. Runtime visualization can help engineers in different ways. For instance, engineers can much more readily grasp the system’s overall architecture by studying the visualization than by relying on the original source code or the raw runtime data. Moreover, an appropriate visualization can inform engineers interested in outliers by identifying and highlighting them, which could be costly with raw data [96]. ViVA is able to visualize the architecture of an EBS and illustrate its key architectural elements: components, connectors, and event communication channels. ViVA also implements a visualization of event chronology [96]: it displays events exchanged between components during execution time in the order in which they are published. Event-Log Replay. Referred to as event-log replay, ViVA can visualize recorded events after the fact in the order of their publication. ViVA implements event-log replay by recording the runtime 62 event communication between components, and by providing the engineer a “remote controller” to replay the event communication history forward and backward. Engineers may utilize this feature to establish that desired event communication is missing or to identify unexpected event communication, such as flooding and delaying. Furthermore, if the execution fails, a replay execution can be used to help track down the failure and its causes. Combined Static-Dynamic Analysis. Static and dynamic analysis have been shown to be effective analysis methods for security vulnerability analysis [58,130,184,208] that can complement each other. Static analysis techniques can consider all possible control-flow paths, which may result in an over-approximation of the event communication channels in a system. In contrast, dynamic analysis techniques can be more precise, but only consider information along paths that have been executed. ViVA adopts both methods and provides engineers with the intersection of their results. In turn, this has the potential to yield more accurate analysis of security vulnerabilities. 3.4.1.2 Architecture In this section, I describe the details of ViVA’s three subsystems and their configurations. Figure 3.7 depicts ViVA’s architecture. The architecture comprises three major subsystems: ViVA Core, Static Analyzer, and External Output Depictor. ViVA Core is responsible for collecting and processing the analysis information to be visualized, and for managing the integration and the interaction with the other two subsystems, both of which have been integrated off-the-shelf. ViVA Core relies on a MOM platform that supports recording of events exchanged between components. In the case of event-log replay, the MOM platform continuously records exchanged events until it receives a stop request. Afterwards, the MOM platform transfers the recorded events to ViVA Core. ViVA Core comprises three distinct 63 Target Code ViVA Crawler ViVA Main ViVA I/O Static-Analyzer Adaptor Connector ViVA-Core Transformed Target Code Static Analysis Information Visualized Architectural Information Component Extensible Component Connector External Component User Command Visualized Outputs External Output Depictor User Command Visualized Outputs User Command Information Request Architectural Information MOM Pla'orm Visualization Information User-Command Request Engineer User/Tool Interaction Data Channel Visualized Architectural Information Middleware Transformed Target Code Static Analysis Information Static Analysis Information Data Access Connector Figure 3.7: Overview of ViVA’s Architecture components: ViVA Main, ViVA Crawler, and ViVA I/O. ViVA Main runs the dynamic analysis computation, sorts and searches the collected application events, and manipulates the information to be presented to engineers. ViVA Main’s dynamic analysis monitors events at the consuming and publishing interfaces of an EBS component to determine their runtime event communication. ViVA’s MOM platform records all events at these interfaces and makes them accessible to ViVA Main. The MOM platform adds a unique ID to each event that is sent by a component. ViVA Main determines event exchanges by checking the IDs of published and consumed events: it identifies 64 the component where each event has been published and the components that consume that event. ViVA Main also sorts recorded events in temporal order and generates visualization information to be presented via ViVA I/O or External Output Depictor. ViVA Crawler collects the architectural information of target EBS’s code. This information includes how each component and connector of the EBS are initialized and composed. ViVA I/O interacts with the engineer and the two external subsystems. ViVA I/O’s GUI visualizes architectural information received from ViVA Main and shows ViVA’s status. This information includes coordinates, colors, types of architectural elements and events, as well as their relationships. ViVA I/O also forwards the analysis results received from Static Analyzer to ViVA Main. In case External Output Depictor has been connected, ViVA I/O forwards the visualization information to the External Output Depictor. Static Analyzer identifies event communication channels and security vulnerabilities using static analysis. The event communication channels are determined by analyzing the types of events that each component publishes and the corresponding components that consume those event types [95]. The security vulnerabilities are determined by examining control-/data-flows across event communication channels as well as event communication patterns between components [128]. Through the use of an explicit data-access connector [182], ViVA is able to integrate with different Static Analyzers. In addition to its default visualization, ViVA also supports visualization through External Output Depictor, an external and pluggable component. External Output Depictor allows engineers to customize notations in their visualization and renders architectural information sent from ViVA I/O in a pre-defined format specified through a meta-model. 65 A light blue rectangle represents components. The component shows its abbreviated name. A black line represents an internal event channel between components and connectors. A blue line represents an external event channel between components and connectors. After an engineer applies an operation, the colors of components and connectors may change accordingly. When an engineer requests for all exchanged messages to be visualized, components that handle no messages become dark blue. A gray-rounded rectangle represents a connector. The connector shows its abbreviated name. When an engineer clicks an architectural element, ViVA shows the messages it sends or receives and the sequence of those messages. Numbers in parentheses indicate the order of messages within components. Trailing numbers in square brackets indicate the order of messages across components. The ViVA Console allows engineers to apply operations and monitor ViVA’s status. When an engineer clicks an architectural element, ViVA shows its full name concatenated with its ID number. Figure 3.8: User Interface of ViVA’s Prototype for Prism-MW 3.4.1.3 Key Features In this section, I will describe ViVA’s three key features. Each feature consists of one or more associated operations accessed via the prototypes of ViVA as shown in Figure 3.8 and 3.9. Visualizing System Architecture. When first encountering an EBS, an engineer can benefit from seeing all of its components, connectors, and event communication channels. To this end, ViVA provides an operation, called visualize, that displays the entire architecture of the target system. As shown in Figure 3.8, the visualize operation depicts the system’s components as light blue rectangles, connectors as gray rounded rectangles, internal event communication channels as black lines, and external event communication channels as blue lines. Internal event communication channels are associations between components and connectors that are deployed on the same host or trust boundary. External event communication channels are associations between components and connectors that are deployed across different hosts or trust boundaries. 66 As part of the visualize operation, an engineer can request to see all events exchanged during a particular execution of target EBS. In response, as shown in Figure 3.8, ViVA displays the events as scrolling lists inside the rectangles of the publishing and consuming components. The shading of the components that did not publish or consume any events during this run changes to dark blue. A target EBS may have a number of event communication channels, connectors, and components while exchanging a large number of events at runtime. Displaying the system in its entirety may result in an incomprehensible visualization. To deal with this situation, ViVA provides an operation called filter. This operation allows engineers to focus on a particular part of the target EBS. Once an engineer inputs the names or identifying keywords of the desired components and/or connectors into ViVA’s console, ViVA responds by depicting only the requested part of the architecture. Analogously to the visualize operation, filter can also show the events exchanged among the selected components during a given execution. Tracking Event Exchanges. Another level of understanding is achieved by considering the events communication between components. For example, engineers may be interested in whether any of the expected events are missing, whether unexpected events have occurred, and whether the order of event exchanges is different than expected. ViVA supports tracking event communication and their order via an operation, called track, that displays the events exchanged during an execution in chronological order. Engineers can monitor event communication in, both, forward and reverse orders. For an eventm that has been exchanged between components, track (1) changes the color of the component that generatedm to green and showsm inside that component, (2) changes the color of the connector through which m has been routed to red, and (3) changes the color of the receiving component to green and shows m inside it. If an engineer tracks the event exchange backwards, ViVA performs the above three steps in reverse order. 67 Figure 3.9: User Interface of ViVA’s Prototype for Android As another aid in focusing on specific events, ViVA provides an operation called search. This function goes through the event communication history to find whether events with a particular name have been published or consumed during runtime. ViVA highlights the components through which the searched events have traveled by changing the color of the components to yellow. Engineers may exploit this function to identify missing events or unintended events communication. Additionally, ViVA provides an operation called check_flow, which compares a event sequence occurring at runtime with a sequence specified by an engineer. ViVA displays any mismatches and highlights the involved components in red. Visualizing Security Vulnerabilities. Inspecting runtime event communication helps engi- neers effectively and intuitively identify security vulnerabilities that expose the system to event 68 attacks. ViVA supports different functionalities in order to aid engineers to identify different types of event attack. ViVA visualizes the number of events exchanged between components, which were gathered by runtime monitoring. As shown in Figure 3.9, ViVA distinguishes the width of each edge based on the number of exchanged events during runtime (e.g., 1mm represents 1-10 events; 5mm represents 10-100 events). Engineers intuitively identify vulnerable event communication channels exposed to flooding attack (type A6) by examining the width of displayed edges. ViVA also records and visualizes the event processing time of each component. ViVA distinguishes the color of components based on each component’s elapsed time between consumption of an event and publishing of an event (e.g., 1ms-10ms or 10ms-100ms). Engineers intuitively identify vulnerable event communication channels exposed to delaying attack (type A7) by examining the color of displayed components. For the other types of event attacks (types A1-A5), ViVA highlights the vulnerable event commu- nication channels that were identified by Static Analyzer (e.g., SEALANT’s Analyzer or SCUTUM). As depicted in Figure 3.9, based on the Static Analyzer’s result, ViVA highlights vulnerable event communication channels with different colors (e.g., intent spoofing in red, unauthorized receipt in blue, and privilege escalation in green). 3.4.2 Implementation I implemented two prototypes of ViVA each of which targets different platform: (1) Prism-MW [135] and (2) Android [7]. Note that these prototypes can be consolidated into a single tool, while maintaining their own features. 69 (1) The first prototype is built upon Prism-MW [135], which is an extensible MOM platform that allows a developer to implement applications using pre-defined architectural constructs, such as components and connectors. Prism-MW is chosen because of its extensibility and support for different architectural styles, types of connectors, and implementation languages. Events in Prism-MW follow a pre-defined format that includes a name and a time stamp, which are used for routing. Both ViVA Core and the target EBSs it visualizes are implemented in Java and run on PrismMW-Vis, a specialized version of Prism-MW [135]. PrismMW-Vis extends Prism-MW by additionally providing the ability to record information about event exchanges as an array structure and to share them with ViVA Core. Prism-MW provides implementations of event interfaces. During runtime, PrismMW-Vis records the information about events into two separate fixed-size arrays, one for published and the other for consumed events. Since ViVA Core runs on PrismMW-Vis, ViVA Main can directly access the arrays for the recorded information about events. ViVA Crawler must be embedded in the target EBS’s code so that it can access and analyze the architectural configuration (i.e., the set of associations between components and connectors) of target EBS. The architectural configuration is explicitly specified using PrismMW-Vis. To embed ViVA Crawler in the target app’s code, I add a pre-compiled Java class file that implements ViVA Crawler to the target EBS’s code. I selected Generic Modeling Environment (GME) [97] as ViVA’s External Output Depictor. GME is a domain-specific modeling tool that supports meta-modeling, provides APIs for model manipulation, visualizes models, and supports facilities for users to interact with the model. I created a new modeling notation for ViVA by specifying a meta-model in GME. This notation includes only the essential information of the architecture visualization. ViVA invokes the model manipulation APIs of GME through the adaptor connector (shown in Figure 3.7) to present the output of the requested ViVA function from ViVA I/O. For ViVA’s Static Analyzer, I chose Eos [95]. Eos is a summary-based 70 iterative data-flow analysis that computes the types of events in a target app, the event types’ constituent attributes, and the potential event communication channels between components. ViVA Core interacts with Static Analyzer (i.e., Eos) via a data-access connector described as the following: one subsystem writes the relevant information to a file, and the connector enables the other subsystem to access that information without directly coupling the two subsystems. (2) The second prototype supports Android [7], which is the most widely used mobile platform. ViVA Main and ViVA I/O are implemented as a web app, using HTML5 with the off-the-shelf JavaScript libraries that include jQuery [38] for event handling web pages and Bootstrap [36] for developing a responsive web app. Android framework [7] has been extended to provide the ability to record the information about event exchanges. To enable extraction of architectural information from apps, ViVA Crawler integrates two static analysis tools: IC3 [147] and COVERT [56]. ViVA Crawler uses a set of APK files as its input and exports a set of architectural information in pre-defined JSON files. External Output Depictor leverages D3 [26], a JavaScript library for data visualization. For ViVA’s Static Analyzer, I chose SEALANT’s Analyzer which is able to extract security vulnerabilities from a given set of apps. ViVA Core interacts with Static Analyzer via data-access connector, a pre-defined JSON file. The prototype is available at http://softarch.usc.edu:34380/. 71 Chapter 4 Evaluation The proposed approaches, SEALANT, SCUTUM, and ViVA, have been designed and developed based on the four hypotheses introduced in Section 1.2. This chapter presents the empirical and analytical evaluation of the proposed approaches as a means to test the four hypotheses. This chapter includes the following four sections: In Section 4.1, the evaluation of SEALANT is presented. The focus of this section is to test Hypotheses 1,2, and 3, regarding whether and to what extent the static analysis that SEALANT provides would accurately identify the vulnerabilities that expose the system to event attacks; the runtime event control that SEALANT provides would accurately prevent event attacks; and users can effectively protect their devices from event attacks using SEALANT. In addition, the evaluation of SEALANT’s performance is described. Section 4.2 demonstrates the evaluation of SCUTUM. This section tests Hypothesis 1, with respect to accuracy, applicability, and performance of SCUTUM inidentifyingthevulnerabilitiesthatexposethesystemtoeventattacks. InSection4.3, theevaluation of ViVA follows. This section tests Hypothesis 4, which deals with the visualization technique that ViVA provides in order to confirm that engineers can effectively detect the vulnerabilities that expose 72 the system to event attacks by using ViVA. Finally, Section 4.4 discusses the threats to validity and the limitations of my evaluation. 73 4.1 Evaluation of SEALANT SEALANT was empirically and analytically evaluated (1) to check its accuracy in detecting vulnera- bilities between a set of apps and in runtime blocking of the identified vulnerabilities, (2) to verify its effectiveness in preventing event attacks (referred to as inter-app attacks in this section), (3) to validate its usability, and (4) to measure its scalability and performance. 4.1.1 Applicability and Accuracy I evaluated Analyzer’s accuracy in identifying vulnerable ICC paths by comparing its results against those of SEPAR [57,58] and IccTA [30,130], state-of-the-art tools for ICC vulnerability detection whose own evaluations have shown better accuracy than other competing approaches [49,122,193]. I also evaluated Interceptor’s ability to control vulnerable ICC paths at runtime. I used a test suite of 1,150 Android apps in total. 4.1.1.1 Experimental Setup To build my test suite, I selected several apps from different sources. The goal of this selection was to have a set of apps whose vulnerabilities were known (for purposes of measuring recall) and here is how they were obtained or generated. I first selected several real-world apps that are vulnerable to inter-app attacks. Among the apps that were previously identified [58] from repositories such as Google Play [11], F-Droid [29], MalGenome [210], and Bazaar [8], I selected 13 that are exposed to the three types of attacks SEALANT targets. I also included six apps from DroidBench 2.0 [10], an app collection for benchmarking ICC-based data leaks. Since several of the 19 vulnerable apps did not have readily available malicious apps targeting them, I built 25 malicious apps, each of which performed one inter-app attack. To mitigate internal threats to the validity of evaluation results, I 74 Table 4.1: Applying SEALANT on the 135 Apps in My Core Test Suite Attack Type Number of Apps Vulnerable ICC Paths Identified ICC Paths (Precision / Recall) Blocked ICC Paths (Precision / Recall) Vulnerable Malicious “Trick” Direct Transitive SEPAR IccTA Analyzer Interceptor IS 27 26 4 25 1 0.00 / 0.00 1.00 / 0.04 1.00 / 0.96 1.00 / 1.00 UIR 26 25 4 25 0 0.50 / 0.20 1.00 / 0.16 1.00 / 0.92 1.00 / 1.00 PE 8 11 4 4 4 0.00 / 0.00 0.00 / 0.00 1.00 / 1.00 1.00 / 1.00 Total 61 62 12 54 5 0.50 / 0.09 1.00 / 0.08 1.00 / 0.95 1.00 / 1.00 IS = intent spoofing; UIR = unauthorized intent receipt; PE = privilege escalation. also asked 39 graduate students at University of Southern California (USC) to build sets of apps that implement inter-app attacks based on published literature [68,74]. Each of those sets was either a pair of apps forming a simple path, or a trio of apps forming a transitive path. Without any intervention by me, the students built 41 distinct sets. This yielded 91 apps in total, of which 47 were new, while 42 were modified and 2 unmodified apps obtained from public sources [25,33]. In total, this yielded 65 sets containing 135 apps, with 54 vulnerable ICC paths and 5 vulnerable transitive ICC paths. To ensure that inter-app attacks can be actually launched, two graduate students at USC manually inspected the code of each set, and installed and ran the set on a Google Nexus 7. They confirmed that the attacks from the malicious apps were successfully launched and exploited the vulnerable apps by observing the apps’ behavior via the device’s UI and via logcat, a native Android tool for monitoring system debug outputs [17]. My test suite also includes 12 “trick” apps containing vulnerable but unreachable components, whose identification would be a false warning. I divided this core test suite into three different groups, based on the type of attack to which a vulnerable app is exposed, as shown in Table 4.1. Subsequently, I created an expanded test suite totaling 1,150 apps, by including another 1,015 apps randomly selected from Google Play [11] and MalGenome [210]. 75 4.1.1.2 Evaluation of Analyzer I evaluated SEALANT’s Analyzer for accuracy in identifying vulnerable ICC paths as compared to SEPAR and IccTA. I used my core test suite to measure all three approaches’ (1) precision, i.e., identified ICC paths that were actually vulnerable, and (2) recall, i.e., the ratio of identified to all vulnerable ICC paths. As depicted in Table 4.1, Analyzer detected vulnerable ICC paths with 100% precision and 95% (56 of 59) recall. It was unable to correctly extract intent information in three cases due to the inaccuracies inherited from IC3 [147] and COVERT [56] (recall Section 3.2.2). Analyzer correctly ignored all “trick” cases with unreachable vulnerable paths. SEPAR had 50% precision and 8% recall. This is primarily because SEPAR was designed (1) to identify vulnerable components or interfaces rather than specific ICC paths between them and (2) to return an ICC path only when both sender and receiver contain sensitive Android API methods [164], hampering its applicability in cases such as privilege escalation via a transitive ICC. IccTA had 100% precision and 8% recall. Since it targets a single type of attack (privacy leaks), IccTA also returned an ICC path only when it involved sensitive API methods [164]. Although SEALANT outperformed SEPAR and IccTA in my evaluation, it is important to note that SEPAR and IccTA support both intra- and inter-app analysis and may detect additional vulnerabilities that SEALANT does not. I then used my expanded test suite of 1,150 apps (9,964 components and 20,787 ICC paths). I created 23 non-overlapping bundles, each comprising 50 apps randomly selected from the suite. I created 50-app bundles because this number is higher than the recently cited number of apps an average smartphone user regularly uses each month [21]. I ran all three tools on each bundle and manually checked if each identified ICC path is indeed vulnerable. Analyzer flagged 86 ICC paths, with 93% precision. The six false-positives were caused by IC3’s inaccuracy in identifying intents and COVERT’s omission of intent attributes in certain scenarios. SEPAR and IccTA were unable to 76 analyze the bundles on four different hardware configurations. SEPAR’s logs indicated that it was unable to generate the results of flow-analysis in some cases, while it did not return any vulnerabilities in other cases. According to the authors of SEPAR, this was caused by its implementation bugs. IccTA invariably crashed. Specifically, it was unable to analyze more than one app at a time in more than 75% of my attempts. This was mainly because of its reliance on reassembling apps. In order to analyze more than one app using IccTA, it is required to reassemble different apps to generate a single app (this functionality is also provided by the tool set of IccTA), which can cause crashes between variables, components, or permissions. These problems were confirmed by the authors. 4.1.1.3 Evaluation of Interceptor I evaluated Interceptor’s accuracy in detecting and blocking malicious ICCs at runtime. To monitor all ICCs exchanged on a device, I integrated a logging module that outputs information of each ICC instance via logcat [17] into ActivityManager (recall Section 3.2). I installed the 135 apps in my core test suite on a Google Nexus 7 with Interceptor set up, ran Analyzer on the device, and provided the resulting SEALANT List to Interceptor. To run test scripts that trigger ICCs, I used monkeyrunner [18], an Android tool for running test suites. I designed each script to trigger one type of vulnerable ICC in the SEALANT List as well as various benign ICCs. I configured the scripts to choose to block an ICC when Interceptor prompts for a blocking choice. I repeated executing each script until I accumulated 30 blocked ICCs. At the end of each test script execution, Two graduate students at USC manually inspected the logs in order to measure (1) precision, i.e., if all blocked ICCs corresponded to vulnerable paths specified in the SEALANT List, and (2) recall, i.e., if Interceptor allowed any ICC attempts over the vulnerable 77 paths. Interceptor was able to block vulnerable ICCs in the core test suite with perfect precision and recall (see Table 4.1). 4.1.2 Effectiveness To the best of my knowledge, three existing works share SEALANT’s goal of providing protection of end-users from inter-app attacks: SEPAR [58], DroidGuard [57] (the prior version of SEPAR), and XmanDroid [67,68]. SEPAR identifies vulnerable surfaces of a set of apps via static analysis and uses dynamic memory instrumentation that hooks the method calls of target apps at runtime. For example, in the scenario from Figure 1.1(a), SEPAR would identify the vulnerability of V2 and hook the startActivity() method that sends an intent to V2. DroidGuard identifies vulnerable surfaces of a set of apps installed on an Android device via static analysis. In order to address the identified vulnerabilities, it directly inserts policy-enforcement code into the vulnerable apps. For example, in the scenario depicted in Figure 1.1(b), DroidGuard would identify the vulnerabilities of V3 (i.e., sendBroadcast()) and place enforcement code that wraps sendBroadcast(). This ensures that whenever sendBroadcast() sends an intent, the end-user will be notified and will be able to choose whether to block the intent exchange. XmanDroid is a technique that only targets privilege escalation attacks by leveraging an extension to Android. XmanDroid enables a user to pre-define a list of ICC restriction policies, and automatically blocks ICCs that match any one of those policies. For example, XmanDroid can have the following policy: An app that can obtain location information must not communicate with an app that has outgoing network access [67]. An ideal comparison of SEALANT against these three techniques would have included executing their implementations in a controlled setting and/or on a set of real-world Android apps. However, the implementation of XmanDroid I obtained from its authors only runs on a prior version of 78 Android (2.2.1), while the current prototype implementations of SEPAR and DroidGuard are missing certain features covered by the underlying technique (e.g., the policy enforcement module). I tried unsuccessfully to build an installation of XmanDroid on several recent versions of Android. Given the changes in Android since 2.2.1, continuing with this strategy proved impractical. For these reasons, I decided to analytically compare the three techniques, relying on the published algorithms of SEPAR [58], DroidGuard [57], and XmanDroid [67,68]. 4.1.2.1 Comparison with SEPAR SEALANT raises fewer false inter-app attack alarms to end-users compared to SEPAR. I validate this by projecting the number of inter-app attack alarms each of the two techniques would raise in the scenario depicted in Figure 1.1(b). I define the following probabilistic random variables in order to illustrate the projection. • N is the number of user interactions with a device in any given period of time. • V is the random variable for user device containing VicApp2. • P (V ) is the probability that a user has VicApp2 on her device. • M is the random variable for user device containing MalApp2 that can receive intent i from V3 in VicApp2. • P (M) is the probability that a user has MalApp2 on her device. • P(E) is the probability that a user interacts with her device and triggers V3 to broadcast intent i. • P (I) is the probability that MalApp2 eavesdrops on intent i. 79 • A is the event that raises an alarm. A SLT indicates an alarm from SEALANT, and A SP indicates an alarm from SEPAR. The expected value for an alarm raised by SEPAR is: E(A SP ) =NP (V;E) (4.1) The expected value for an alarm raised by SEALANT is: E(A SLT ) =NP (V;M;E;I) (4.2) E(A SLT ) can never be higher than E(A SP ) for the following reasons. Assuming M = I (i.e., MalApp2 can always eavesdrop on intent i), the expected value for SEALANT raising an alarm will be E(A SLT ) =NP(V;M;E). Since 0P(M) 1, I can infer the following two cases regarding the dependency of M on V: 1. E(A SLT ) =E(A SP ) ifM is completely dependent onV (i.e.,M =V). However, this is unlikely since there is no guarantee that the two different apps are installed on the same device. 2. E(A SLT ) =NP (V;E)P (M) if M is independent of V. This means that SEPAR will raise NE(A SP )(1P (M)) more alarms than SEALANT. As P (M) converges to zero, the rate at which SEPAR raises a false positive alarm will increase. Even if the device did not have an app that receives intent i, SEPAR would raise an alarm for every broadcast of intent i from V3 . For example, even for a safe, intended intent exchange within VicApp2 such as sending intent i from V3 to V4, SEPAR will raise the (false positive) alarm. By contrast, SEALANT raises an alarm only when intent i between V3 and M2 is initiated. SEALANT 80 filters only the vulnerable ICCs using the path information which includes the ICC’s sender and receiver. 4.1.2.2 Comparison with DroidGuard SEALANT raises fewer false inter-app attack alarms to end-users compared to DroidGuard. I validate this by projecting the number of inter-app attack alarms each of the two techniques would raise in the scenario depicted in Figure 1.1(b). I define the following probabilistic random variables in order to illustrate the projection. • N is the number of user interactions with a device in any given period of time. • V is the random variable for user device containing VicApp2. • P (V ) is the probability that a user has VicApp2 on her device. • M is the random variable for user device containing MalApp2 that can receive intent i from V3 in VicApp2. • P (M) is the probability that a user has MalApp2 on her device. • P (E) is the probability that a user interacts with her device and triggers V3 to broadcast intent i. • P (I) is the probability that MalApp2 eavesdrops on intent i. • A is the event that raises an alarm. A SLT indicates an alarm from SEALANT, andA DG indicates an alarm from DroidGuard. The expected value for an alarm raised by DroidGuard is: E(A DG ) =NP (V;E) (4.3) 81 The expected value for an alarm raised by SEALANT is: E(A SLT ) =NP (V;M;E;I) (4.4) E(A SLT ) can never be higher than E(A DG ) for the following reasons. Assuming M = I (i.e., MalApp2 can always eavesdrop on intent i), the expected value for SEALANT raising an alarm will be E(A SLT ) =NP(V;M;E). Since 0P(M) 1. I can infer the following two cases regarding the dependency of M on V: 1. E(A SLT ) = E(A DG ) if M is completely dependent on V (i.e., M = V). However, this is unlikely since there is no guarantee that the two different apps are installed on the same device. 2. E(A SLT ) =NP(V;E)P(M) if M is independent of V. This means that DroidGuard will raise NE(A DG )(1P (M)) more alarms than SEALANT. As P (M) converges to zero, the rate at which DroidGuard raises a false positive alarm will increase. Even if the device did not have an app that receives intent i, DroidGuard would raise an alarm for every broadcast of intent i from V3 . For example, even for a safe, intended intent exchange within VicApp2 such as sending intent i from V3 to V4, DroidGuard will raise the (false positive) alarm. By contrast, SEALANT raises an alarm only when intent i between V3 and M2 is initiated. SEALANT filters only the vulnerable ICCs using the path information which includes the ICC’s sender and receiver. 4.1.2.3 Comparison with XmanDroid SEALANT suffers from fewer false negatives than XmanDroid. The detection mechanism of XmanDroid requires a user to explicitly specify policies indicating the types of inter-app attacks she 82 wishes to detect and ICC paths to monitor at runtime. This may omit critical inter-app attacks. Recall the privilege escalation attack scenario from Figure 1.1(c). When component M3 in MalApp3 requests an ICC to access V8 in VicApp4, XmanDroid inspects the permissions of MalApp3 and VicApp4 based on the pre-defined policies. Although a few general policies for XmanDroid have been proposed [68], they do not cover all vulnerability scenarios. In the above scenario, if a user-specified policy does not prohibit an ICC between an app with permission P1 and another app without it, XmanDroid will not raise an alarm. Since SEALANT inspects all ICC paths via static analysis to identify vulnerable paths, it does not suffer from this type of false negative. SEALANT also suffers from fewer false positives than XmanDroid. XmanDroid finds ICCs that match policies specifying the sender and receiver permission combinations. However, this would also block safe ICCs initiated by a benign app with an identical set of permissions as a malicious app. Suppose that XmanDroid has a policy that would block ICCs between MalApp3 and VicApp4 in the scenario depicted in Figure 1.1(c), and the device had another app, BenignApp, which is confirmed as reliable and holds identical permissions to MalApp3. In that case, even if BenignApp initiated an ICC to a method of VicApp4 that does not require P1, XmanDroid would block that ICC. SEALANT would not trigger such a false alarm. 4.1.3 Performance 4.1.3.1 Evaluation of Analyzer To evaluate the performance of Analyzer, I used a PC with an Intel dual-core i5 2:7GHz CPU and 4GB of RAM. I divided my expanded test suite into four categories with different numbers of apps (25, 50, 75, and 100). For each category, I created ten different bundles randomly selected from the 1,150 apps, and ran Analyzer on each bundle. On average, extracting architectural information 83 Table 4.2: Analyzer’s Performance on Different Number of Apps Number of Apps 25 50 75 100 Avg. Number of Components 237 553.5 761 1200 Avg. Number of ICCs 218 701.5 1110.5 1690.5 Avg. Analysis Time (Sec.) 22.17 42.24 107.27 118.43 from each app took 77:95s and identifying vulnerable ICC paths took 1:08s per app. While the extraction is relatively time-consuming, in scenarios where an app is newly installed or updated, Analyzer reuses the previously extracted app models to minimize the execution time. It performs the extraction only on the new app, and then runs the vulnerable path identification over all apps. Table 4.2 shows the average numbers of components and ICCs in each category. Since SEALANT manages an individual summary-based model of each app, the analysis time scales linearly with the number of apps. The results indicate that while the extraction of architectural information may require a long time depending on the number of apps, considering the fact that average end-users uses 30 apps in their devices, the analysis time for vulnerable paths would require less than 1 minute. Also, once the first analysis is finished, when a new app is installed on an end-user’s device, it would require less than 2 minutes, because Analyzer can reuse the summarized model from prior analysis. Furthermore, running Analyzer on a high-performance sever could significantly decrease the total analysis time. 4.1.3.2 Evaluation of Interceptor To evaluate Interceptor’s impact on performance, I measured the differences in execution times between Android with Interceptor and without it (in the remainder of this section, referred to as “Interceptor” and “AOSP” [7], respectively). I configured the two environments to be highly similar and to reasonably reflect the real-world. I employed the Google Nexus 7 in both environments and 84 Table 4.3: Differences in Execution Times (in milliseconds) Mean Min Max Std Dev Interceptor 25.51 11.31 81.12 10.22 AOSP 25.20 10.09 45.85 7.18 Difference 0.31 1.22 35.27 3.04 configured both to use Android KitKat 4.4.4. I installed the 50 most popular third-party apps [9] on the devices. To observe Interceptor’s worst-case performance overhead, I manually created a SEALANT List that would induce the longest execution time. The list contained 10 paths (amounting to 20% of the installed apps), none of which matched the actual ICC paths between the 50 installed apps. This maximized the overhead of Interceptor’s detection operation which sequentially matches an ICC to each path in its list. The above numbers were selected because they reflect (in fact, surpass) those found in the real-world: an average user regularly uses about 30 apps per month [21], and around 10% of Android apps are vulnerable to inter-app attacks [57]. To trigger a large number of ICCs on the test devices, I used Monkey [22], which generates pseudo-random streams of user- and system-level events on a target device. I used the same seed value in Interceptor and AOSP so that Monkey would generate identical event sequences in both environments. I injected 5,000 events in each environment and measured the time it took to process each event. I repeated this five times to mitigate the impact of conditions such as battery-status changes. Table 4.3 describes the results I obtained. The difference in mean execution times was less than 1ms, and in maximum execution times under 40ms. Differences of this degree are negligible because the threshold at which an end-user begins noticing slowdown in mobile app response is 100-200ms [15]. Interceptor introduces low overhead because it simply extends an existing operation 85 that AOSP already regularly performs to match a requested ICC with the list of paths on the device [7]. 4.1.4 Usability When an intent exchange matches a vulnerable ICC path, SEALANT requires the end-user to either block or allow the exchange in order to secure her device. To assess how challenging such choices are for end-users, I conducted a user study and a survey, guided by two hypotheses: • H1: The intent-exchange control choices SEALANT requires an end-user to make are not more difficult than the choices required of end-users by “stock” Android. • H2: A non-expert user can make intent-exchange control choices that prevent an inter-app attack most of the time. 4.1.4.1 Experimental Setup My user study and survey were designed to simulate situations in which users make choices reflective of daily Android use (e.g., whether to install an app after being shown the list of permissions it requires). Among those choices, I also inserted choices required by SEALANT. I asked the participants how difficult it was to make each choice and how confident they were in making the choice. The study included 34 participants, all graduate students at USC, recruited via an e-mail list. The students’ majors spanned engineering, communication, business, and social work. The background survey showed that the participants had used a mobile device for 59 months on average. 25 of the participants (74%) reported Android as their primary mobile platform or one they had experience 86 using; 9 (26%) had not used Android previously. 5 participants (14%) were aged between 18 and 24, and the remaining 29 (86%) between 25 and 34. I provided each user study participant a Google Nexus 7 with SEALANT pre-installed. They were presented with a series of 20 common scenarios of four different types: • Type 1 – A dialog asks the user whether to install an app randomly selected from a credible source (Google Play [11]) given the list of permissions the app requires. • Type 2 – Same as Type 1, but with apps randomly selected from an unreliable source. • Type 3 – Intent matches multiple filters. Android displays a dialog so the user can choose which app to use. • Type 4 – A dialog prompts the end-user to make a choice to block or allow a vulnerable inter-app access. I used native-Android dialogs in 12 of the 20 scenarios (Type 1-3), and in the remaining 8, I used SEALANT’s customized dialog (Type 4) that presents (1) the sender/receiver apps’ names, (2) the identified attack type, and (3) block, allow, and always buttons among which the end-user must choose. Half of the apps used in Type 4 scenarios were selected from apps used in Type 1 and the other half from Type 2 scenarios. During the study, I logged every interaction between a participant and the device via logcat [17]. At the end of each scenario, I asked participants to assess the scenario’s difficulty and confidence in their choices, using a 7-point Likert scale. In order to expand my dataset, I designed the online survey in the same manner as the user study. I took screenshots of what a user would see on her device as she went through the 20 scenarios, 87 Table 4.4: Difficulty, Confidence, and Response Time per Dialog Type Dialog Type User Study Survey Difficulty Confidence Response Time Difficulty Confidence n x s n x s n x M s n x s n x s Type 1 34 5.26 1.62 34 5.65 0.95 34 6.99 4.06 8.29 155 4.14 1.29 155 4.16 1.30 Type 2 34 4.68 1.70 34 5.35 1.20 34 12.32 9.92 7.92 155 4.29 1.25 155 4.15 1.33 Type 3 34 4.79 1.68 34 5.56 1.02 34 9.02 6.51 8.58 155 4.65 1.38 155 4.35 1.36 Type 4 34 4.97 1.40 34 5.50 1.21 34 6.24 5.10 4.32 155 4.35 1.33 155 4.17 1.26 Type 1-3 102 4.91 1.67 102 5.52 1.06 102 9.44 7.24 8.53 465 4.36 1.32 465 4.22 1.33 n = num participants. x = mean. M = median. s = std deviation. Difficulty and confidence values are on 7-point Likert scales (1 = very difficult, 7 = very easy; 1 = not confident at all, 7 = fully confident). Response time values are in seconds. The Type 1-3 row presents merged data from Type 1 through Type 3 rows. presented the screenshots to the survey respondents, and prompted them to make the corresponding choices. I sent out 200 survey requests and received 155 valid responses (78%); 45 people did not respond or only partially completed the survey. I sent requests to known e-mail lists and contacts, and allowed them to self-select. The respondents had used a mobile device for 51 months on average. 138 (89%) named Android as their primary mobile platform or had experience using it. The survey covered a range of age groups and occupations. 11 respondents (7%) were aged 18-24, 46 (30%) were 25-34, 37 (24%) were 35-44, 35 (22%) were 45-54, and 26 (17%) were 55+. Respondents included 46 students (30%), 27 medical doctors (17%), 20 business people (13%), 11 housewives (7%), 10 software engineers(7%), 9professors(6%), 5retailers(3%), 5lawyers(3%), and22others(14%). Moredetailed information about the user study and survey is available at http://softarch.usc.edu/sealant/. 4.1.4.2 Results I evaluate hypotheses H1 and H2 using the user study and survey data. For simplicity, I refer to the user study participants and survey respondents as “participants”. 88 H1 – I compared (1) the difficulty perceived by participants in making their choices, (2) the confidence participants had in their choices, and (3) the time it took to make choices for native- Android dialogs (Type 1-3) and SEALANT dialogs (Type 4). Table 4.4 presents the data I obtained. A comparison of the mean degrees of difficulty showed that they did not differ significantly between the two groups of scenarios (Student’s t-test; p-value 0.928 for user study and 0.972 for survey). A comparison of the mean degrees of confidence yielded the same conclusion (Student’s t-test; p-value 0.853 for user study and 0.646 for survey). Finally, the median response time was significantly lower for Type 4 than for Type 1-3 scenarios (the Mann-Whitney-Wilcoxon test; p-value 0.000). These results support the conclusion that SEALANT’s intent-exchange control choices are not more difficult than those of stock Android. H2 – I measured the proportion of instances in which a participant elected to block an intent exchange and prevent an attack in a Type 4 scenario. In general, users may deliberately allow vulnerable intent exchanges (e.g., a user trusts both apps). However, in my study, unbeknownst to the users, I only included paths actually leading to exploits, allowing me to know the correct behavior. Recall that one half of the apps in the Type 4 scenarios came from reliable and the other half from unreliable sources. In the combined Type 1 (credible apps) and Type 2 (unreliable apps) scenarios, participants chose to cancel installation 51% of the time. That tendency, halting an on-going activity to avoid security threats, was much higher for Type 4 scenarios. The 34 user study participants chose intent blocking 70% of the time, while 155 survey participants chose blocking 68% of the time. Participants were thus able to make intent-exchange choices that did not lead to inter-app attacks at a much higher rate than their “average” behavior. 89 4.2 Evaluation of SCUTUM SCUTUM was empirically evaluated in terms of its accuracy, applicability, and performance in detecting vulnerabilities from a target EBS. 4.2.1 Accuracy An ideal evaluation of SCUTUM’s accuracy would have included comparison of SCUTUM against existing vulnerability detection techniques for EBSs. However, the prototype implementations of those techniques are not publicly available [176,185]. Thus, I targeted vulnerability detection tools for web apps, because they fall under a particular type of EBS which can be implemented by using MOM platforms (see Section 2.2.2). Among the state-of-the-art static analysis tools for detecting security vulnerabilities in web apps [42], three tools were executable while supporting Java-based systems: Xanitizer [43], Owasp Orizon [40], and SonarQube [37]. I evaluated SCUTUM’s accuracy in identifying vulnerable event communication channels by comparing its results against those of Xanitizer, Owasp Orizon, and SonarQube. 4.2.1.1 Experimental Setup Since existing test benchmarks for web apps [39,66,105] neither target EBSs nor event attacks, I have created a test benchmark for evaluating security analysis techniques for EBSs. To minimize internal threats to the validity of results, I asked a graduate student at USC to build a set of apps that implement event attacks (types A1-A5) based on the published literature [68,74,129]. We built 20 distinct event-based apps by using two representative types of MOM platforms (10 apps for each platform): (1) Java Message Service (JMS) [31], the widely adopted Java-oriented middleware for exchanging messages between components; and (2) Prism-MW [1], a research-off-the-shelf, extensible 90 middleware platform that enables efficient implementation, deployment, and execution of distributed software systems. Every app was designed to contain a malicious component that had the sole purpose of launching an event attack. To ensure that event attacks can be actually launched, two graduate students at USC manually inspected the code of each app. By running each app on a PC, they also confirmed that the attacks are successfully launched at runtime. The benchmark also comprises five “trick” apps containing vulnerable but unreachable components, whose identification would be a false warning. This yielded a total of 25 event-based apps containing 20 vulnerable event communication channels. The benchmark is distributed on https://github.com/namdy0429/SCUTUM. 4.2.1.2 Results I evaluated SCUTUM’s accuracy in identifying vulnerable event communication channels in compar- ison to Xanitizer, Owasp Orizon, and SonarQube. Xanitizer statically detects security vulnerabilities such as injections and privacy leaks by using taint-flow analysis [43]. Owasp Orizon statically analyzes insecure code patterns by using pattern matching [40,41]. SonarQube identifies the insecurities in target code such as hard-coded passwords and badly managed errors [37]. I ran the three tools on my test benchmark and measured their (1) precision, i.e., identified vulnerabilities that were actually vulnerable to event attacks, and (2) recall, i.e., the ratio of identified vulnerabilities to all those exposed to event attacks. SCUTUM detected vulnerabilities—vulnerable event communication channels in particular—with 100% precision and recall, correctly ignoring all “trick” cases. However, other tools (i.e., Xanitizer, Owasp Orizon, and SonarQube) were unable to find any of the vulnerabilities related to event attacks from the benchmark. Specifically, Xanitizer did not return any vulnerabilities. While Owasp Orizon and SonarQube reported some security warnings (e.g., potential dangerous keyword in the method), they are not directly related to the 91 Table 4.5: Four Subject Systems and Results Name Type Event Mechanism SLOC No. of Identified Vulnerabilities SCUTUM Xanitizer Orizon SonarQube Dradel Software IDE [140] c2.fw [139] 11K 12 6 9 17 ERS Crisis Response [134] Prism-MW [135] 7K 11 62 1 73 KLAX Arcade Game [181] c2.fw [139], Java events 5K 2 15 3 5 vulnerabilities caused by event attacks. This is primarily because these three tools neither target event attacks nor support inter-component flow analysis. However, they support additional types of vulnerabilities such as resource leaks and security misconfiguration [37,40,43] which SCUTUM does not target. 4.2.2 Applicability To assess if SCUTUM is applicable to real-world EBSs, I selected eight EBSs (i.e., non-Android apps) from the test suite which have been used in evaluating prior research [95]. While all subject systems are implemented in Java, they are from different application domains (e.g., game, simulator, and chat system), of different sizes (5K-247K SLOC), and use different underlying mechanisms (e.g., c2.fw [138], Prism-MW [135], and REBECA [143]) for event communication. Since the list of sensitive APIs and trust boundaries were not provided for those systems, I ran SCUTUM with the configuration that every ‘getter’ or ‘setter’ method was a sensitive method and every component belonged to different trust boundaries. According to the well-known sensitive API list for Android [164], 81% of sensitive methods are either getters or setters (getters: 97%, setters: 65%), which implies that getters and setters are more likely to be sensitive to security attacks compared to other methods. However, it is important to note that this does not necessarily mean that all getters and setters are always sensitive methods. 92 Among the eight subject systems, SCUTUM flagged 25 vulnerable event communication channels in three systems (Dradel: 12,ERS: 11,KLAX: 2) as indicated in Table 4.5. Two graduate students at USC manually inspected each system’s code to check if the identified event communication channels are indeed vulnerable to event attacks. On average, the precision of result was 85.67% (Dradel: 75%, ERS: 82%, KLAX: 100%). Every false positive was caused by SCUTUM’s inaccuracy in identifying control-flows between sensitive methods and event interfaces. For those three systems, Xanitizer reported 83 security warnings such as “may expose internal representation by returning reference to mutable object” and “IO Stream Resource Leaks” (Dradel: 6, ERS: 62, KLAX: 15). However, only seven of them (8.43%) were related to the vulnerabilities that expose the system to event attacks. Owasp Orizon and SonarQube returned 13 (Dradel: 9, ERS: 1, KLAX: 3) and 95 (Dradel: 17, ERS: 73, KLAX: 5) implementation bugs, respectively, indicated as “empty catch detected” and “found potential dangerous keyword”. But none of them were related to the vulnerabilities that expose the system to event attacks. The three tools (i.e., Xanitizer, Owasp Orizon, and SonarQube) also did not return any such vulnerabilities from the other five subject systems. Although SCUTUM outperformed the three tools in this evaluation, it is to be noted that they detected additional types of vulnerabilities SCUTUM does not target. 4.2.3 Performance To evaluate the performance of SCUTUM, I tested it on the event-based apps comprising different numbers of components. I created four distinct apps by adding different numbers of components (i.e., 25, 50, 75, and 100, respectively) to an app randomly selected from my benchmark. To observe SCUTUM’s best-case performance overhead, each of the added components is designed to have a minimized architecture—containing one method for communicating with at most two other 93 Figure 4.1: SCUTUM’s Performance on Different Number of Components components (55 SLOC)—which would induce the shortest analysis time while connected with other components. The size of the apps spanned 2.8K-7K SLOC. None of the added components are involved in the vulnerable event communication channels so that they can be pruned in SCUTUM’s Reduction phase. I ran SCUTUM on each app using a PC with an Intel dual-core i5 2.7GHz CPU and 4GB RAM. On average, SCUTUM’s analysis took 115.04s (Extraction phase: 69.02s; Reduction and Iden- tification phase: 46.02s), which is efficient considering the fact that Xanitizer’s analysis on the 25-components-app took over an hour. To assess the effectiveness of SCUTUM’s pruning operation, I also measured its analysis time for each app “without” the Reduction phase. The result (see Fig- ure 4.1) indicates that as the number of added components increased, the difference of analysis time between “with” and “without” Reduction phase also increased. This result confirms that SCUTUM minimizes the potential overheads in its analysis by introducing the pruning operation. Considering the fact that the added components are designed to have a minimized architecture (i.e., one method 94 and two event communication channels; 55 SLOC), the effectiveness of pruning will drastically increase in the case of large-scale EBSs comprising a number of components with higher complexity. 95 4.3 Evaluation of ViVA 4.3.1 Usability To test Hypothesis 4, I conducted a user study that evaluates whether or not ViVA helps engineers identify security vulnerabilities that expose the system to event attacks. 4.3.1.1 Experimental Setup The participants include 30 computer science graduate students at USC, recruited via an e-mail list. The background survey indicated that the mean degree of the participants’ familiarity on software programming, mobile programming, and program analysis was 5.73 (Std: 1.00), 4.27 (Std: 1.71), and 4.90 (Std: 1.35), respectively (7-point Likert scales: 1 = not familiar at all, 7 = very familiar). There was a tutorial session prior to the user study in order to explain the basic concept of vulnerabilities that expose the system to event attacks. The user study comprised of three different sessions: • Session 1 (code inspection): The participants were asked to discover vulnerable ICC paths and components by inspecting the source code of target apps for 15 minutes. Each participant was provided with the source code of ten Android apps that were built by two graduate students at USC. Among those apps, there exist nine different vulnerabilities that expose the apps to event attacks (5 for types A1-A5; 2 for type A6; 2 for type A7). The participants were also provided with nine use-case scenarios that could trigger the attacks. Then they were asked to identify the vulnerabilities by inspecting the apps’ source code and submit the information of the identified vulnerable ICC paths and components. • Session 2 (runtime monitoring): The participants were asked to discover vulnerable ICC paths and components by examining runtime operation of target apps via both device screen 96 and logcat [15] for 15 minutes. Each participant was provided with (1) an Android device (i.e., Google’s Nexus 7) on which the ten apps were installed, (2) a PC connected with the Android device to display logcat output, and (3) the nine use-case scenarios. Participants were asked to run the apps based on the scenarios and inspect the logcat output. Whenever participants ran the apps, logcat automatically displayed the runtime logs. By interpreting the logcat’s output, the participants were asked to submit the information of the identified vulnerable ICC paths and components. • Session 3(visualization): For15minutes, theparticipantswereaskedtofindthevulnerabilities from the ten apps by using ViVA’s prototype which provided a compositional visualization of the apps and their vulnerabilities as depicted in Figure 3.9. Each participant was provided with mocked-up visualizations of ViVA as well as the nine use-case scenarios, and was asked to access and interpret them. This simulates the situation in which the participant already ran the apps based on the scenarios and ViVA visualized the collected data. The mocked-up visualizations of ViVA were based on the data I collected by running the apps using the scenarios. To this end, I installed and ran the apps on the device where the modified version of Android, which can print out the information of runtime intents (the same one used for SEALANT’s experiment in Section 4.1.1.3), was installed. The logged information of the intents was fed into ViVA. By interpreting ViVA’s visualization (different colors and widths of edges and components), the participants were asked to submit the information of the discovered vulnerable ICC paths and components. The sessions were based on the assumption that participants were already familiar with running Android device, apps, and tools (i.e., logcat and ViVA) which enable them to explore the desired 97 Table 4.6: The Number of Identified Vulnerabilities and The Level of Difficulty per Session Session Technique No. of Identified Vulnerabilities Difficulty Mean Std. Precision / Recall Mean Std. 1 Code inspection 0.48 1.45 2.87% / 1.53% 1.40 0.75 2 Runtime monitoring 0.00 0.00 0.00% / 0.00% 2.06 1.18 3 Visualization 6.76 1.90 98.55% / 75.00% 5.50 1.83 outputs. This is because the purpose of this test was to validate the effectiveness of runtime monitoring with visualization that ViVA provides, rather than to validate the ease of using the tools. To avoid the testing effects among sessions, participants were assigned with three consecutive sessions in different order (i.e., 5 participants for each of the following combination of sessions: 1-2-3, 1-3-2, 2-1-3, 2-3-1, 3-1-2, and 3-2-1). In addition, the target apps, components, and events were provided in different names for each session. At the end of the user study, the participants were asked to assess the level of difficulty (7-point Likert scales: 1 = very difficult, 7 = very easy) in using each technique for identifying vulnerabilities (i.e., code inspection, runtime monitoring, and visualization). 4.3.1.2 Results I compared the results of three sessions, especially focusing on (1) the number of identified vulnera- bilities and (2) the perceived level of difficulty. Table 4.6 presents the results I obtained. A comparison of the mean number of the identified vulnerabilities (Session 3: 6.76 > Session 1: 0.48 > Session 2: 0.00) indicated that in a certain period of time, participants identified more vulnerabilities by using ViVA in comparison to those by using other techniques (i.e., code inspection and runtime monitoring). Moreover, the precision and recall of the identified vulnerabilities by using ViVA are higher than those by using other techniques (Session 3: 98.55%/75.00% > Session 1: 98 2.87%/1.53% > Session 2: 0.00%/0.00%). This is primarily because while ViVA’s visualization delivers target EBS’s architectural information and runtime event communication in a compositional view, it is challenging to analyze the runtime operation of target system by using code inspection. Furthermore, while ViVA captures and visualizes every runtime event communication, runtime monitoring may miss some of them, because not all event exchanges are visible via device screen and logcat. The results support the conclusion that ViVA enables engineers to detect more vulnerabilities from a target EBS with higher accuracy compared to the existing techniques. To confirm if ViVA’s visualization is still effective for the vulnerabilities that are not statically analyzable (i.e., types A6 and A7)—main targets of ViVA—, I also compared the number of identified vulnerabilities that exposed the system to A6 and A7. While only four vulnerabilities were examined for types A6 and A7, the number of vulnerabilities reflects the minimum number of vulnerabilities typically found in a real usage setting: an average user regularly uses about 30 apps per month [21]; around 10% of Android apps are vulnerable to event attacks [57]; 59% of apps have 0-6 vulnerabilities and 41% of apps have 7+ vulnerabilities [5]. To implement two vulnerabilities that expose the apps to type A6, component c1 in app M1 (size: 125KB; number of components: 7) was designed to send intent i1 to component c2 in app V1 (size: 1.22MB; number of components: 6) for 100 times in a row and send intent i2 to component c3 in app V2 (size: 47KB; number of components: 4) for 100 times in a row. To implement two vulnerabilities that expose the apps to type A7, component c4 in app V1 was designed to send intent i3 to component c5 in app M2 (size: 1.17MB; number of components: 7) and send intent i4 to component c6 in M2. Components c5 and c6 were designed to delay their subsequent operation (i.e., publication of intents) for 5 seconds upon their consumption of i3 and i4, respectively: in Android, app responsiveness is monitored by checking whether an app responds to an input event within 5 seconds [16]. In ViVA’s visualization (see Figure 3.9), to 99 display the vulnerabilities for type A6, the corresponding ICC paths were displayed in thicker edges than others. To display the vulnerabilities for type A7, the names of the vulnerable components were displayed in different color, light blue. While none of the vulnerabilities for types A6 and A7 were discovered in Session 1 and Session 2, the mean number of the identified vulnerabilities in Session 3 was 2.36 (Std: 1.35) and their precision and recall was 99% and 59.00%, respectively. The false positive was caused by the incorrect name of component a participant carelessly filled in. The false negatives were mainly caused by the participants’ overlooking of the vulnerabilities for type A7. This might be induced by the type of visualization ViVA provided since the given visualization was more focused on highlighting edges between components than delivering information of components. However, this can be improved by providing different types of visualizations. Moreover, the result implies that ViVA’s visualization is still effective for types A6 and A7 compared to the existing techniques. A comparison of the mean level of difficulty (Session 3: 5.50 > Session 1: 2.06 > Session 2: 1.40) demonstrated that participants identified the vulnerabilities with less difficulty by using ViVA than by using other techniques. This is primarily because ViVA’s visualization delivers target EBS’s architectural information and runtime event communication intuitively and comprehensibly (e.g., distinguishing width of edges based on the number of exchanged events). Engineers are thus able to identify vulnerabilities more easily by using ViVA compared to the existing techniques. 100 4.4 Threats to Validity In SEALANT’s user study (Section 4.1.4), the participants were students. To address any resulting bias, Iadditionallyconductedthesurveywhoserespondents spanned avarietyofagesand occupations. The survey merely emulated a mobile environment, possibly influencing the participants’ choices. As a mitigation, I carefully described each scenario to provide the participants with the context they would have had if they had used an actual device. I also separately analyzed the user study and survey results, and both support my conclusions. Lastly, while I regard blocking an ICC that SEALANT identifies as vulnerable to be the appropriate choice in most cases, and consider the users’ choices to block70% of ICCs that would otherwise have remained uncaught as a positive result, the participants did elect to allow a fair portion (30%) of the vulnerable ICCs. This indicates that improvements may be possible with regards to how SEALANT presents the vulnerable ICCs to end-users. To evaluate SCUTUM’s accuracy and applicability (Section 4.2.1 and 4.2.2), EBSs from academic benchmark and open-source repository were used as test suites, which may be considered as an external validity. Specifically, in some aspects, they are not likely to be representative of real-world EBSs because of the following reasons: they might be relatively smaller in size compared to real-world EBSs; they were primarily developed for academic purposes; and some of them were developed by our research group. However, the benefits of using those EBSs are as follows. First of all, there were no other EBSs publicly available except for them. Moreover, they use a similar style of architecture and event communication mechanism with real-world EBSs as long as those are implemented by using the same MOM platforms. This is because the architecture and event communication model of EBSs primarily rely on the MOM platform they use. Furthermore, they represent a wide spectrum by selecting different types of domains (e.g., game, software IDE, and logger), sizes (5K-247K SLOC), 101 and various MOM platforms (e.g., SIENA, Prism-MW, and c2.fw) including popular ones (e.g., JMS) as discussed in Section 4.2.1 and Section 4.2.2. Meanwhile, to mitigate internal threats to the validity of evaluation results, more than half of EBSs (70%) in the test suites were externally developed. 102 Chapter 5 Related work This dissertation is related to several approaches that have been proposed to secure EBSs. This chapter discusses the approaches for securing EBSs including Android and web apps as well as the visualization techniques in the following four sections: Section 5.1 introduces prior works regarding security techniques for EBSs. Section 5.2 and Section 5.3 discuss a review of security techniques for Android and web apps, respectively. Lastly, Section 5.4 covers related work in the area of visualization techniques. 5.1 Security in Event-Based Systems Several approaches have targeted the security in EBSs [47,59,154,189,197,199]. Simeon et al. [199] examined the security vulnerabilities of event-driven systems and defined the conditions that produce them. ExistingsecuritysolutionsforEBSemployencryption and/orruntimeaccesscontroltechniques in general. Among many, I highlight the most closely related work. Encryption is a widely used technique for securing not only general software systems, but also EBSs [144,161,177,178,180]. EventGuard [178] proposes encryption for publish/subscribe systems in which each component encrypts events through event broker network. Publishers sign events and 103 encrypt them with a random key, while the signature itself is encrypted with a topic-specific key and is attached to the event. Event brokers verify the publishers’ signatures during event routing. PSGuard [177] proposes a key management technique by defining encryption keys according to content-based subscriptions. Costi et al. [161] focused on studying confidentiality for commonly used apps and subscription languages in content-based event communication. They embedded practical solutions in the implementation of Siena, a popular content-based publish/subscribe system. Mohamed et al. [144] proposed an approach to preserve the privacy of the subscriptions and confidentiality of the published data by using cryptographic techniques. However, encryption techniques increase the risk of compromised keys and may cause unacceptable performance overhead. Furthermore, key distribution is inappropriate when it is not determined which component will comprise the system. Runtime access control is another popular technique for securing EBSs [54,70,78,152,174,175,198]. Alex et al. [198] proposed a policy model and framework for content-based publish/subscribe (CPS) systems, which benefits from the scalability and expressiveness of CPS matching algorithms. Their implementation enabled notification semantics, meta-events, security zoning, and CPS firewalls. Singh et al. [175] introduced IC (interaction control), a policy model that overlays context-aware, point-to point controls onto a publish/subscribe network. This approach enables a granular control over the information flows within the network by enforcing policies only where necessary at specific points of the publish/subscribe process. Chun et al. [70] proposed an access control model which captures the path history of particular components and reaches a decision according to whether the path matches a path pattern set. PrivateFlow [152] is a publish/subscribe prototype that guarantees the confidentiality of user’s data. It is supported by decentralized information flow control using a taint-tracking mechanism. 104 Role-based access control is a large body of runtime access control techniques for EBSs [55,91,142, 170]. It maintains the policies that determine the components that are authorized for particular event- related behaviors, such as publication and consumption of events. Scope [91] proposes a grouping structure that limits event visibility. OASIS role-based access control [170] allows administration of distributed security policy, with parametrized roles and appointment certificates. OASIS secures not only individual events, but also the entire system by supporting evolving rules and event structures for long-lived systems and data. Andras et al. [62] introduced the integration of OASIS role-based access control into Hermes [156], a publish/subscribe middleware platform. This system supports advanced features, such as the ability to work within a network where components are attributed by different levels of trust, and employs a variety of access restriction methods which balance the expressiveness with the content-based routing optimization. However, grouping and assigning roles require general knowledge of component types, which may not work for the systems containing unknown types of components. Furthermore, malicious components may bypass the restrictions of role-based access control (e.g., privilege escalation attacks in Android [68]). 5.2 Security in Android This research is related to the approaches for security in Android communication model. A lot of effort has been dedicated to identifying security vulnerabilities in Android and preventing potential exploitations. Existing approaches for Android’s security vulnerabilities are based on program analysis and/or policy enforcement in general. Here I highlight the most closely related work. Program analysis has been employed by several approaches [49,72,74,85,89,93,98,100,101,109,120, 136,167,202–204,211]. ComDroid [74] categorizes security vulnerabilities in inter-app communication and detects vulnerabilities residing in a target app by using static analysis. FlowDroid [49] provides 105 intra-component taint-flow analysis to detect data leaks. CHEX [133] leverages data-flow analysis to discover component hijacking vulnerabilities. However, these techniques mainly focused on individual component, which may miss the compositional vulnerabilities between multiple components such as event attacks. Inter-component communication (ICC) analysis is a large body of program analysis research for Android [56,61,75,84,87,122,130–132,147–149,165,171,193,195,196,209]. Epicc [149] and IC3 [147] statically analyze the specification of ICC in Android apps and extract information from Android apps for ICC-aware analyses. DidFail [122] uses taint-flow analysis to locate sensitive inter-app data-flows, but targets only Activity components and neglects intents’ data scheme. AmanDroid [193] identifies privacy leaks by tracking components interactions, but has been shown to work incorrectly on Content Provider components and certain ICC methods (e.g., startActivityForResult). IccTA [130,132] is a taint-flow analysis targeting privacy leaks. While instrumenting source code to resolve the connections between components does improve its precision, it does not target other types of event attacks. COVERT [56] introduces a compositional analysis of inter-app vulnerabilities, especially against permission leakage. However, it does not target other types of event attacks or handle intents’ data scheme. Policy enforcement inAndroidisexploredvia(1)appcodeinstrumentation[52,57,60,73,79,80,114, 163,200,206], (2) Android framework extension [68,69,82,85,86,90,107,150,169,208], and (3) dynamic memory instrumentation [58,190]. Aurasium [200] enforces arbitrary policies by interposing code into the target app in order to limit the app’s security and privacy violations. DroidForce [163] enforces custom data-centric policies by instrumenting an app’s bytecode. DroidGuard [57] automatically synthesizes and enforces security policies, allowing end-users to safeguard the apps installed on their devices from inter-app vulnerabilities. While rewriting apps can be effective, incomplete 106 implementations of bytecode rewriting results in a number of potential attacks [103]. Moreover, since repackaging assigns a different signature to a target app, it no longer shares history information with the original app and cannot be updated by the original issuer. Saint [150] extends Android to enable control of an app’s behavior via app provider’s policies. XmanDroid [68] also extends the monitoring mechanism of Android to prevent app-level privilege escalation attacks based on permission-based policies. ASM [106] provides a programmable interface that enables enforcement of app-specific security requirements. However, end-users typically lack expertise in devising policies, and have to rely on general coarse-grain policies written by experts. DeepDroid [190] provides enterprise policy enforcement by applying dynamic memory instrumen- tation (i.e., “rooting”) to Android’s runtime environment. SEPAR [58] automatically synthesizes security policies, which it also enforces through dynamic memory instrumentation that hooks the original method calls of target applications at runtime. However, rooting may introduce subsequent vulnerabilities [14] and compatibility issues on custom ROM. 5.3 Security in Web Applications To reduce the inherent security risks of web apps [4], a number of techniques have been developed [44– 46,59,63,81,102,110,124,145,157,166,176,185,188,212]. Static code analysis is a popular technique for inspecting security flaws in web apps. SABER [166] is a static analysis tool that detects common design errors based on the instantiations of error pattern templates. Andromeda [185] inspects data-flow propagations on demand, while supporting apps written in Java, .NET, and JavaScript. PQL (Program Query Language) [124] allows engineers to specify information flow patterns succinctly and declaratively. Derailer [145] finds security bugs in web apps using symbolic execution. It enumerates the ways in which data might be exposed, 107 asks a user to examine the surfaces where data might be exposed, and constructs a security policy. Xanitizer [43] statically detects security vulnerabilities such as injections and privacy leaks by using taint-flow analysis. Owasp Orizon [40] is a source code security scanner designed to spot vulnerabilities in J2EE web apps by using pattern matching. SonarQube [37] is an open source platform for continuous inspection of code quality to detect security vulnerabilities. Runtime protection is also widely used to mitigate security threats in web apps. F4F (Frame- work For Frameworks) [176] is a system for effective taint analysis of framework-based web apps. WebSSARI [110] is a dynamic system that detects failures and validates input/output in PHP apps. DEFCon [157] is a middleware that applies an information flow control model which tracks the event flows through a complex, heterogeneous event processing system and constrains undesirable event flows that could potentially violate security policy. It provides end-to-end security guarantees to event processing apps. Ryck et al. [81] presented an architecture of security middleware, which provides a reusable solution supporting complex security requirements. Zhou et al. [212] presented an automated approach to instrument an app’s source code to report failed access attempts that may bypass its runtime protection. However, aforementioned techniques are more focused on other types of security issues than event attacks. Furthermore, since those techniques do not fully support event-based communication model, they may suffer from inaccuracy and scalability problems in analyzing large-scale web apps comprising a number of components. 108 5.4 Visualization This research employs a visualization technique widely used to help engineers understand and analyze target software systems. VisPub [123] is a tool for visualizing performance metrics in topic- based publish/subscribe systems, ranging from dissemination of publications to overlay properties. VisTracer [92] displays analysis results of anomaly detection on large traceroute data sets with the help of scalable representations such as pixel-based visualization. CluVis [191] is a visual monitoring tool which depicts an active chart on each node of a computer cluster or communication network while displaying the relationships between the explored charts. In security domains, visualization techniques have been widely adopted in order to aid engineers to identify security vulnerabilities in target systems. ASTRAEA [159], a privacy-enforcement system for Android and iOS, displays its analysis results on top of a visual representation of target app’s UI. Goodall et al. [99] designed a system that combines the results of disparate software analysis tools with visual environment. This system enables engineers to triage the most important code weaknesses and identify the part that introduces software vulnerabilities. SRNET [118] is a visualization system for analyzing and detecting complex patterns of sensor network attacks. The root causes of network attacks can be identified through visualizing network traffic data on its multiple coordinated views. MVS [126] increases the meaningfulness of security metrics by connecting the practical measurement values with the derived security metrics through hierarchical representation. However, these techniques neither target EBS nor vulnerabilities that expose the system to event attacks. Although COVERT [56] has a feature that visualizes its vulnerability analysis results, it neither supports compositional visualization of a large number of components nor runtime monitoring of event communication. 109 Chapter 6 Conclusion Event-based systems (EBSs) follow a particular inter-component communication mechanism in which components do not directly call other components, but rely on brokers to transfer notifications of events. Components in EBS may not know the consumers of the events they publish, nor do they necessarily know the producers of events they consume. Also, the published events are processed non-deterministically. While this mechanism enables highly decoupled, scalable, and easy-to-evolve systems, the non-determinism in event processing can be exploited by event attacks. Existing solutions for general software systems cannot be directly applied to resolve event attacks because they do not support event-based communication model. Although several approaches have been proposed to secure EBSs, the fundamental security flaws, which can be exploited by event attacks, have not been clearly identified yet. Furthermore, existing security solutions targeting EBSs do not appropriately resolve event attacks or suffer from inaccuracy in detecting event attacks. To minimize the risk of event attacks, this dissertation presented four essential approaches: 1. A new taxonomy for security flaws in EBS, which can serve as a basis for resolving event attack problems—The taxonomy defines and classifies different types of security flaws in EBSs. It also provides the relationships among the security flaws, event attacks, and existing solutions. 110 2. SEALANT, a novel protection mechanism for Android—SEALANT monitors and protects ICC paths through which event attacks can take place. Its novel combination of static and dynamic analysis improves upon existing techniques in automatically identifying the vulnerable ICC paths between a given set of apps, monitoring each instance of ICC to detect potential attacks, and empowering end-users to block the attacks as they happen. 3. SCUTUM, a novel vulnerability detection technique for EBSs that are implemented by using MOM platforms—SCUTUM statically analyzes vulnerabilities by examining inter-component flows and event communication patterns. It improves upon existing techniques in detecting vulnerabilities that expose the system to event attacks from a given EBS, while supporting multiple types of MOM platforms and increasing the coverage, accuracy, and scalability of vulnerability detection. 4. ViVA, a new visualization technique for inspecting security vulnerabilities in EBS—ViVA aids engineers to analyze runtime event communication between components and identify security vulnerabilities that expose the system to event attacks. It visualizes a target EBS’s runtime event communication on top of a visual representation of the target EBS’s architectural elements. In this dissertation, the proposed approaches, SEALANT, SCUTUM, and ViVA have been evaluated both empirically and analytically. My empirical evaluation shows that SEALANT is efficient and scalable while exhibiting high precision and recall with respect to identification and control of vulnerable ICC paths in 1,150 Android apps. Analytical comparisons with SEPAR [58], DroidGuard [57], and XmanDroid [68], the state-of-the-art protection techniques for Android, show that, SEALANT is able to prevent event attacks more accurately. A user study involving 189 111 Android end-users shows that end-users are able to effectively use SEALANT to halt vulnerable event exchanges and do not find it burdensome to use. Another empirical evaluation demonstrates that SCUTUM is more accurate in identifying vulnerable event communication channels from 33 EBSs compared to Xanitizer [43] and Owasp Orizon [40], the state-of-the-art vulnerability detection techniques for web apps. The result of SCUTUM’s performance analysis shows that SCUTUM is scalable to large-scale EBSs. Lastly, a user study involving 30 engineers shows that engineers can identify vulnerabilities that expose the system to event attacks by using ViVA more accurately and easily compared to those using code inspection and runtime monitoring. The proposed approaches are not limited to the form as presented in this dissertation, and their variations may also benefit from securing EBSs as follows: • To provide non-expert users with more specific guidance in controlling event communica- tion, SEALANT can build a statistical model by collecting end-users’ choices over time and recommend “correct” choices that likely not lead to event attacks. • The effectiveness of runtime monitoring relies on the coverage of test cases. To extend the coverage of test cases, ViVA can incorporate other dynamic testing techniques such as fuzzing [201,205]. • Depending on the type of display (e.g., different notations and colors), the effectiveness of visualization can be affected. Consequently, this can affect engineers’ understanding of target EBSs and identifying vulnerabilities. To handle this, ViVA can build a statistical model that collects engineers’ assessments on each type of display and recommend the most efficient visualization depending on the type of target EBS. 112 References [1] Prism-MW - Architectural Middleware for Mobile and Embedded Systems. http://sunset. usc.edu/~softarch/Prism/, 2001. [Online; accessed July 18, 2017]. [2] 2012 Norton Cybercrime Report. http://www.norton.com/2012cybercrimereport, 2012. [Online; accessed September 16, 2015]. [3] Gartner says worldwide pc, tablet and mobile phone combined shipments to reach 2.4 billion units in 2013. http://www.gartner.com/newsroom/id/2408515, 2013. [Online; accessed April 15, 2015]. [4] Top 10 2013 - OWASP. https://www.owasp.org/index.php/Top_10_2013-Top_10, 2013. [Online; accessed September 20, 2016]. [5] 70% Of The Mobile Banking Android Apps Are Vulnerable: Appvigil. http://trak.in/ tags/business/2015/04/02/mobile-banking-android-apps-vulnerable/, 2015. [Online; accessed August 16, 2016]. [6] Android Debug Bridge. http://developer.android.com/tools/help/adb.html, 2015. [On- line; accessed August 16, 2016]. [7] Android Open Source Project. https://source.android.com, 2015. [Online; accessed August 16, 2016]. [8] Bazaar. http://cafebazaar.ir, 2015. [Online; accessed August 16, 2016]. [9] Download APK Android Apps and Games. http://www.appsapk.com, 2015. [Online; accessed August 16, 2016]. [10] DroidBench: A micro-benchmark suite to assess the stability of taint-analysis tools for Android. https://github.com/secure-software-engineering/DroidBench, 2015. [Online; accessed April 29, 2015]. [11] Google Play. http://play.google.com/store/apps, 2015. [Online; accessed August 20, 2016]. [12] IDC: Smartphone OS Market Share. http://www.idc.com/prodserv/ smartphone-os-market-share.jsp, 2015. [Online; accessed August 20, 2015]. [13] Intents and Intent Filters | Android Developers. https://developer.android.com/guide/ components/intents-filters.html, 2015. [Online; accessed August 16, 2016]. 113 [14] Is Rooting Your Phone Safe? The Security Risks of Root- ing Devices. https://insights.samsung.com/2015/10/12/ is-rooting-your-phone-safe-the-security-risks-of-rooting-devices, 2015. [Online; accessed August 20, 2015]. [15] Keeping Your App Responsive | Android Developers. http://developer.android.com/ training/articles/perf-anr.html, 2015. [Online; accessed August 16, 2016]. [16] Keeping Your App Responsive | Android Developers. https://developer.android.com/ training/articles/perf-anr.html, 2015. [Online; accessed August 16, 2016]. [17] logcat Command-line Tool | Android Studio. https://developer.android.com/studio/ command-line/logcat.html, 2015. [Online; accessed August 16, 2016]. [18] monkeyrunner | Android Studio. https://developer.android.com/studio/test/ monkeyrunner, 2015. [Online; accessed August 16, 2016]. [19] Run Apps on the Android Emulator | Android Studio. https://developer.android.com/ studio/run/emulator.html, 2015. [Online; accessed August 16, 2016]. [20] Running Builds–Booting into Fastboot Mode. https://source.android.com/source/ running.html#booting-into-fastboot-mode, 2015. [Online; accessed August 16, 2016]. [21] So Many Apps, So Much Time For Entertainment. http://www.nielsen.com/us/en/ insights/news/2015/so-many-apps-so-much-more-time-for-entertainment.html, 2015. [Online; accessed August 16, 2016]. [22] UI/Application Exerciser Monkey | Android Studio. http://developer.android.com/tools/ help/monkey.html, 2015. [Online; accessed August 16, 2016]. [23] Which methods should be considered “Sources”, “Sinks” or “Sanitization”? http:// thecodemaster.net/methods-considered-sources-sinks-sanitization/, 2015. [Online; accessed August 16, 2016]. [24] android.app | Android Developers. http://developer.android.com/reference/android/ app/package-summary.html, 2016. [Online; accessed August 16, 2016]. [25] apps-for-android — Google Code Archive. https://code.google.com/archive/p/ apps-for-android/, 2016. [Online; accessed August 16, 2016]. [26] D3.js - Data-Driven Documents. https://d3js.org/, 2016. [Online; accessed September 27, 2016]. [27] Dashboards | Android Developers. https://developer.android.com/about/dashboards, 2016. [Online; accessed August 16, 2016]. [28] Developer error: The most dangerous programming mistakes | InfoWorld. http://www.infoworld.com/article/2622611/application-security/ developer-error--the-most-dangerous-programming-mistakes.html, 2016. [Online; accessed September 25, 2016]. 114 [29] F-Droid – Free and Open Source Android App Repository. https://f-droid.org, 2016. [Online; accessed August 16, 2016]. [30] IccTA. http://sites.google.com/site/icctawebpage, 2016. [Online; accessed August 16, 2016]. [31] Java Message Service (JMS). http://www.oracle.com/technetwork/java/jms/index.html, 2016. [Online; accessed September 16, 2016]. [32] Siena: A Wide-Area Event Notification Service. http://www.inf.usi.ch/carzaniga/siena/, 2016. [Online; accessed August 16, 2016]. [33] Sourcecodester.com. http://www.sourcecodester.com/android, 2016. [Online; accessed August 16, 2016]. [34] Welcome To CORBA Web Site! http://www.corba.org/, 2016. [Online; accessed August 16, 2016]. [35] APKExpansionFiles|AndroidDevelopers. https://developer.android.com/google/play/ expansion-files.html, 2017. [Online; accessed August 15, 2017]. [36] Bootstrap. http://getbootstrap.com/, 2017. [Online; accessed June 28, 2017]. [37] Continuous Code Quality | SonarQube. https://www.sonarqube.org/, 2017. [Online; ac- cessed October 10, 2017]. [38] jQuery. https://jquery.com/, 2017. [Online; accessed June 28, 2017]. [39] Owasp Benchmark. https://www.owasp.org/index.php/Benchmark, 2017. [Online; accessed July 29, 2017]. [40] Owasp Orizon. https://www.owasp.org/index.php/Category:OWASP_Orizon_Project, 2017. [Online; accessed July 27, 2017]. [41] Owasp Top10 2013. https://www.owasp.org/index.php/Top_10_2013, 2017. [Online; ac- cessed July 31, 2017]. [42] Source Code Analysis Tools - OWASP. https://www.owasp.org/index.php/Source_Code_ Analysis_Tools, 2017. [Online; accessed October 9, 2017]. [43] Xanitizer. https://www.rigs-it.net/index.php/product.html, 2017. [Online; accessed July 27, 2017]. [44] Leman Akoglu and Christos Faloutsos. Anomaly, Event, and Fraud Detection in Large Network Datasets. In Proceedings of the 6th ACM International Conference on Web Search and Data Mining (WSDM), pages 773–774, 2013. [45] Chris Allan, Pavel Avgustinov, Aske Simon Christensen, Laurie Hendren, Sascha Kuzins, Ondřej Lhoták, Oege de Moor, Damien Sereni, Ganesh Sittampalam, and Julian Tibble. Adding Trace Matching with Free Variables to AspectJ. SIGPLAN Not., 40(10):345–364, October 2005. 115 [46] Anh Nguyen-Tuong, Salvatore Guarnieri, Doug Greene, Jeff Shirley, and David Evans. Au- tomatically Hardening Web Applications Using Precise Tainting. In Proceedings of the 20th IFIP International Information Security Conference (SEC), pages 295–308, 2005. [47] Leonardo Aniello, Roberto Baldoni, Claudio Ciccotelli, Giuseppe Antonio Di Luna, Francesco Frontali, and Leonardo Querzoni. The Overlay Scan Attack: Inferring Topologies of Distributed Pub/Sub Systems Through Broker Saturation. In Proceedings of the 8th ACM International Conference on Distributed Event-Based Systems (DEBS), pages 107–117, 2014. [48] Farooq Anjum, Dhanant Subhadrabandhu, and Saswati Sarkar. Signature based intrusion detection for wireless ad-hoc networks: A comparative study of various routing protocols. In Vehicular Technology Conference (VTC), volume 3, pages 2152–2156, October 2003. [49] Steven Arzt, Siegfried Rasthofer, Christian Fritz, Eric Bodden, Alexandre Bartel, Jacques Klein, Yves Le Traon, Damien Octeau, and Patrick McDaniel. Flowdroid: Precise Context, Flow, Field, Object-Sensitive and Lifecycle-Aware Taint Analysis for Android Apps. In Proceedings of the 35th annual ACM SIGPLAN conference on Programming Language Design and Implementation (PLDI), pages 259–269, 2014. [50] T. Aslam. A taxonomy of Security Faults in the Unix Operating System. M.S. Thesis, Purdue University, 1995. [51] Kathy Wain Yee Au, Yi Fan Zhou, Zhen Huang, and David Lie. PScout: Analyzing the Android Permission Specification. In Proceedings of the 19th ACM Conference on Computer and Communications Security (CCS), pages 217–228, 2012. [52] Michael Backes, Sebastian Gerling, Christian Hammer, Matteo Maffei, and Philipp von Styp- Rekowsky. AppGuard: Enforcing User Requirements on Android Apps. In Proceedings of the 19th International Conference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS), pages 543–548, 2013. [53] JeanBacon, DavidEyers, JatinderSingh, BrianShand, MatteoMigliavacca, andPeterPietzuch. Security in Multi-domain Event-based Systems. it-Information Technology Methoden und innovative Anwendungen der Informatik und Informationstechnik, 51(5):277–284, 2009. [54] Jean Bacon, David M. Eyers, Jatinder Singh, and Peter R. Pietzuch. Access Control in Pub- lish/Subscribe Systems. In Proceedings of the Second International Conference on Distributed Event-based Systems (DEBS), pages 23–34, 2008. [55] Jean Bacon, Ken Moody, and Walt Yao. A Model of OASIS Role-based Access Control and Its Support for Active Security. ACM Trans. Inf. Syst. Secur., 5(4):492–540, November 2002. [56] Hamid Bagheri, Alireza Sadeghi, Joshua Garcia, and Sam Malek. COVERT: Compositional Analysis of Android Inter-App Permission Leakage. IEEE Transactions on Software Engineer- ing, 41(9):866–886, September 2015. [57] Hamid Bagheri, Alireza Sadeghi, Reyhaneh Jabbarvand, and Sam Malek. Automated Dynamic Enforcement of Synthesized Security Policies in Android. Technical Report GMU-CS-TR-2015- 5, George Mason University, 2015. 116 [58] Hamid Bagheri, Alireza Sadeghi, Reyhaneh Jabbarvand, and Sam Malek. Practical, Formal Synthesis and Automatic Enforcement of Security Policies for Android. In Proceedings of the 46th IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), pages 514–525, 2016. [59] Fernando J. Barros. Semantics of Dynamic Structure Event-based Systems. In Proceedings of the Second International Conference on Distributed Event-based Systems (DEBS), pages 245–252, 2008. [60] Alexandre Bartel, Jacques Klein, Martin Monperrus, Kevin Allix, and Yves Le Traon. Improv- ing Privacy on Android Smartphones through In-Vivo Bytecode Instrumentation. Technical report, University of Luxembourg, 2012. [61] S. Bartsch, B. Berger, M. Bunke, and K. Sohr. The Transitivity-of-Trust Problem in Android Application Interaction. In Proceedings of the 8th International Conference on Availability, Reliability and Security (ARES), pages 291–296, 2013. [62] András Belokosztolszki, David M. Eyers, Peter R. Pietzuch, Jean Bacon, and Ken Moody. Role-Based Access Control for Publish/Subscribe Middleware Architectures. In Proceedings of the 2nd International Workshop on Distributed Event-Based Systems (DEBS), pages 1–8, 2003. [63] Cor-Paul Bezemer, Ali Mesbah, and Arie van Deursen. Automated Security Testing of Web Widget Interactions. In Proceedings of the the 7th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on The Foundations of Software Engineering (ESEC/FSE), pages 81–90, 2009. [64] F. Biscotti et al. Market Share: AIM and Portal Software, Worldwide, 2009. Gartner Market Research Report, 2010. [65] F. Biscotti and A Raina. Market Share Analysis: Application Infrastructure and Middleware Software, Worldwide, 2011. Gartner Market Research Report, 2012. [66] Stephen M. Blackburn, Robin Garner, Chris Hoffmann, Asjad M. Khang, Kathryn S. McKinley, Rotem Bentzur, Amer Diwan, Daniel Feinberg, Daniel Frampton, Samuel Z. Guyer, Martin Hirzel, Antony Hosking, Maria Jump, Han Lee, J. Eliot B. Moss, Aashish Phansalkar, Darko Stefanović, Thomas VanDrunen, Daniel von Dincklage, and Ben Wiedermann. The DaCapo Benchmarks: Java Benchmarking Development and Analysis. In Proceedings of the 21st Annual ACM SIGPLAN Conference on Object-oriented Programming Systems, Languages, and Applications (OOPSLA), pages 169–190, 2006. [67] Sven Bugiel, Lucas Davi, Alexandra Dmitrienko, Thomas Fischer, and Ahmad-Reza Sadeghi. XManDroid: A New Android Evolution to Mitigate Privilege Escalation Attacks. Technical Report TR-2011-04, Technische Universität Darmstadt, 2011. [68] Sven Bugiel, Lucas Davi, Ra Dmitrienko, and Thomas Fischer. Towards Taming Privilege- Escalation Attacks on Android. In Proceedings of the 19th Annual Network & Distributed System Security Symposium (NDSS), 2012. 117 [69] Sven Bugiel, Stephan Heuser, and Ahmad-Reza Sadeghi. Flexible and Fine-grained Mandatory Access Control on Android for Diverse Security and Privacy Policies. In Proceedings of the 22nd USENIX Conference on Security (USENIX Security), pages 131–146, 2013. [70] Chun Cao and Jian Lu. A Path-History-Sensitive Access Control Model for Mobile Agent Environment. In Proceedings of the Third International Workshop on Mobile Distributed Computing (ICDCSW), pages 660–663, 2005. [71] StuartKCard, JockDMackinlay, andBenShneiderman. Readings in information visualization: using vision to think. Morgan Kaufmann, 1999. [72] Patrick P.F. Chan, Lucas C.K. Hui, and S. M. Yiu. DroidChecker: Analyzing Android Applications for Capability Leak. In Proceedings of the 5th Conference on Security and Privacy in Wireless and Mobile Networks (WISEC), pages 125–136, 2012. [73] Kevin Zhijie Chen, Noah Johnson, Shuaifu Dai, Kyle Macnamara, Tom Magrino, Edward Wu, Martin Rinard, and Dawn Song. Contextual Policy Enforcement in Android Applications with Permission Event Graphs. In Proceedings of the 20th Annual Network & Distributed System Security Symposium (NDSS), 2013. [74] Erika Chin, Adrienne Porter Felt, Kate Greenwood, and David Wagner. Analyzing Inter- Application Communication in Android. In Proceedings of the 9th International Conference on Mobile Systems, Applications, and Services (MobiSys), pages 239–252, 2011. [75] Kwanghoon Choi and Byeong-Mo Chang. A Type and Effect System for Activation Flow of Components in Android Programs. Information Processing Letters, 114(11):620–627, November 2014. [76] JM Correira et al. Market Share: AIM and Portal Software, Worldwide, 2005. Gartner Market Research Report, 2006. [77] Gianpaolo Cugola et al. The JEDI Event-Based Infrastructure and Its Application to the Development of the OPSS WFMS. IEEE TSE, 2001. [78] Shalvi Dave, Jimit Mahadevia, and Bhushan Trivedi. Security Policy Implementation Using Connection and Event Log to Achieve Network Access Control. In Proceedings of the Interna- tional Conference on Advances in Computing and Artificial Intelligence (ACAI), pages 29–33, 2011. [79] Benjamin Davis and Hao Chen. RetroSkeleton: Retrofitting Android Apps. In Proceeding of the 11th Annual International Conference on Mobile Systems, Applications, and Services (MobiSys), pages 181–192, 2013. [80] Benjamin Davis, Ben Sanders, Armen Khodaverdian, and Hao Chen. I-ARM-Droid: A Rewriting Framework for In-App Reference Monitors for Android Applications. In Proceedings of the Mobile Security Technologies (MoST), 2012. 118 [81] Philippe De Ryck, Lieven Desmet, and Wouter Joosen. Middleware Support for Complex and Distributed Security Services in Multi-tier Web Applications. In Proceedings of the Third International Conference on Engineering Secure Software and Systems (ESSoS), pages 114–127. Springer-Verlag, 2011. [82] Michael Dietz, Shashi Shekhar, Yuliy Pisetsky, Anhei Shu, and Dan S. Wallach. Quire: Lightweight Provenance for Smart Phone Operating Systems. In Proceedings of the 20th USENIX Conference on Security (SEC), pages 23–23, 2011. [83] V. S. Dolk, P. Tesi, C. De Persis, and W. P. M. H. Heemels. Event-triggered control systems underdenial-of-serviceattacks. IEEE Transactions on Control of Network Systems, 4(1):93–105, Mar 2017. [84] Karim O Elish, Danfeng Yao, and Barbara G Ryder. On the Need of Precise Inter-App ICC Classification for Detecting Android Malware Collusions. In Proceedings of IEEE Mobile Security Technologies (MoST), in conjunction with the IEEE Symposium on Security and Privacy, 2015. [85] William Enck, Peter Gilbert, Byung-Gon Chun, Landon P. Cox, Jaeyeon Jung, Patrick McDaniel, and Anmol N. Sheth. TaintDroid: An Information-flow Tracking System for Realtime Privacy Monitoring on Smartphones. In Proceedings of the 9th USENIX Conference on Operating Systems Design and Implementation (OSDI), pages 393–407, 2010. [86] William Enck, Machigar Ongtang, and Patrick McDaniel. On Lightweight Mobile Phone Application Certification. In Proceedings of the 16th ACM Conference on Computer and Communications Security (CCS), pages 235–245, 2009. [87] Michael D. Ernst, René Just, Suzanne Millstein, Werner Dietl, Stuart Pernsteiner, Franziska Roesner, Karl Koscher, Paulo Barros Barros, Ravi Bhoraskar, Seungyeop Han, Paul Vines, and Edward X. Wu. Collaborative Verification of Information Flow for a High-Assurance App Store. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 1092–1104, 2014. [88] P.T. Eugster et al. The Many Faces of Publish/Subscribe. ACM Computing Surveys (CSUR), June 2003. [89] Adrienne Porter Felt, Erika Chin, Steve Hanna, Dawn Song, and David Wagner. Android Permissions Demystified. In Proceedings of the 18th ACM Conference on Computer and Communications Security (CCS), pages 627–638, 2011. [90] Adrienne Porter Felt, Helen J. Wang, Alexander Moshchuk, Steven Hanna, and Erika Chin. Per- mission Re-delegation: Attacks and Defenses. In Proceedings of the 20th USENIX Conference on Security (SEC), pages 22–22, 2011. [91] Ludger Fiege, Mira Mezini, Gero Mühl, and Alejandro P. Buchmann. Engineering Event-Based Systems with Scopes. In Proceedings of the 16th European Conference on Object-Oriented Programming (ECOOP), pages 309–333, 2002. 119 [92] Fabian Fischer, Johannes Fuchs, Pierre-Antoine Vervier, Florian Mansmann, and Olivier Thonnard. VisTracer: A Visual Analytics Tool to Investigate Routing Anomalies in Traceroutes. In Proceedings of the Ninth International Symposium on Visualization for Cyber Security (VizSec), pages 80–87, 2012. [93] Adam P. Fuchs, Avik Chaudhuri, and Jeffrey S. Foster. SCanDroid: Automated Security Certification of Android Applications. Technical report, University of Maryland, 2009. [94] Joshua Garcia, Daniel Popescu, George Edwards, and Nenad Medvidovic. Toward a Catalogue of Architectural Bad Smells. In Proceedings of the 5th International Conference on the Quality of Software Architectures: Architectures for Adaptive Software Systems (QoSA), pages 146–162, 2009. [95] JoshuaGarcia, DanielPopescu, GholamrezaSafi, WilliamG.J.Halfond, andNenadMedvidovic. Identifying Message Flow in Distributed Event-Based Systems. In Proceedings of the 9th Joint Meeting on Foundations of Software Engineering (ESEC/FSE), pages 367–377, 2013. [96] Kang Su Gatlin. Trials and Tribulations of Debugging Concurrency. ACM Queue, 2(7):66–73, October 2004. [97] GenericModelingEnvironment(GME). http://isis.vanderbilt.edu/projects/gme/, 2014. [Online; accessed August 16, 2016]. [98] ClintGibler, JonathanCrussell, JeremyErickson, andHaoChen. AndroidLeaks: Automatically Detecting Potential Privacy Leaks in Android Applications on a Large Scale. In Proceedings of the 5th International Conference on Trust and Trustworthy Computing (TRUST), pages 291–307, 2012. [99] John R. Goodall, Hassan Radwan, and Lenny Halseth. Visual Analysis of Code Security. In Proceedings of the 7th International Symposium on Visualization for Cyber Security (VizSec), pages 46–51, 2010. [100] Michael I Gordon, Deokhwan Kim, Jeff H Perkins, Limei Gilham, Nguyen Nguyen, and Martin C Rinard. Information Flow Analysis of Android Applications in DroidSafe. In Proceedings of the 22nd Annual Network & Distributed System Security Symposium (NDSS), 2015. [101] Michael C Grace, Yajin Zhou, Zhi Wang, and Xuxian Jiang. Systematic Detection of Capability Leaks in Stock Android Smartphones. In NDSS, 2012. [102] Nils Gruschka, Meiko Jensen, and Torben Dziuk. Event-based Application of Ws-security Policy on Soap Messages. In Proceedings of the 2007 ACM Workshop on Secure Web Services (SWS), pages 1–8, 2007. [103] Hao Hao, Vicky Singh, and Wenliang Du. On the Effectiveness of API-Level Access Control Using Bytecode Rewriting in Android. In Proceedings of the 8th Symposium on Information, Computer and Communications Security (ASIA CCS), pages 25–36, 2013. 120 [104] Manfred Hauswirth and Mehdi Jazayeri. A Component and Communication Model for Push Systems. In Proceedings of the 7th European Software Engineering Conference Held Jointly with the 7th ACM SIGSOFT International Symposium on Foundations of Software Engineering (ESEC/FSE), pages 20–38, 1999. [105] Sarah Heckman and Laurie Williams. On Establishing a Benchmark for Evaluating Static Analysis Alert Prioritization and Classification Techniques. In Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), pages 41–50, 2008. [106] Stephan Heuser, Adwait Nadkarni, William Enck, and Ahmad-Reza Sadeghi. ASM: A Pro- grammable Interface for Extending Android Security. In Proceedings of the 23rd USENIX Conference on Security Symposium (SEC), pages 1005–1019, 2014. [107] Peter Hornyack, Seungyeop Han, Jaeyeon Jung, Stuart Schechter, and David Wetherall. These Aren’t the Droids You’re Looking for: Retrofitting Android to Protect Data from Imperious Applications. In Proceedings of the 18th ACM Conference on Computer and Communications Security (CCS), pages 639–652, 2011. [108] John D Howard. An analysis of security incidents on the internet 1989-1995. Technical report, Carnegie-Mellon Univ Pittsburgh PA, 1997. [109] Jianjun Huang, Xiangyu Zhang, Lin Tan, Peng Wang, and Bin Liang. AsDroid: Detecting Stealthy Behaviors in Android Applications by User Interface and Program Behavior Contra- diction. In Proceedings of the 36th International Conference on Software Engineering (ICSE), pages 1036–1046, 2014. [110] Yao-Wen Huang, Fang Yu, Christian Hang, Chung-Hung Tsai, Der-Tsai Lee, and Sy-Yen Kuo. Securing Web Application Code by Static Analysis and Runtime Protection. In Proceedings of the 13th International Conference on World Wide Web (WWW), pages 40–52, 2004. [111] Zhanwei Hui, Song Huang, Zhengping Ren, and Yi Yao. Review of Software Security Defects Taxonomy. In Proceedings of the 5th International Conference on Rough Set and Knowledge Technology, RSKT’10, pages 310–321, 2010. [112] Mamdouh H. Ibrhaim, Kerrie Holley, Nicolai M. Josuttis, Brenda Michelson, Dave Thomas, and John deVadoss. The Future of SOA: What Worked, What Didn’T, and Where is It Going from Here? In Companion to the 22Nd ACM SIGPLAN Conference on Object-oriented Programming Systems and Applications Companion (OOPSLA), pages 1034–1038, 2007. [113] V. M. Igure and R. D. Williams. Taxonomies of attacks and vulnerabilities in computer systems. IEEE Communications Surveys Tutorials, 10(1):6–19, January 2008. [114] Jinseong Jeon, Kristopher K. Micinski, Jeffrey A. Vaughan, Ari Fogel, Nikhilesh Reddy, Jeffrey S. Foster, and Todd Millstein. Dr. Android and Mr. Hide: Fine-grained Permissions in Android Applications. In Proceedings of the 2nd ACM Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM), pages 3–14, 2012. 121 [115] K. Jiwnani and M. Zelkowitz. Susceptibility matrix: A new aid to software auditing. IEEE Security Privacy, 2(2):16–21, March 2004. [116] C. Joshi and U. K. Singh. ADMIT- A Five Dimensional Approach towards Standardization of Network and Computer Attack Taxonomies. International Journal of Computer Applications, 100(5):30–36, August 2014. [117] Chanchala Joshi and Umesh Singh. A Review on Taxonomies of Attacks and Vulnerability in Computer and Network System. 5, 02 2015. [118] Eirini Karapistoli, Panagiotis Sarigiannidis, and Anastasios A. Economides. SRNET: A Real- time, Cross-based Anomaly Detection and Visualization System for Wireless Sensor Networks. In Proceedings of the Tenth Workshop on Visualization for Cyber Security (VizSec), pages 49–56, 2013. [119] Paul A. Karger, Mary Ellen Zurko, Douglas W. Bonin, Andrew H. Mason, and Clifford E. Kahn. A Retrospective on the VAX VMM Security Kernel. IEEE Transactions on Software Engineering, 17(11):1147–1165, November 1991. [120] Jinyung Kim, Yongho Yoon, Kwangkeun Yi, and Junbum Shin. ScanDal: Static Analyzer for Detecting Privacy Leaks in Android Applications. Mobile Security Technologies (MoST), 12, September 2012. [121] James C. King. Symbolic execution and program testing. Commun. ACM, 19(7):385–394, Jul 1976. [122] William Klieber, Lori Flynn, Amar Bhosale, Limin Jia, and Lujo Bauer. Android Taint Flow Analysis for App Sets. In Proceedings of the 3rd International Workshop on the State of the Art in Java Program Analysis (SOAP), pages 1–6, 2014. [123] Nils Peder Korsveien, Vinay Setty, and Roman Vitenberg. VizPub: Visualizing the Performance of Overlay-based Pub/Sub Systems. In Proceedings of the 8th ACM International Conference on Distributed Event-Based Systems (DEBS), pages 326–329, 2014. [124] Monica S. Lam, Michael Martin, Benjamin Livshits, and John Whaley. Securing Web Ap- plications with Static and Dynamic Information Flow Tracking. In Proceedings of the 2008 ACM SIGPLAN Symposium on Partial Evaluation and Semantics-based Program Manipulation (PEPM), pages 3–12, 2008. [125] Carl E. Landwehr, Alan R. Bull, John P. McDermott, and William S. Choi. A Taxonomy of Computer Program Security Flaws. ACM Comput. Surv., 26(3):211–254, September 1994. [126] Outi-Marja Latvala, Jyri Toivonen, Jarkko Kuusijärvi, and Antti Evesti. A Tool for Security Metrics Modeling and Visualization. In Proceedings of the 2014 European Conference on Software Architecture Workshops (ECSAW), pages 3:1–3:7, 2014. [127] Byeoksan Lee, Seong Min Kim, Eru Park, and Dongsu Han. MemScope: Analyzing Memory Duplication on Android Systems. In Proceedings of the 6th Asia-Pacific Workshop on Systems (APSys), pages 19:1–19:7, 2015. 122 [128] Youn Kyu Lee, Jae young Bang, Gholamreza Safi, Arman Shahbazian, Yixue Zhao, and Nenad Medvidovic. A SEALANT for Inter-app Security Holes in Android. In Proceedings of the 39th International Conference on Software Engineering (ICSE), pages 312–323, 2017. [129] Youn Kyu Lee, Daye Nam, and Nenad Medvidovic. Identifying Inter-Component Communica- tion Vulnerabilities in Event-based Systems. Technical Report USC-CSSE-17-801, University of Southern California, 2017. [130] Li Li, Alexandre Bartel, Tegawendé F Bissyandé, Jacques Klein, Yves Le Traon, Steven Arzt, Siegfried Rasthofer, Eric Bodden, Damien Octeau, and Patrick Mcdaniel. IccTA: Detecting Inter-Component Privacy Leaks in Android App. In Proceedings of the 37th International Conference on Software Engineering (ICSE), pages 280–291, 2015. [131] Li Li, Alexandre Bartel, Jacques Klein, and Yves Le Traon. Automatically Exploiting Potential Component Leaks in Android Applications. In Proceedings of the 13th International Conference on Trust, Security and Privacy in Computing and Communications (TRUSTCOM), pages 388–397, 2014. [132] Li Li, Alexandre Bartel, Jacques Klein, Yves Le Traon, Steven Arzt, Siegfried Rasthofer, Eric Bodden, Damien Octeau, and Patrick Mcdaniel. I know what leaked in your pocket: uncovering privacy leaks on Android Apps with Static Taint Analysis. arXiv:1404.7431, 2014. [133] Long Lu, Zhichun Li, Zhenyu Wu, Wenke Lee, and Guofei Jiang. Chex: Statically Vetting Android Apps for Component Hijacking Vulnerabilities. In Proceedings of the ACM Conference on Computer and Communications Security (CCS), pages 229–240, 2012. [134] Sam Malek, Nenad Medvidovic, and Marija Mikic-Rakic. An extensible framework for improv- ing a distributed software system’s deployment architecture. IEEE Transactions on Software Engineering, 38(1):73–100, January 2012. [135] Sam Malek, Marija Mikic-Rakic, and Nenad Medvidovic. A Style-Aware Architectural Mid- dleware for Resource-Constrained, Distributed Systems. IEEE Transactions on Software Engineering, 31(3):256–272, March 2005. [136] Christopher Mann and Artem Starostin. A Framework for Static Detection of Privacy Leaks in Android Applications. In Proceedings of the 27th Symposium on Applied Computing (SAC), pages 1457–1462, 2012. [137] Raffael Marty. Applied Security Visualization. Addison-Wesley Upper Saddle River, 2009. [138] Nenad Medvidovic. On the Role of Middleware in Architecture-based Software Development. In Proceedings of the 14th International Conference on Software Engineering and Knowledge Engineering (SEKE), pages 299–306, 2002. [139] Nenad Medvidovic, Eric M Dashofy, and Richard N Taylor. The role of middleware in architecture-based software development. International Journal of Software Engineering and Knowledge Engineering, 13(04):367–393, November 2003. 123 [140] NenadMedvidovic, DavidSRosenblum, andRichardNTaylor. Alanguageandenvironmentfor architecture-based software development and evolution. In Proceedings of the 21st International Conference on Software Engineering (ICSE), pages 44–53, 1999. [141] Anton Michlmayr, Florian Rosenberg, Philipp Leitner, and Schahram Dustdar. Advanced Event Processing and Notifications in Service Runtime Environments. In Proceedings of the Second International Conference on Distributed Event-based Systems (DEBS), pages 115–125, 2008. [142] Matteo Migliavacca, Peter Pietzuch, Jean Bacon, David Eyers, Jatinder Sigh, and Brian Shand. Security in Multi-domain Event-based Systems. it - Information Technology, 51(5), October 2009. [143] G. Mühl et al. Distributed Event-Based Systems. Springer-Verlag New York, Inc., 2006. [144] Mohamed Nabeel, Ning Shang, and Elisa Bertino. Efficient Privacy Preserving Content Based Publish Subscribe Systems. In Proceedings of the 17th ACM Symposium on Access Control Models and Technologies (SACMAT), pages 133–144, 2012. [145] Joseph P. Near and Daniel Jackson. Derailer: Interactive Security Analysis for Web Applica- tions. In Proceedings of the 29th ACM/IEEE International Conference on Automated Software Engineering (ASE), pages 587–598, 2014. [146] Flemming Nielson, Hanne R. Nielson, and Chris Hankin. Principles of Program Analysis. Springer-Verlag New York, Inc., 1999. [147] D. Octeau, D. Luchaup, M. Dering, S. Jha, and P. McDaniel. Composite Constant Propagation: Application to Android Inter-Component Communication Analysis. In Proceedings of the 37th International Conference on Software Engineering (ICSE), pages 77–88, 2015. [148] Damien Octeau, Somesh Jha, Matthew Dering, Patrick McDaniel, Alexandre Bartel, Li Li, Jacques Klein, and Yves Le Traon. Combining Static Analysis with Probabilistic Models to Enable Market-Scale Android Inter-Component Analysis. In Proceedings of the 43rd Symposium on Principles of Programming Languages (POPL), pages 469–484, 2016. [149] Damien Octeau, Patrick McDaniel, Somesh Jha, Alexandre Bartel, Eric Bodden, Jacques Klein, and Yves Le Traon. Effective Inter-component Communication Mapping in Android with Epicc: An Essential Step Towards Holistic Security Analysis. In Proceedings of the 22nd USENIX Conference on Security (SEC), pages 543–558, 2013. [150] Machigar Ongtang, Stephen McLaughlin, William Enck, and Patrick McDaniel. Semantically Rich Application-Centric Security in Android. In Proceedings of the Annual Computer Security Applications Conference (ACSAC), pages 340–349, 2009. [151] Peyman Oreizy, Nenad Medvidovic, and Richard N. Taylor. Architecture-based Runtime Soft- ware Evolution. In Proceedings of the 20th International Conference on Software Engineering (ICSE), pages 177–186, 1998. 124 [152] I. Papagiannis, M. Migliavacca, P. Pietzuch, B. Shand, D. Eyers, and J. Bacon. PrivateFlow: Decentralised Information Flow Control in Event Based Middleware. In Proceedings of the Third ACM International Conference on Distributed Event-Based Systems (DEBS), pages 38:1–38:2, 2009. [153] Lauri I. W. Pesonen, David M. Eyers, and Jean Bacon. Encryption-Enforced Access Control in Dynamic Multi-Domain Publish/Subscribe Networks. In Proceedings of the Inaugural International Conference on Distributed Event-based Systems (DEBS), pages 104–115, 2007. [154] Fabio Petroni, Leonardo Querzoni, Roberto Beraldi, and Mario Paolucci. Exploiting User Feedback for Online Filtering in Event-based Systems. In Proceedings of the 31st Annual ACM Symposium on Applied Computing (SAC), pages 2021–2026, 2016. [155] Frank Piessens. A Taxonomy of Causes of Software Vulnerabilities in Internet Software. In Supplementary Proceedings of the 13th International Symposium on Software Reliability Engineering (ISSRE), pages 47–52, 2002. [156] P. R. Pietzuch and J. M. Bacon. Hermes: A distributed event-based middleware architecture. In Proceedings 22nd International Conference on Distributed Computing Systems Workshops (ICDCSW), pages 611–618, 2002. [157] Peter Pietzuch. Building Secure Event Processing Applications. In Proceedings of the First International Workshop on Algorithms and Models for Distributed Event Processing (AlMoDEP), pages 11–11, 2011. [158] Marco Pistoia, Stephen J. Fink, Robert J. Flynn, and Eran Yahav. When Role Models Have Flaws: Static Validation of Enterprise Security Policies. In Proceedings of the 29th International Conference on Software Engineering (ICSE), pages 478–488, 2007. [159] Marco Pistoia, Omer Tripp, Pietro Ferrara, and Paolina Centonze. Automatic Detection, Correction, and Visualization of Security Vulnerabilities in Mobile Apps. In Proceedings of the 3rd International Workshop on Mobile Development Lifecycle (MobileDeLi), pages 35–36, 2015. [160] Daniel Popescu, Joshua Garcia, Kevin Bierhoff, and Nenad Medvidovic. Impact analysis for distributed event-based systems. In Proceedings of the 6th ACM International Conference on Distributed Event-Based Systems (DEBS), pages 241–251, 2012. [161] C. Raiciu and D. S. Rosenblum. Enabling Confidentiality in Content-Based Publish/Subscribe Infrastructures. In Securecomm and Workshops (SecureComm), pages 1–11, 2006. [162] Mohammed Rangwala, Ping Zhang, Xukai Zou, and Feng Li. A Taxonomy of Privilege Escalation Attacks in Android Applications. Int. J. Secur. Netw., 9(1), February 2014. [163] S. Rasthofer, S. Arzt, E. Lovat, and E. Bodden. DroidForce: Enforcing Complex, Data-centric, System-wide Policies in Android. In Proceedings of the 9th International Conference on Availability, Reliability, and Security (ARES), pages 40–49, 2014. [164] Siegfried Rasthofer, Steven Arzt, and Eric Bodden. A Machine-Learning Approach for Classifying and Categorizing Android Sources and Sinks. In Proceedings of the 21st Annual Network & Distributed System Security Symposium (NDSS), 2014. 125 [165] Tristan Ravitch, E. Rogan Creswick, Aaron Tomb, Adam Foltzer, Trevor Elliott, and Ledah Casburn. Multi-App Security Analysis with FUSE: Statically Detecting Android App Collusion. In Proceedings of the 4th Program Protection and Reverse Engineering Workshop (PPREW), pages 4:1–4:10, 2014. [166] Darrell Reimer, Edith Schonberg, Kavitha Srinivas, Harini Srinivasan, Bowen Alpern, Robert D. Johnson, Aaron Kershenbaum, and Larry Koved. SABER: Smart Analysis Based Error Reduction. In Proceedings of the 2004 ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), pages 243–251, 2004. [167] Gholamreza Safi, Arman Shahbazian, William GJ Halfond, and Nenad Medvidovic. Detecting Event Anomalies in Event-Based Systems. In Proceedings of the 10th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE), pages 25–37, 2015. [168] Manish Kumar Sahu, Manish Ahirwar, and A Hemlata. A Review of Malware Detection Based on Pattern Matching Technique. Int. J. of Computer Science and Information Technologies (IJCSIT), 5(1):944–947, May 2014. [169] Daniel Schreckling, Joachim Posegga, Johannes Köstler, and Matthias Schaff. Kynoid: Real- Time Enforcement of Fine-Grained, User-Defined, and Data-Centric Security Policies for Android. In Proceedings of the 6th IFIP International Conference on Information Security Theory and Practice: Security, Privacy and Trust in Computing Systems and Ambient Intelligent (WISTP), pages 208–223, 2012. [170] Brian Shand, Peter Pietzuch, Ioannis Papagiannis, Ken Moody, Matteo Migliavacca, David Eyers, and Jean Bacon. Security Policy and Information Sharing in Distributed Event-Based Systems. Reasoning in Event-Based Distributed Systems, pages 151–172, 2011. [171] Feng Shen, Namita Vishnubhotla, Chirag Todarka, Mohit Arora, Babu Dhandapani, Eric John Lehner, Steven Y. Ko, and Lukasz Ziarek. Information Flows As a Permission Mechanism. In Proceedings of the 29th ACM/IEEE International Conference on Automated Software Engineering (ASE), pages 515–526, 2014. [172] Alexis Silva and Jocelyn Simmonds. BehaviorDroid: Monitoring Android Applications. In Proceedings of the International Conference on Mobile Software Engineering and Systems (MOBILESoft), pages 19–20, 2016. [173] Chris Simmons, Charles Ellis, Sajjan Shiva, Dipankar Dasgupta, and Qishi Wu. AVOIDIT: A Cyber Attack Taxonomy. Technical report, University of Memphis, 2009. [174] Jatinder Singh, Jean Bacon, and David Eyers. Policy Enforcement Within Emerging Dis- tributed, Event-based Systems. In Proceedings of the 8th ACM International Conference on Distributed Event-Based Systems (DEBS), pages 246–255, 2014. [175] Jatinder Singh, David M. Eyers, and Jean Bacon. Disclosure Control in Multi-domain Publish/Subscribe Systems. In Proceedings of the 5th ACM International Conference on Distributed Event-based System (DEBS), pages 159–170, 2011. 126 [176] Manu Sridharan, Shay Artzi, Marco Pistoia, Salvatore Guarnieri, Omer Tripp, and Ryan Berg. F4F: Taint Analysis of Framework-based Web Applications. In Proceedings of the 2011 ACM International Conference on Object Oriented Programming Systems Languages and Applications (OOPSLA), pages 1053–1068, 2011. [177] Mudhakar Srivatsa and Ling Liu. Secure Event Dissemination in Publish-Subscribe Networks. InProceedings of the 27th International Conference on Distributed Computing Systems (ICDCS), pages 22–22, 2007. [178] Mudhakar Srivatsa, Ling Liu, and Arun Iyengar. EventGuard: A System Architecture for Securing Publish-Subscribe Networks. ACM Transactions on Computer Systems (TOCS), 29(4):10:1–10:40, December 2011. [179] Sufatrio, Darell J. J. Tan, Tong-Wei Chua, and Vrizlynn L. L. Thing. Securing Android: A Survey, Taxonomy, and Challenges. ACM Comput. Surv., 47(4):58:1–58:45, May 2015. [180] Muhammad Adnan Tariq, Boris Koldehofe, Ala’ Altaweel, and Kurt Rothermel. Providing Basic Security Mechanisms in Broker-less Publish/Subscribe Systems. In Proceedings of the Fourth ACM International Conference on Distributed Event-Based Systems (DEBS), pages 38–49, 2010. [181] Richard N Taylor, Nenad Medvidovic, Kenneth M Anderson, E James Whitehead, Jason E Robbins, Kari A Nies, Peyman Oreizy, and Deborah L Dubrow. A component- and message- based architectural style for gui software. IEEE Transactions on Software Engineering, 22(6):390–406, June 1996. [182] R.N. Taylor, N Medvidovic, and E.M. Dashofy. Software Architecture: Foundations, Theory, and Practice. John Wiley & Sons, 2009. [183] S. J. Templeton and K. E. Levitt. Detecting Spoofed Packets. In DARPA Information Survivability Conference and Exposition Proceedings, volume 1, pages 164–175, 2003. [184] Frank Tip. A Survey of Program Slicing Techniques. Journal of Programming Languages, 3:121–189, 1995. [185] Omer Tripp, Marco Pistoia, Patrick Cousot, Radhia Cousot, and Salvatore Guarnieri. AN- DROMEDA: Accurate and Scalable Security Analysis of Web Applications. In Proceedings of the 16th International Conference on Fundamental Approaches to Software Engineering (FASE), pages 210–225, 2013. [186] K. Tsipenyuk, B. Chess, and G. McGraw. Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors. IEEE Security Privacy, 3(6):81–84, November 2005. [187] Raja Vallée-Rai, Phong Co, Etienne Gagnon, Laurie Hendren, Patrick Lam, and Vijay Sundaresan. Soot - a Java Bytecode Optimization Framework. In Proceedings of the 1999 Conference of the Centre for Advanced Studies on Collaborative Research (CASCON), pages 13–, 1999. 127 [188] Robert J. Walker and Kevin Viggers. Implementing Protocols via Declarative Event Patterns. In Proceedings of the 12th ACM SIGSOFT Twelfth International Symposium on Foundations of Software Engineering (FSE), pages 159–169, 2004. [189] Chenxi Wang, A. Carzaniga, D. Evans, and A.L. Wolf. Security issues and requirements for Internet-scale publish-subscribe systems. In Proceedings of the 35th Annual Hawaii Interna- tional Conference on System Sciences (HICSS), pages 3940–3947, 2002. [190] Xueqiang Wang, Kun Sun, Yuewu Wang, and Jiwu Jing. DeepDroid: Dynamically Enforcing Enterprise Policy on Android Devices. In Proceedings of the 22nd Annual Network & Distributed System Security Symposium (NDSS), 2015. [191] Christopher Waters, Jonathan Howell, and T. J. Jankun-Kelly. CluVis: Dual-domain Visual Exploration of Cluster/Network Metadata. In Proceedings of the 45th Annual Southeast Regional Conference (ACM-SE), pages 272–276, 2007. [192] Sam Weber, Paul A. Karger, and Amit Paradkar. A Software Flaw Taxonomy: Aiming Tools at Security. SIGSOFT Softw. Eng. Notes, 30(4):1–7, May 2005. [193] Fengguo Wei, Sankardas Roy, Xinming Ou, and Robby. Amandroid: A Precise and General Inter-component Data Flow Analysis Framework for Security Vetting of Android Apps. In Proceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 1329–1341, 2014. [194] Handong Wu, Stephen Schwab, and Robert Lom Peckham. Signature based network intrusion detection system and method, September 2008. US Patent 7,424,744. [195] Jianliang Wu, Tingting Cui, Tao Ban, Shanqing Guo, and Lizhen Cui. PaddyFrog: Sys- tematically Detecting Confused Deputy Vulnerability in Android Applications. Security and Communication Network, 8(13):2338–2349, September 2015. [196] Lei Wu, Michael Grace, Yajin Zhou, Chiachih Wu, and Xuxian Jiang. The Impact of Vendor Customizations on Android Security. In Proceedings of the 2013 ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 623–634, 2013. [197] Alex Wun, Alex Cheung, and Hans-Arno Jacobsen. A Taxonomy for Denial of Service Attacks in Content-based Publish/Subscribe Systems. In Proceedings of the 2007 Inaugural International Conference on Distributed Event-based Systems (DEBS), pages 116–127, 2007. [198] Alex Wun and Hans-Arno Jacobsen. A Policy Management Framework for Content-based Publish/Subscribe Middleware. In Proceedings of the ACM/IFIP/USENIX 2007 International Conference on Middleware (Middleware), pages 368–388, 2007. [199] Simeon Xenitellis. Security Vulnerabilities in Event-Driven Systems. In Proceedings of the IFIP TC11 17th International Conference on Information Security: Visions and Perspectives (SEC), pages 147–160, 2002. [200] Rubin Xu, Hassen Saïdi, and Ross Anderson. Aurasium: Practical Policy Enforcement for Android Applications. In Proceedings of the 21st USENIX Conference on Security Symposium (USENIX), pages 539–552, 2012. 128 [201] Kun Yang, Jianwei Zhuge, Yongke Wang, Lujue Zhou, and Haixin Duan. IntentFuzzer: Detecting Capability Leaks of Android Applications. In Proceedings of the 9th ACM Symposium on Information, Computer and Communications Security (ASIA CCS), pages 531–536, 2014. [202] Shengqian Yang, Dacong Yan, Haowei Wu, Yan Wang, and Atanas Rountev. Static Control- Flow Analysis of User-driven Callbacks in Android Applications. In Proceedings of the 37th International Conference on Software Engineering (ICSE), pages 89–99, 2015. [203] Zhemin Yang and Min Yang. LeakMiner: Detect Information Leakage on Android with Static Taint Analysis. In Proceedings of the 3rd World Congress on Software Engineering (WCSE), pages 101–104, 2012. [204] Zhemin Yang, Min Yang, Yuan Zhang, Guofei Gu, Peng Ning, and X. Sean Wang. AppIntent: Analyzing Sensitive Data Transmission in Android for Privacy Leakage Detection. In Proceed- ings of the ACM SIGSAC Conference on Computer Communications Security (CCS), pages 1043–1054, 2013. [205] Hui Ye, Shaoyin Cheng, Lanbo Zhang, and Fan Jiang. DroidFuzzer: Fuzzing the Android Apps with Intent-Filter Tag. In Proceedings of International Conference on Advances in Mobile Computing & Multimedia (MoMM), pages 68:68–68:74, 2013. [206] Mu Zhang and Heng Yin. Appsealer: Automatic Generation of Vulnerability-Specific Patches for Preventing Component Hijacking Attacks in Android Applications. In Proceedings of the 21st Annual Network & Distributed System Security Symposium (NDSS), 2014. [207] R. Zhang, K. Cai, and W. M. Wonham. Delay-robustness in distributed control of timed discrete-event systems based on supervisor localization. In 53rd IEEE Conference on Decision and Control, pages 6719–6724, Dec 2014. [208] Zhibo Zhao and Fernando C. Colon Osono. “TrustDroid™”: Preventing the Use of Smartphones for Information Leaking in Corporate Networks Through the Used of Static Analysis Taint Tracking. In Proceedings of the 7th International Conference on Malicious and Unwanted Software (MALWARE), pages 135–143, 2012. [209] Yibing Zhongyang, Zhi Xin, Bing Mao, and Li Xie. DroidAlarm: An All-Sided Static Analysis Tool for Android Privilege-Escalation Malware. In Proceedings of the 8th ACM SIGSAC Symposium on Information, Computer and Communications Security (CCS), pages 353–358, 2013. [210] Y. Zhou and X. Jiang. Dissecting Android Malware: Characterization and Evolution. In Proceedings of the 33rd IEEE Symposium on Security and Privacy (SP), pages 95–109, 2012. [211] Yajin Zhou and Xuxian Jiang. Detecting Passive Content Leaks and Pollution in Android Applications. In Proceedings of the 19th Annual Network & Distributed System Security Symposium (NDSS), 2013. [212] Jun Zhu, Bill Chu, and Heather Lipford. Detecting Privilege Escalation Attacks Through Instrumenting Web Application Source Code. In Proceedings of the 21st ACM on Symposium on Access Control Models and Technologies (SACMAT), pages 73–80, 2016. 129

Abstract (if available)

Abstract Event-based system (EBS) has become popular because of its high flexibility, scalability, and adaptability. These advantages are facilitated by its reliance on implicit invocation and implicit concurrency. Specifically, in EBS, components may not know the consumers of the events they publish, nor do they necessarily know the producers of events they consume. This communication mechanism is based on non-determinism in event processing, which can introduce inherent security vulnerabilities into a system referred to as event attacks. Event attack is a particular type of attack that can abuse, incapacitate, and damage a target system by exploiting the system’s event-based communication model. Different types of event attacks have been identified in a range of domains to date. It is hard to prevent event attacks because they are administered in a way that does not differ from ordinary event-based communication in general. While a number of techniques have focused on security threats in EBS, they do not appropriately resolve the event attack problems or suffer from inaccuracy in detecting and preventing event attacks. Furthermore, fundamental security flaws, which can be exploited by event attacks, have not been clearly identified yet. In order to address the risk of event attacks, this dissertation presents four main approaches: (1) a new taxonomy for security flaws in EBS, which can serve as a basis for resolving event attack problems

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Detecting anomalies in event-based systems through static analysis

PDF

Energy optimization of mobile applications

PDF

Prediction of energy consumption behavior in component-based distributed systems

PDF

Deriving component‐level behavior models from scenario‐based requirements

PDF

Detection, localization, and repair of internationalization presentation failures in web applications

PDF

Automatic detection and optimization of energy optimizable UIs in Android applications using program analysis

PDF

Detecting SQL antipatterns in mobile applications

PDF

Automated repair of presentation failures in Web applications using search-based techniques

PDF

Constraint-based program analysis for concurrent software

PDF

Defending industrial control systems: an end-to-end approach for managing cyber-physical risk

PDF

Techniques for methodically exploring software development alternatives

PDF

Design-time software quality modeling and analysis of distributed software-intensive systems

PDF

Dynamic graph analytics for cyber systems security applications

PDF

Architectural evolution and decay in software systems

PDF

Proactive detection of higher-order software design conflicts

PDF

A function-based methodology for evaluating resilience in smart grids

PDF

A user-centric approach for improving a distributed software system's deployment architecture

PDF

Analysis of embedded software architecture with precedent dependent aperiodic tasks

PDF

Toward understanding mobile apps at scale

PDF

Software security economics and threat modeling based on attack path analysis; a stakeholder value driven approach

Asset Metadata

Creator Lee, Youn Kyu (author)

Core Title Reducing inter-component communication vulnerabilities in event-based systems

School Viterbi School of Engineering

Degree Doctor of Philosophy

Degree Program Computer Science

Publication Date 11/10/2017

Defense Date 10/19/2017

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag event-based systems,inter-component communication,OAI-PMH Harvest,Security,vulnerabilities

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor Medvidovic, Nenad (committee chair), Gupta, Sandeep (committee member), Halfond, William (committee member)

Creator Email younkyul@usc.edu

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c40-453301

Unique identifier UC11264353

Identifier etd-LeeYounKyu-5891.pdf (filename),usctheses-c40-453301 (legacy record id)

Legacy Identifier etd-LeeYounKyu-5891.pdf

Dmrecord 453301

Document Type Dissertation

Rights Lee, Youn Kyu

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA