Learn how to protect your apps against the new Android overlay threat - Promon

What is the Android overlay threat, and how can you mitigate the risks?

In today’s world of increased mobility for everyone, the accelerating use of mobile platforms for the storage, manipulation and transport of sensitive personal and corporate data has become inevitable. Already, use of this technology has opened up significant levels of data leakage from devices readily available in the marketplace, which are being exploited for mal intent. This is having a significant affect on industry worldwide, especially in the financial sectors.

Android OS presently accounts for almost 85% of that global mobile handset market (Gartner/Nov 2015) presenting a significant challenge for security from data leakage. Highlighted by one of the more recently discovered vulnerabilities, the Android Overlay Threat (also referred to as Slempo, Slembunk, Mazarbot, Gm-bot), which affects the Android platform. This puts over 97% of those Android devices at potential risk through the use of its open systems architecture. This mobile platform is targeted because of its ubiquitous use.

What is the Android overlay threat?

Simply put, the application overlay Malware inserts an invisible observation layer between the app and the handset’s screen. This could mean user data input could be copied, and/or the user to be encouraged into disabling security features by disguising the true nature of the interface’s capability as a more mundane feature. Which could allow the handset to be open to attack from other vectors.

Often the Malware is targeted at specific types of the applications of interest e.g. Banking/Finance/VPN. When those apps are launched the overlay deploys as a replicate version of the original application to perform its intended task. The Android Overlay Threat targets the system as a genuine user of system resources, in such a way that they are complex to detect.

Android OS versions affected:  All versions up to Version 5.1.

The footprints of the Android overlay threat

There are three different known attack types using application overlays on Android, they operate in the following ways:

1. A window that covers all or parts of the screen that displays something, but doesn’t intercept user touch events.
2. A window that covers parts of the screen to overlay parts of an application in the foreground, which does intercept user touch events. E.g. Click-jacking attacks where the user is invisibly duped into an action not normally undertaken e.g. disabling a security feature.
3. Launch a new activity that looks like the app in the foreground and completely overlay it. This is the easiest and most powerful method since it gives the attacker full control without the need to perfectly adjust to the apps UI.

The Android Overlay Threat appears as genuine system requests, making detection of the problem more complex since access to the system is a bona fide request, which is often granted with little or no user permissions checking. The attacker does need to have some intelligence of the system to be successful; certain items of information are required in order to mount an attack. The degree of difficulty varies depending on the version of Android OS.

Defense against the Android overlay threat

App shielding into the application allows us to significantly enhance control of the application’s environment and take measures to mitigate the onward data theft threat. Reducing attacker success and risk posed by this threat. The nature of the Android Overlay Threat makes it important to make app shielding and the additional enhancements part of your security policy.

About Promon SHIELD™

Promon’s unique shielding technology is integrated into the app that it is intended to protect. It protects by making it impossible to perform static analysis of the application’s code, removing the ability to directly exploit the app itself. This is performed in a number ways:

• Obfuscation of the code (masking it’s intent)
• Removal and encryption of large portions of the application’s content –making it impossible to reverse engineer.
• Encryption of the application data itself.

These processes force attackers to attack the application when Promon SHIELD™ is in control of the app’s execution environment (during runtime).

Keeping control – Promon’s runtime protection

• Promon SHIELD™ is always first to start. Detection of jailbreak, system rooting, emulators and hooking frameworks etc.
• Once completed the application is decrypted and launched.
• Whitelisted modules only (created by the shielding process) are allowed to exist in the runtime environment.
• Real-time protection against known and unknown threats is maintained as long as the shielded app is active. Default policy is that “anything not normal is forbidden”. Enterprises’ can determine their own security policy and behavior upon problem detection.

Further threat mitigation – continued risk reduction

Promon has taken the lead to provide it’s customers additional steps to marginalise the threat to their apps and reduce pain.

These encompass the measures already embedded within the shielded application (i.e. Promon’s obfuscation and runtime protection which cannot be gleaned from or through the overlay process, and additionally:

• Injecting of individual client certificates onto the app on the users device, so that the device alone can only be used to interact with the application and the end service. If the handset is sold/lost or stolen it will need to be re-registered with a new device before access can be granted.
• Use of Promon’s Secure Storage technology to further enhance security of key data, by implementing a dual end security solution at the service delivery point.

Therefore even if credentials are stolen, the thief cannot adequately do anything with those details because additional layers of security have been integrated into the overall system linking the device to the user. There are further security measures and best practice recommendations, which will enhance security and make the task of hijacking sensitive data more difficult.

• Personalisation of the login pages/interface e.g. users avatar or unique pieces of information that identifies the end system back to the user at the time of use.
• Policy of not allowing the use of single factor authentication alone. Multiple factor authentication should be minimum level set for connection to the service.

The last steps are optional, but threat and risk reduction is an action policy that requires multiple touch points. Taking action to shield the application against threat in an insecure environment is a first step, but the additional security measures against potential attackers, makes easy access and use of stolen data much more complex.