Are free Android app security analysis tools effective in detecting known vulnerabilities?

Abstract

Increasing interest in securing the Android ecosystem has spawned numerous efforts to assist app developers in building secure apps. These efforts have resulted in tools and techniques capable of detecting vulnerabilities and malicious behaviors in apps. However, there has been no evaluation of the effectiveness of these tools and techniques in detecting known vulnerabilities. The absence of such evaluations puts app developers at a disadvantage when choosing security analysis tools to secure their apps. In this regard, we evaluated the effectiveness of vulnerability detection tools for Android apps. We reviewed 64 tools and empirically evaluated 14 vulnerability detection tools against 42 known unique vulnerabilities captured by Ghera benchmarks, which are composed of both vulnerable and secure apps. Of the 20 observations from the evaluation, the main observation is existing vulnerability detection tools for Android apps are very limited in their ability to detect known vulnerabilities — all of the evaluated tools together could only detect 30 of the 42 known unique vulnerabilities. More effort is required if security analysis tools are to help developers build secure apps. We hope the observations from this evaluation will help app developers choose appropriate security analysis tools and persuade tool developers and researchers to identify and address limitations in their tools and techniques. We also hope this evaluation will catalyze or spark a conversation in the software engineering and security communities to require a more rigorous and explicit evaluation of security analysis tools and techniques.

Appendix: A Catalog of Considered Vulnerabilities

In this catalog, we briefly describe the 42 vulnerabilities captured in Ghera (along with their canonical references) that were used in this evaluation. Few vulnerabilities have generic references as they were discovered by Ghera authors while reading the security guidelines available as part of Android documentation (Google Inc 2018c). Please refer the work by Mitra and Ranganath (2017a) for details about the repository and the initial set of vulnerabilities.

1.1 A.1 Crypto

Crypto APIs enable Android apps to encrypt and decrypt information and manage cryptographic keys.

• C1 The result of encrypting a message twice using Block Cipher algorithm in ECB mode is the message itself. So, apps using Block Cipher algorithm in ECB mode (explicitly or due to default on Android platform) can leak information (Egele et al. 2013).

• C2 Encryption using Block Cipher algorithm in CBC mode with a constant Initialization Vector (IV) can be broken by recovering the constant IV using plain text attack. So, apps using such encryption can leak information (Egele et al. 2013).

• C3 Password-based encryption (PBE) uses a salt to generate a password-based encryption key. If the salt is constant, the encryption key can be recovered with knowledge about the password. Hence, apps using PBE with constant salt can leak information (Egele et al. 2013).

• C4 Cipher APIs rely on unique keys to encrypt information. If such keys are embedded in the app’s code, then attackers can recover such keys from the app’s code. Hence, such apps are susceptible to both information leak and data injection (Egele et al. 2013).

1.2 A.2 Inter Component Communication (ICC)

Android apps are composed of four basic kinds of components: 1) Activity components display user interfaces, 2) Service components perform background operations, 3) Broadcast Receiver components receive event notifications and act on those notifications, and 4) Content Provider components manage app data. Communication between components in an app and in different apps (e.g., to perform specific actions, share information) is facilitated via exchange of Intent s. Components specify their ability to process specific kinds of intents by using intent-filters.

• I1 Android apps can dynamically register broadcast receivers at runtime. Such receivers are automatically exported without any access restrictions and, hence, can be accessed via ICC and exploited to perform unintended actions (Chin et al. 2011).

• I2 A component can use a pending intent to allow another component to act on its behalf. When a pending intent is empty (i.e., does not specify an action), it can be seeded (via interception) with an unintended action to be executed on behalf of the originating component (Wang 2014b).

• I3 To perform an action (e.g., send email), users choose an activity/app from a list of activities ordered by priority. By using appropriate priorities, activities can gain unintended privilege over other activities (Chin et al. 2011).

• I4 Implicit intents are processed by any qualifying service determined by intent filters as opposed to a specific explicitly named service. In case of multiple qualifying services, the service with the highest priority processes the intent. By registering appropriate intent filters and by using appropriate priorities, services can gain unintended access to implicit intents (Chin et al. 2011).

• I5 Pending intents can contain implicit intents. Hence, services processing implicit intents contained in pending intents are vulnerable like in I4 (Wang 2014b).

• I6 Apps can use path-permissions to control access to data exposed by content provider. These permissions control access to a folder and not to its subfolders/descendants and their contents. Incorrectly assuming the extent of these permissions can lead to information leak (read) and data injection (write) (Google Inc 2018c).

• I7 Components that process implicit intents are by default exported without any access restrictions. If such a component processes intents without verifying their authenticity (e.g., source) and handles sensitive information or performs sensitive operations in response to implicit intents, then it can leak information or perform unintended actions (Chin et al. 2011).

• I8 Broadcast receivers registered for system intents (e.g., low memory) from Android platform are by default exported without any access restrictions. If such a receiver services intents without verifying the authenticity of intents (e.g., requested action), then it may be vulnerable like the components in I7 (Chin et al. 2011).

• I9 Broadcast receivers respond to ordered broadcasts in the order of priority. By using appropriate priorities, receivers can modify such broadcasts to perform unintended actions (Chin et al. 2011).

• I10 Sticky broadcast intents are delivered to every registered receiver and saved in the system to be delivered to receivers that register in the future. When such an intent is re-broadcasted with modification, it replaces the saved intent in the system, which can lead to information leak and data injection (Chin et al. 2011).

• I11 Every activity is launched in a task, a collection (stack) of activities. An activity can declare its affinity to be started in a specific task under certain conditions. When the user navigates away from an activity X via the back button, the activity below X on X’s task is displayed. This behavior along with task affinity and specific start order — malicious activity started before benign activity — can be used to mount a phishing attack (Ren et al. 2015).

• I12 When an activity from a task in the background (i.e., none of its activities are being displayed) is resumed, the activity at the top of the task (and not the resumed activity) is displayed. This behavior along with task affinity and specific start order — malicious activity started after benign activity — can be used to mount a phishing attack (Ren et al. 2015).

• I13 When a launcher activity is started, its task is created and it is added as the first activity of the task. If the task of a launcher activity already exists with other activities in it, then its task is brought to the foreground, but the launcher activity is not started. This behavior along with task affinity and specific start order — malicious activity started before benign activity — can be used to mount a phishing attack (Ren et al. 2015).

• I14 In addition to declaring task affinity, an activity can request that it be moved to the affine task when the task is created or moved to the foreground (known as task reparenting). This behavior along with task affinity and specific start order — malicious activity started before benign activity — can be used to mount a denial-of-service or a phishing attack (Ren et al. 2015).

• I15 Apps can request permission to perform privileged operations (e.g., send SMS) and offer interfaces (e.g., broadcast receiver) thru which these privileged operations can be triggered. Unless appropriately protected, these interfaces can be exploited to perform an operation without sufficient permissions (Chin et al. 2011).

• I16 The call method of Content Provider API can be used to invoke any provider-defined method. With reference to a content provider, this method can be invoked without any restriction leading to both information leak and data injection (Google Inc 2018b).

1.3 A.3 Networking

Networking APIs allow Android apps to communicate over the network via multiple protocols.

• N1 Apps can open server sockets to listen to connections from clients; typically, remote servers. If such sockets are not appropriately protected, then they can lead to information leak and data injection (Jia et al. 2017).

• N2 Apps can communicate with remote servers via insecure TCP/IP connections. Such scenarios are susceptible to MitM attacks (Jia et al. 2017).

1.4 A.4 Permissions

In addition to system-defined permissions, Android apps can create and use custom permissions. These permissions can be combined with the available four protection levels (i.e., normal, dangerous, signature, signatureOrSystem) to control access to various features and services.

• P1 Permissions with normal protection level are automatically granted to requesting apps during installation. Consequently, any component or its interface protected by such “normal” permissions will be accessible to every installed app (Satoru 2014).

1.5 A.5 Storage

Android provides two basic options to store app data.

• 1. Internal Storage is best suited to store files private to apps. Every time an app is uninstalled, its internal storage is purged. Starting with Android 7.0 (API 24), files stored in internal storage cannot be shared with and accessed by other apps (Google Inc 2018c).

• 2. External Storage is best suited to store files that are to be shared with other apps or persisted even after an app is uninstalled. While public directories are accessible by all apps, app-specific directories are accessible only by corresponding apps or other apps with appropriate permission (Google Inc 2018c).

• S1 Files stored in public directories on external storage can be accessed by an app with appropriate permission to access external storage. This aspect can be used to tamper data via data injection (Google Inc 2018c).

• S2 The same aspect from S1 can lead to information leak (Google Inc 2018c).

• S3 Apps can accept paths to files in the external storage from external sources and use them without sanitizing them. A well-crafted file path can be used to read, write, or execute files in the app’s private directory on external storage (directory traversal attack) (Ryohei 2014).

• S4 Apps can copy data from internal storage to external storage. As a result, information could be leaked if such apps accept input from untrusted sources to determine the data to be copied (Yu 2014).

• S5 SQLiteDatabase.rawQuery() method can be used by apps to serve data queries. If such uses rely on external inputs and use non-parameterized SQL queries, then they are susceptible to sql injection attacks (Wang 2014a).

• S6 Content Provider API support selectionArgs parameter in various data access operations to separate selection criteria and selection parameters. App that do not use this parameter are be susceptible to sql injection attacks (Wang 2014a).

1.6 A.6 System

System APIs enable Android apps to access low-level features of the Android platform like process management, thread management, runtime permissions, etc.

Every Android app runs in its own process with a unique Process ID (PID) and a User ID (UID). All components in an app run in the same process. A permission can be granted to an app at installation time or at run time. All components inherit the permissions granted to the containing app at installation time. If a component in an app is protected by a permission, only components that have been granted this permission can communicate with the protected component.

• Y1 During IPC, checkCallingOrSelfPermission method can be used to check if the calling process or the called process has permission P. If a component with permission P uses this method to check if the calling component has permission P, then improper use of this method can leak privilege when the calling component does not have permission P (Google Inc 2018a).

• Y2 checkPermission method can be used to check if the given permission is allowed for the given PID and UID pair. getCallingPID and getCallingUID methods of Binder API can be used to retrieve the PID and UID of the calling process. In certain situations, they return PID/UID of the called process. So, improper use of these methods by a called component with given permission can leak privilege (Google Inc 2018a).

• Y3 During IPC, enforceCallingOrSelfPermission method can be used to check if the calling process or the called process has permission P. Like in Y1, improper use of this method can leak privilege (Google Inc 2018a).

• Y4 enforcePermission method can be used to check if the given permission is allowed for the given PID and UID pair. Like in Y2, improper use of this method along with getCallingPID and getCallingUID can leak privilege (Google Inc 2018a).

1.7 A.7 Web

Web APIs allow Android apps to interact with web servers both with and without SSL/TLS, display web content through WebView widget, and control navigation between web pages via WebViewClient class.

• W1 Apps connecting to remote servers via HTTP (as opposed to HTTPS) are susceptible to information theft via Man-in-the-Middle (MitM) attacks (Tendulkar and Enck 2014).

• W2 Apps can employ HostnameVerifier interface to perform custom checks on hostname when using SSL/TLS for secure communication. If these checks are incorrect, apps can end up connecting to malicious servers and be targets of malicious actions (Tendulkar and Enck 2014).

• W3 In secure communication, apps employ TrustManager interface to check the validity and trustworthiness of presented certificates. Like in W1, if these checks are incorrect, apps can end up trusting certificates from malicious servers and be targets of malicious actions (Tendulkar and Enck 2014).

• W4 Intents can be embedded in URIs. Apps that do not handle such intents safely (e.g., check intended app) can leak information (Google Inc 2017).

• W5 Web pages can access information local to the device (e.g., GPS location). Apps that allow such access without explicit user permission can leak information (Ryoji 2014).

• W6 When WebView is used to display web content, JavaScript code executed as part of the web content is executed with the permissions of the host app. Without proper checks, malicious JavaScript code can get access to the app’s resources, e.g. private files (Chin and Wagner 2013).

• W7 When loading content over a secure connection via WebView, host app is notified of SSL errors via WebViewClient. Apps ignoring such errors can enable MitM attacks (Tendulkar and Enck 2014).

• W8 When a web resource (e.g., CSS file) is loaded in WebView, the load request can be validated in shouldInterceptRequest method of WebViewClient. Apps failing to validate such requests can allow loading of malicious content (Chin and Wagner 2013).

• W9 When a web page is loaded into WebView, the load request can be validated in shouldOverridUrlLoading method of WebViewClient. Apps failing to validate such requests can allow loading of malicious content (Chin and Wagner 2013).