SALMA: Self-Protection of Android Systems from Inter-Component Communication Attacks

The current security mechanisms for Android apps, both static and dynamic analysis approaches, are insufficient for detection and prevention of the increasingly dynamic and sophisticated security attacks.

Static analysis approaches suffer from false positives whereas dynamic analysis approaches suffer from false negatives. Moreover, they all lack the ability to efficiently analyze systems with incremental changes---such as adding/removing apps, granting/revoking permissions, and dynamic components' communications. Each time the system changes, the entire analysis needs to be repeated, making the existing approaches inefficient for practical use.

To mitigate their shortcomings, we have developed SALMA, a novel self-protecting Android software system that monitors itself and adapts its behavior at runtime to prevent a wide-range of security risks. SALMA maintains a precise architectural model, represented as a Multiple-Domain-Matrix, and incrementally and efficiently analyzes an Android system in response to incremental system changes. The maintained architecture is used to reason about the running Android system. Every time the system changes, SALMA determines (1) the impacted part of the system, and (2) the subset of the security analyses that need to be performed, thereby greatly improving the performance of the approach. Our experimental results on hundreds of real-world apps corroborate SALMA's scalability and efficiency as well as its ability to detect and prevent security attacks at runtime with minimal disruption.

Every time an app is added to the system, SALMA incrementally analyzes the system whereas DELDROID, a complete analysis approach, reanalyzes the entire system. As illustrated in the figure below, the analysis time of SALMA takes, on average, 2 seconds to incrementally analyze an Android system whenever a new app is installed. On the other hand, DELDROID takes, on average, 75 seconds.

Similarly, the figure below contains box-and-whisker plots comparing the analysis time of each approach with a decreasing number of apps, i.e., in response to the removing apps system events. We started with a bundle of 150 apps, then we removed one app at a time until the system contains 120 apps. The average analysis time of SALMA is 0.2 seconds while the average analysis time of DELDROID is 35.3 seconds.

We also measured the efficiency of SALMA on all other events (grant/revoke permissions, dynamically added interactions). To that end, we randomly considered 100 different transactions of each event type to be considered only at runtime for an Android system with 100 apps randomly selected from the app datasets. For example, in the cases of grant a permission or revoke a permission, we randomly selected 100 permissions required by various apps to be revoked from these apps and then to be granted at a later time. Regarding new explicit communication or new implicit communication events, for each event, we randomly selected 100 communications to be added only at runtime, i.e., these communications have been removed from the initial system's model. Finally, since the studied Android system with 100 apps contains 80 database interactions (40 data access and 40 data manipulation requests), we considered all of these interactions to be added at runtime. The total number of transactions considered for this experiment is 480 events. The box-and-whisker plots in the below figure compares the efficiency of SALMA with DELDroid for each event. SALMA takes, on average across all events, 1.6 milliseconds (0.0016 seconds) while DELDroid takes, on average across all events, 63.8 seconds.

Applying security policies at runtime can cause disruption to the app's benign functionality. SALMA minimizes the disruption by only preventing the malicious communication instead of (1) revoking permissions of the vulnerable app or (2) preventing the installation of the vulnerable app as suggested by other approaches in the literature.

The figure below compares the three different permission-induced prevention mechanisms. The diagram shows that SALMA has 0.4% disruption, meaning that SALMA does not disturb components from providing their services except in one identical custom permission case. In that case, SALMA created a security policy to revoke a custom permission from the malicious app so it will not be able to access the vulnerable app. On the other hand, the install-time approach performs the worst (100%), as it does not allow installation of a vulnerable app. Finally, revoking permissions at runtime to prevent permission-induced attacks would result, on average per app, in 32%disruption. Meaning that, on average, 32% of the components in a vulnerable app will not be able to provide their full services due to the lack of required permissions even though some of these components are not vulnerable or involved in any vulnerability. Moreover, revoking permissions from apps at runtime lead to crashes or unexpected behaviors due to inappropriate handling of dynamic permissions in Android.

Github