Application Vetting

On Android, accessing device calendar data requires that the app hold the READ_CALENDAR permission. Apps that request this permission could be closely scrutinized to ensure that the request is appropriate. On iOS, the app vetting process can determine whether apps access device calendar data, with extra scrutiny applied to any that do so.

On Android, accessing the device call log requires that the app hold the READ_CALL_LOG permission. Apps that request this permission could be closely scrutinized to ensure that the request is appropriate.

On Android, accessing the device contact list requires that the app hold the READ_CONTACTS permission. Apps that request this permission could be closely scrutinized to ensure that the request is appropriate. On iOS, the app vetting process can determine whether apps access the device contact list, with extra scrutiny applied to any that do so.

Ensure applications do not store data in an insecure fashion, such as in unprotected external storage, without acknowledging the risk that the data can potentially be accessed or modified by other applications.

Application vetting techniques could search for use of the Android PackageManager class to enumerate other apps, and such applications could have extra scrutiny applied to them. However, this technique may not be practical if many apps invoke these methods as part of their legitimate behavior. On iOS, application vetting techniques could similarly search for use of the private API call necessary to obtain a list of apps installed on the device. Additionally, on iOS, use of the private API call is likely to result in the app not being accepted into Apple's App Store.

Application vetting services could provide further scrutiny to applications that request permissions related to phone calls.

Applications using the android permission android.permission.RECORD_AUDIO or iOS applications using RequestRecordPermission could be more closely scrutinized and monitored. If android.permission.CAPTURE_AUDIO_OUTPUT is found in a third-party application, it should be heavily scrutinized.

During the vetting process applications using the android permission android.permission.CAMERA, or the iOS NSCameraUsageDescription plist entry could be analyzed more closely.

Applications could be vetted for their use of the clipboard manager APIs with extra scrutiny given to application that make use of them.

Enterprises performing application vetting could search for applications that declare the RECEIVE_SMS permission and scrutinize them closely.

Application vetting services can check for applications that request SMS permissions, and can provide extra scrutiny to those that do.

Applications could be vetted for their use of the clipboard manager APIs with extra scrutiny given to application that make use of them.

Static or dynamic code analysis to look for misuse of dynamic libraries. Increased focus on applications utilizing DexClassLoader.

Application vetting services could detect invocations of methods that could be used to execute shell commands.

Application vetting services could look for attempted usage of the Janus vulnerability.

A static analysis approach may be able to identify ransomware apps that encrypt user files on the device.^[1]

Application vetting services could be extra scrutinous of applications that request device administrator permissions.

App store operators and enterprises could assess reputational characteristics of the app, including the popularity of the app or other apps from the same developer and whether or not security issues have been found in other apps from the same developer.

Application vetting can check for the string BIND_DEVICE_ADMIN in the application’s manifest.

It is rare for applications to utilize Device Administrator access. App vetting can detect apps that do so, and those apps should be closely scrutinized. A static analysis approach can be used to identify ransomware apps including apps that abuse Device Administrator access.^[1]

Application vetting techniques could (either statically or dynamically) look for indications that the application downloads and executes new code at runtime (e.g., on Android use of DexClassLoader, System.load, or the WebView JavaScriptInterface capability, or on iOS use of JSPatch or similar capabilities). Unfortunately, this is only a partial mitigation, as additional scrutiny would still need to be applied to applications that use these techniques, as the techniques are often used without malicious intent, and because applications may employ other techniques such as to hide their use of these techniques.

Applications attempting to get android.os.SystemProperties or getprop with the runtime exec() commands should be closely scrutinized. Google does not recommend the use of system properties within applications.

Application vetting may be able to identify the presence of exploit code within applications.

Applications could be vetted for their use of the startForeground() API, and could be further scrutinized if usage is found.

Application vetting services can detect unnecessary and potentially abused location permissions or API calls.

Application vetting services could look for attempts to invoke the superuser (su) binary or modules related to rooting frameworks.

Applications that attempt to register themselves as a device keyboard or request the android.permission.BIND_ACCESSIBILITY_SERVICE permission in a service declaration should be closely scrutinized during the vetting process.

Applications that register an accessibility service should be scrutinized further for malicious behavior.

Application vetting services may be able to detect known privilege escalation exploits contained within applications.

On Android, applications must request the ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION permission to access the device's physical location. Extra scrutiny could be given to applications that request these permissions. On iOS, calls to the relevant APIs could be detected during the vetting process.

Application vetting techniques can scan for use of cleartext communication, insecure TrustManager implementations, and other potential network communication weaknesses. The Google Play Store now automatically assesses submitted applications for insecure TrustManager implementations.^[2]

Application vetting services could look for the native keyword in function definitions. However, this is widely used for legitimate purposes, so this may not be feasible. Application vetting services may also be able to detect behaviors carried out through the Native Development Kit (NDK) via dynamic analysis.

Closely scrutinize applications that request VPN access before allowing their use.

Application vetting techniques may be able to alert to the presence of obfuscated or encrypted code in applications, and such applications could have extra scrutiny applied. Unfortunately, this mitigation is likely impractical, as many legitimate applications apply code obfuscation or encryption to resist adversary techniques such as Repackaged Application. Dynamic analysis when used in application vetting may in some cases be able to identify malicious code in obfuscated or encrypted form by detecting the code at execution time (after it is deobfuscated or decrypted). Some application vetting techniques apply reputation analysis of the application developer and can alert to potentially suspicious applications without actual examination of application code.

Application vetting techniques could be used to attempt to identify applications with this behavior.

Applications with network connections to unknown domains or IP addresses could be further scrutinized to detect unauthorized file copying. Further, some application vetting services may indicate precisely what content was requested during application execution.

Applications can be vetted for their use of the Android MediaProjectionManager class, with extra scrutiny applied to any application that uses the class.

Application vetting services could provide further scrutiny to applications that request SMS-based permissions.

App vetting procedures can search for apps that use the android.os.Build class, but these procedures could potentially be evaded and are likely not practical in this case, as many apps are likely to use this functionality as part of their legitimate behavior.

Application vetting could be used to analyze applications to determine whether they access this information, including determining whether the application requests the Android ACCESS_NETWORK_STATE permission (required in order to access NetworkInterface information) or the READ_PHONE_STATE permission (required in order to access TelephonyManager information).

During application vetting, applications could be examined to see if they have this behavior, and extra scrutiny could potentially be given to applications that do.

Application vetting reports may show network communications performed by the application, including hosts, ports, protocols, and URLs.

Application vetting services could look for use of the accessibility service or features that typically require root access.

When vetting applications for potential security weaknesses, the vetting process could look for insecure use of intents. Developers should be encouraged to use techniques to ensure that the intent can only be sent to an appropriate destination (e.g., use explicit rather than implicit intents, permission checking, checking of the destination app's signing certificate, or the App Links feature added in Android 6.0). For mobile applications using OAuth, encourage use of best practice.^[3][4]

Application vetting services could look for usage of the SensorManager class, indicating that the application is attempting to access device sensors.