Ghera

Ghera is a repository of benchmarks that capture vulnerabilities previously observed in Android apps. Almost all of the captured vulnerabilities have been reported and documented in prior work.

Each benchmark capturing a specific vulnerability X contains three apps: a benign (vulnerable) app with vulnerability X a malicious app capable of exploiting vulnerability X in the benign app, and a secure app without vulnerability X and, hence, not exploitable by the malicious app. Each benchmark is accompanied by instructions to demonstrate the captured vulnerability (and the corresponding exploit) by building and executing the associated apps. Consequently, the presence (and absence) of vulnerabilities and exploits in these benchmarks is verifiable.

Currently, Ghera contains only lean benchmarks. These benchmarks are stripped down apps that exhibit vulnerabilities and exploits with almost no other interesting behaviors. In the future, we plan to add real world apps that have been reported to exhibit vulnerabilities as fat benchmarks to Ghera.

For more information about Ghera, please refer to
Ghera: A Repository of Android App Vulnerability Benchmarks by Joydeep Mitra and Venkatesh-Prasad Ranganath. International Conference on Predictive Models and Data Analytics in Software Engineering (PROMISE) 2017. PREPRINT

The repository is located at https://bitbucket.org/secure-it-i/android-app-vulnerability-benchmarks/.

Catalog of Vulnerabilities

Crypto

BlockCipher-ECB-InformationExposure-Lean: 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.

BlockCipher-NonRandomIV-InformationExposure-Lean: 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.

ConstantKey-ForgeryAttack-Lean: Cipher APIs rely on unique keys. If such keys used to encrypt information are stored in an 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.

ExposedCredentials-InformationExposure-Lean: Apps can safely store encryption keys in a keystore. But if the keystore is accessible to other apps and the key is not password protected then a malicious app can retrieve it from the keystore. Hence, such apps are susceptible to leaking sensitive information.

PBE-ConstantSalt-InformationExposure-Lean: Password based encryption (PBE) uses a salt to generate 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.

ICC

DynamicRegBroadcastReceiver-UnrestrictedAccess-Lean: 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.

EmptyPendingIntent-PrivEscalation-Lean: A component can use a pending intent to allow another component to perform an action 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 originating component.

FragmentInjection-PrivEscalation-Lean: A fragment is a reusable class implementing a portion of an activity. An activity can accept a fragment name as input and load it at runtime. If the fragment name is not validated then any fragment can be loaded in an activity.

HighPriority-ActivityHijack-Lean: 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 low priority activities.

ImplicitPendingIntent-IntentHijack-Lean: Pending intents can contain implicit intents. Hence, services processing of the implicit intent contained in a pending intent are vulnerable as in IncorrectHandlingImplicitIntent-UnauthorizedAccess-Lean.

InadequatePathPermission-InformationExposure-Lean: 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).

IncorrectHandlingImplicitIntent-UnauthorizedAccess-Lean: 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, 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.

NoValidityCheckOnBroadcastMsg-UnintendedInvocation-Lean: Broadcast receivers registered for system intents (e.g.,low memory) from Android platform are by de- fault exported without any access restrictions. If such a receiver services intents without verifying the authen- ticity of intents (e.g.,requested action), then it may be vulnerable like the components in I7.

OrderedBroadcast-DataInjection-Lean: Broadcast receivers respond to ordered broadcasts in the order of priority. By using appropriate priorities, receivers can modify such broadcasts to perform unintended actions.

StickyBroadcast-DataInjection-Lean: 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. This can lead to information leak and data injection.

TaskAffinity-ActivityHijack-Lean: 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.

TaskAffinity-LauncherActivity-PhishingAttack-Lean: 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.

TaskAffinity-PhishingAttack-Lean: 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.

TaskAffinityAndReparenting-PhishingAndDoSAttack-Lean: 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.

UnhandledException-DOS-Lean: Apps that fail to handle exceptions while servicing incoming intents can be crashed by sending appropriately crafted intents. Hence, such apps are vulnerable to Denial of Service attack.

UnprotectedBroadcastRecv-PrivEscalation-Lean: 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 operation without sufficient permissions.

WeakChecksOnDynamicInvocation-DataInjection-Lean: The call method of Content Provider API can be used to invoke any provider-defined method. With a reference to a content provider, this method can be invoked without any restriction leading to both information leak and data injection.

Networking

CheckValidity-InformationExposure-Lean: Android apps can use SSL/TLS to securely communicate with a web server via a chain of certificates signed by trusted CAs. Every certificate in the certificate chain has an expiration date which can be checked by the app. If an app connects to a server without checking the expiration date of a certificate then the app might connect to a malicious server using the expired certificate.

IncorrectHostNameVerification-MITM-Lean: Apps can employ HostnameVerifier interface to perform custom checks on host name 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.

InsecureSSLSocket-MITM-Lean: Apps that use the SSLCertificateSocketFactory.getSocket(InetAddress, ...) method are vulnerable to MITM attacks.

InsecureSSLSocketFactory-MITM-Lean: Apps that use the SSLCertificateSocketFactory.getInsecure() method are vulnerable to MITM attacks.

InvalidCertificateAuthority-MITM-Lean: In secure communication, apps employ TrustManager interface to check the validity and trustworthiness of presented certificates. Like in W2, if these checks are incorrect, apps can end up trusting certificates from malicious servers and be targets of malicious actions.

OpenSocket-InformationLeak-Lean: 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.

UnEncryptedSocketComm-MITM-Lean: Apps can communicate with remote servers via insecure TCP/IP connections. Such scenarios are susceptible to MitM attacks.

UnpinnedCertificates-MITM-Lean: An app can store a certificate it trusts and only trust that certificate when connecting to a web server. This is called certificate pinning. Not pinning a trusted certificate can compromise an app's security if a certificate trusted by the device is compromised.

NonAPI

MergeManifest-UnintendedBehavior-Lean: When apps use libaries, the manifest file of the library is merged with the manifest file of the app. If the manifest of the library has a vulnerability e.g., exported component that should not be exported, then the app unknowingly inherits the vulnerability.

OutdatedLibrary-DirectoryTraversal-Lean: When an app uses an external library, it may use older versions of the library which may contain vulnerabilities. As a result, the app may exhibit vulnerabilities as result of using an outdated library.

Permission

UnnecesaryPerms-PrivEscalation-Lean: Android requires apps to explicitly request for permission when invoking a protected API. However, if an app asks for more permissions than necessary then the permission can be (mis)used by less privileged apps to invoke protected APIs.

WeakPermission-UnauthorizedAccess-Lean: 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.

Storage

ExternalStorage-DataInjection-Lean: 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.

ExternalStorage-InformationLeak-Lean: The same aspect from ExternalStorage-DataInjection-Lean can lead to information leak.

InternalStorage-DirectoryTraversal-Lean: 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).

InternalToExternalStorage-InformationLeak-Lean: Apps can copy data from internal storage to external storage. This could lead to information leak if such appps accept input from untrusted sources to determine the data to be copied.

SQLite-execSQL-Lean: SQLiteDatabase.execSQL() method can be used by apps to update data. If such uses rely on external inputs and use non-parameterized SQL queries, then they are susceptible to sql injection attack.

SQLlite-RawQuery-SQLInjection-Lean: 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 attack.

SQLlite-SQLInjection-Lean: 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 susceptible to sql injection attacks.

System

CheckCallingOrSelfPermission-PrivilegeEscalation-Lean: During IPC, checkCallingOrSelfPermission method can be used to check if the calling/caller 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 lead to privilege leaks when the calling component does not have permission P.

CheckPermission-PrivilegeEscalation-Lean: 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.

ClipboardUse-InformationExposure-Lean: Android allows all apps to access clipboard information. If an app allows users to copy sensitive information then that information is written to Clipboard. A malicous app can access Clipboard and retrieve the sensitive information.

DynamicCodeLoading-CodeInjection-Lean: Android apps can use dynamic code loading features to dynamically load and execute code not packaged with the app. If the app does not verify the integirty and authenticity of the code before dynamically loading and executing it then the app is vulnerable to code injection attacks.

EnforceCallingOrSelfPermission-PrivilegeEscalation-Lean: During IPC, enforceCallingOrSelfPermission method can be used to check if the calling/caller process or the called process has permission P. Like in Y1, improper use of this method can lead to privilege leaks.

EnforcePermission-PrivilegeEscalation-Lean: 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.

UniqueIDs-IdentityLeak-Lean: An app can use device identifiers to identify unique app instances. Collecting such information could lead to exposing sensitive data related to the device. Malicious actors can use such information to track the device.

Web

HttpConnection-MITM-Lean: Apps connecting to remote servers via HTTP (as op- posed to HTTPS) are susceptible to information theft via Man-in-the-Middle (MitM) attacks.

JavaScriptExecution-CodeInjection-Lean: Apps can load web content via the WebView API. Apps can control if JavaScript should be allowed to execute in the WebView. If the control is enabled then the app could potentially allow malicious JavaScript to be injected and executed in the context of the app.

UnsafeIntentURLImpl-InformationExposure-Lean: Intents can be embedded in URIs. Apps that do not handle such intents safely (e.g., check intended app) can leak information.

WebView-CookieOverwrite-Lean: Apps that allow websites viewed through WebView may enable cookie overwrite attacks.

WebView-NoUserPermission-InformationExposure-Lean: Web pages may access information local to the device (e.g., GPS location). Apps that allow such access without explicit user permission may leak information.

WebViewAllowContentAccess-UnauthorizedFileAccess-Lean:Apps that allow Javascript code to execute in a WebView without verifying where the JavaScript is coming from, can expose the app's resources.

WebViewAllowFileAccess-UnauthorizedFileAccess-Lean: 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.

WebViewIgnoreSSLWarning-MITM-Lean: 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.

WebViewInterceptRequest-MITM-Lean: 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 validat such request can allow loading of malicious content.

WebViewLoadDataWithBaseUrl-UnauthorizedFileAccess-Lean:Apps that use loadDataWithBaseUrl() with a file scheme based baseURL (e.g., file://www.google.com) and allow the execution of JavaScript sourced from unverified source may expose the app's resources.

WebViewOverrideUrl-MITM-Lean: When a web page is loaded into WebView, the load request can be validated in shouldInterceptRequest method of WebViewClient. Apps failing to validate such requests can allow loading of malicious content.

WebViewProceed-UnauthorizedAccess-Lean:Apps that use HttpAuthHandler#proceed(username, password) to instruct the WebView to perform authentication with the given credentials may give unauthorized access to third-party when the apps do not validate credentials, e.g., by sending token of previously validated credentials.