Recommended Responses to Security Issues
Malwarelytics for Android provides detection of many security issues. Moreover, it provides a huge variability in both configuring these protections and reactions to security violations. Some reactions, such as app termination, are provided by the SDK. Other reactions, such as displaying a warning screen or limiting functionality, are the responsibility of the application integrating Malwarelytics for Android.
The page provides a summary of recommended responses to various security issues that the SDK can help you with.
Responses to Security Issues
Some general approaches to handling a security violation (either RASP or Anti-Malware) might be:
- Display a Warning Message: The app can display a warning message informing the user that the app is not supported when a certain security feature is violated. This message should explain the security risks associated with using the app on such devices in such conditions and recommend fixing the issue for banking and financial operations.
- Limited Functionality: The app can limit its functionality when a security violation is detected. For example, it might disable some sensitive features like money transfers, or access to sensitive financial data to reduce the potential for unauthorized access and fraudulent activities.
- Terminate the App: If the app detects that it is running on a device with a security violation, it can immediately terminate itself to prevent any further access. This will help minimize the exposure of sensitive financial information and protect the user from potential security risks. As a general UX improvement, it is recommended to also open a website (in a browser outside the app) with an explanation while the app is being terminated.
- Silent Monitoring on Server: The app can silently monitor what’s happening on the device by sending data to the remote server. This approach is especially powerful when connected to a complex anti-fraud system analyzing inputs from various sources. The backend system can then decide the appropriate handling of the security issue. This approach should be used for all features in parallel to other approaches.
Responses to Anti-Malware Security Issues
Malwarelytics for Android ranks apps based on their potential to cause harm to the user or the apps. The most dangerous and most harmful apps are ranked with ThreatIndex.MALWARE. The second most dangerous category is ThreatIndex.HIGHLY_DANGEROUS. Any app ranked with one of these categories should be considered potentially harmful to the app.
For some apps, the SDK also provides additional flags indicating malware types or malware families. These flags further categorize apps by their dangerousness. Some examples of flags are trojan, spyware, exploit, adware. The most dangerous category of malware apps is banker. The SDK provides a direct method to check if the evaluated app is a banker (apkThreat.isBanker() returns true), in that case, the potential threat should be taken very seriously.
The recommended response is to block all app functionality when an app ranked as banker is reported and show a warning requiring the removal of the malware app. In case of detecting other ThreatIndex.MALWARE apps, we recommend blocking sensitive functionality and showing a warning requiring the removal of the app. In the case of apps ranked with ThreatIndex.HIGHLY_DANGEROUS we recommend displaying a warning screen with options for the user to uninstall those apps or to confirm that the apps are safe.
Summary of Responses to Malware Issues
| Threat | Response |
|---|---|
| Banker | Block all functionality and display a warning requiring the removal of the malware app. |
| MALWARE | Block sensitive functionality and display a warning requiring the removal of the malware app. |
| HIGHLY_DANGEROUS | Display a warning with options for removal or approval of the problematic app. |
Responses to RASP Security Issues
Malwarelytics for Android protects from a wide range of runtime issues. Some of them are more serious than others. Here we provide a list of recommended responses to these issues by a banking or a financial app.
Summary of Responses to RASP Issues
The summary here only mentions RASP protection features that have a RaspObserver callback method. These features can notify the integrating app about an issue and the app can react to it.
| Security feature | Recommended response to security issue |
|---|---|
| Rooted device | Terminate the app. If termination is not desirable, display a warning and limit functionality. |
| Emulator | Terminate the app. |
| Attached debuggers | Terminate the app. |
| Repackaged app | Terminate the app. |
| Screen sharing | Block screenshots preemptively and monitor silently. |
| Tapjacking | Block tapjacking preemptively and display a warning. |
| HTTP proxy | Display a warning. |
| VPN | Display a warning. |
| ADB | Display a warning. |
| Active calls | Limit sensitive functionality during a call. |
| App presence | Limit sensitive functionality when an unwanted app is installed. Use screenshot blocking preemptively. |
Passive RASP Features
Some RASP protection features are passive. They can be set up to block various attack vectors, but the app cannot be notified whether there was an attempt to perform such an attack.
The recommendation for passive features is to enable them to improve the app’s security.
| Security feature | Recommended setting |
|---|---|
| Screenshot blocking | Block screenshots. |
| Screen reader blocking | Block screen readers, but allow legitimate apps for disabled people. |
| Process name change | Change process name. |
RASP Info Methods
Besides RASP protection features having callback methods and passive RASP methods, there are several RASP info methods. These methods can be all accessed from RaspManager. When invoked, these methods return information about certain system’s security features.
The recommendation is to check for these occasionally or when there are other suspicious signals.
| Security feature | Info method | Recommended response |
|---|---|---|
| Usage of system screen lock | isDeviceUsingScreenLock(): Boolean |
Display a warning. Optionally limit sensitive functionality. |
| Biometry enrollment status | getBiometryDetection(): BiometryDetection |
Monitor silently. Optionally display a recommendation. |
| Play Protect status | isPlayProtectEnabled(): Boolean |
Display a warning. Optionally limit sensitive functionality. |
| Developer options status | isDeveloperOptionsEnabled(): Boolean |
Monitor silently. Optionally display a warning. |
Rooted Devices
It is generally recommended to avoid using rooted devices for banking or financial apps. Rooted devices make it easier for attackers to bypass security measures designed to protect financial data and the integrity of financial operations.
For these reasons, we generally recommend terminating the app and not allowing users to use it on a rooted device.
In case rooting is prevalent among the app’s user base we recommend at least displaying a warning message to the user and optionally limiting the app’s sensitive functionality.
Emulators
Emulators are not regular devices and no real user should use one for active usage of a banking or a financial app. Emulators pose multiple risks related to app security. Besides the obvious issues such as lacking hardware-backed security features, unreliable device identity, possibility of a modified operating system, there might be legal issues. Using emulators might be non-compliant with some regulations. There might be also repudiation risks when it might not be possible to tie a transaction or activity to a specific user.
For these reasons, we generally recommend terminating the app and not allowing users to use it on emulators.
Attached Debuggers
An attached debugger poses a huge danger to the app. There’s a huge number of potential issues such as data leakage, security breaches, transaction tampering, and injection of malicious code.
For these reasons, we generally recommend terminating the app and not allowing users to use it when an attached debugger is detected.
Repackaged Application
A repackaged application is a changed app and can’t be considered secure. It poses a danger to both clients and the financial institution issuing the app. Security features of such apps are compromised.
For this reason, the app should unconditionally terminate itself when it detects that it has been repackaged.
Screen Sharing
A financial or banking app handles a lot of sensitive data. Screen sharing (mirroring) can expose sensitive data to unauthorized viewers. Screen sharing can be also an attack vector for obtaining a user’s password or PIN.
Screen sharing can be partially mitigated by enabling screenshot blocking. This way most of the sensitive data should not be visible on the mirrored screen.
The recommended approach is to preemptively enable screenshot blocking on all sensitive pages. Screen sharing detection should be monitored silently, with no action unless additional suspicious signals appear.
Blocking Tapjacking
With tapjacking, also known as “UI redressing” or “clickjacking”, the risks are that unauthorized actions can be performed by tricking users into clicking into the app. This can lead to a data theft or even an account takeover if login credentials are captured.
The recommended approach is to try to block tapjacking. Android app can be set up to block clicks into the app when the screen is obscured. Malwarelytics for Android provides a way to block tapjacking when a problematic app capable of tapjacking is installed on the device. The observer is notified whenever tapjacking protection is activated or deactivated because such apps were installed or uninstalled.
The recommended configuration should block tapjacking when problematic apps are present. For tapjacking protection, an app evaluated as ThreatIndex.HIGHLY_DANGEROUS or worse is considered problematic. It’s recommended to ignore system apps in the configuration.
The recommended response to the tapjacking protection callback is to display a warning to the user. The message should inform about the suspicious apps that cause the tapjacking protection to be activated.
Active HTTP Proxy
Active HTTP proxy can exploit issues in client-server communication when not done correctly and can lead to data interception.
The recommended response to the detection of an active HTTP proxy is to display a warning to the user.
Active VPN
Active VPN can indicate a possible fraud attempt and might be a problem from the point of regulatory compliance.
The recommended response to the detection of an active VPN is to display a warning to the user.
Enabled ADB
ADB (Android debug bridge) is a powerful development tool providing wide-ranging access to the Android operating system. With ADB access it’s possible to access sensitive app and system data, execute potentially harmful commands, and modify system behavior. Still, the primary risk lies in the area of reverse engineering.
It’s recommended to display a warning on devices with active ADB.
Active Calls
An active call during active usage of the app poses a risk of social engineering attacks. These attacks are very frequent and create huge financial losses.
For this reason, it’s recommended to block any sensitive functionality during the period of the call. Or even automatically reject all operations and transactions initiated during an active call.
App Presence
Remote desktop apps are unwanted for all banking apps because they pose a huge risk of financial fraud. Remote desktop apps allow, as their name suggests, remote access to the device. Through these apps, the device can be fully remotely controlled. These apps are frequently used by attackers to perform financial fraud.
The recommended response is to limit functionality while an unwanted app is installed. At the minimum, all functionality involving sensitive operations and transactions should be blocked.
The recommended configuration should include enabled screenshot blocking as it might, in some cases, help impede the attacker’s efforts.
Screenshots
The screenshot blocking feature is preemptive. You can set it up to protect the contents of the app UI from being visible in screenshots, video, or screen casting. Screen casting can be performed through various modes of screen sharing or a remote desktop app. Screenshot blocking improves protection against these attacks.
The recommended configuration is to have screenshot blocking turned on.
Screen Readers
The screen reader blocking feature is preemptive. You can set it up to protect against apps capable of reading app screens through the system’s accessibility API. This API was designed to facilitate mobile device use for disabled people. Unfortunately, it is frequently misused for other purposes, some of which are malicious.
The recommended configuration is to have screen reader blocking turned on. Legitimate apps designed to help disabled people should be allowed.
Process Name
Changing the app process name is a protection technique for preventing or impeding reverse engineering efforts.
The recommended configuration is to change the process name to a stealthy one.
Usage of system screen lock
Device screen lock is an essential security feature of all Android devices. Not having a screen lock poses significant security risks, especially if sensitive applications like banking apps are installed. The stored personal and financial information is vulnerable to unauthorized access. Moreover, when a malicious individual gets physical access to the device, the possession authentication factor is effectively eliminated on such devices, and the risk of financial fraud greatly increases. Lastly, a lack of screen lock conflicts with several security standards and regulations, which can lead to compliance issues.
The recommended response is to display a warning and optionally limit the app’s sensitive functionality.
Biometry enrollment status
Usage of biometrics reduces the risk of unauthorized access to the user’s device and a banking app. PINs and passwords are frequently reused by the users. Also, there is a range of attacks for obtaining the user’s password or PIN such as phishing attacks, keyloggers, social engineering, shoulder surfing, screen overlay attacks, exploitation of various security vulnerabilities or Android API weaknesses, and many more.
The recommended response is to monitor the issue silently. Optionally the app can attempt to display a recommendation to the user.
Play Protect status
Google Play Protect is a built-in malware protection for devices that are part of the Google Play ecosystem. There are a few reasons for users to turn Play Protect off. Users usually turn it off when they wish to side-load an app and the automatic protection doesn’t allow the app to be installed. Malware apps sometimes try to turn Play Protect off to evade detection. Disabled Play Protect is a sign that there might be apps on the device that shouldn’t be there and that might pose some risk to the banking or financial app.
The recommended response is to display a warning and optionally limit the app’s sensitive functionality.
Developer options status
Enabled developer options mean that a section of system settings designed for developer use only has been enabled by the user. These settings allow to alter various system behaviors, some of them dangerous, for example, enabling debugging (see Enabled ADB for more details), enabling instrumentation, enabling overlays, fake location data, access to sensitive log and tracing data. For this reason, these settings shouldn’t be enabled by common users.
The recommended response is to display to monitor the issue silently. Optionally the app can display a warning.