Defending Mobile Banking Application Against Android Accessibility Abuse

Since 2017, the security community started to register a new type of attack emerging from standard overlays. In this attack vector, the malicious application utilizes old-fashioned clickjacking, to gain even more powerful permission – AccessibilityService API. This attack is still valid and widely used. This attack is nicknamed “Cloak & Dagger” and can be used for multiple malicious intents, such as:

• Perform keylogging
• Read any text displayed on the screen (such as OTP)
• Listen to touch events (keylogging of custom keyboards)
• Perform actions on the user’s behalf
• Etc.

ThreatMark SOC & RD team analyzed the attacks and present a high-level description.

Existing ThreatMark customers are already protected against such attacks. Because some companies start to prefer a more active approach (blocking such attacks on top of detection), ThreatMark updated its SDK to block Accessibility API and prevent sensitive data from leaking the application.

Android Accessibility API Feature

Android Accessibility API is an Android feature designed to increase application usability for users with visual, motor or cognitive impairment. An application providing accessibility services can perform activities such as text-to-speech conversion or automated interface interaction performing activities on behalf of the user.

Feature Ecosystem and APIs

Android introduces accessibility features in API level 4 (Android 1.6) and since then has two parts:

• AccessibilityEventSource – all applications publishing accessibility events
• AccessibilityService – applications providing text-to-speech and other features

These are very well documented in the Developer Documentation from Android.

Accessibility Events

Android objects (such as Views) implementing AccessibilityEventSource interface can use sendAccessibilityEvent. Default controls (such as buttons, textboxes or even composite objects like WebView) have already implemented accessibility events. Events tracked by accessibility features are translated to AccessibilityEvent and broadcasted.

Sending Events

Accessibility events are sent by any application using default controls or implementing custom methods to publish the events. An application can declare, which portion of the application should be monitored by AccessibilityService by setting property isImportantForAccessibilitymethod of views.

Receiving Events

Accessibility events can be intercepted by implementing AccessibilityService Interface. In order to use this API, an application requires BIND_ACCESSIBILITY_SERVICE permission. Accessibility service will ignore events sent from views marked as IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDANTS by default, however, this can be overridden by adding FLAG_INCLUDE_NOT_IMPORTANT_VIEWS flag to AccessibilityServiceInfo

Cloak and Dagger Attacks

Cloak and Dagger attacks were first registered during 2017 and are still present since then. This attack is using standard Android applications without breaking the Android sandbox. In most cases, the harmful application was hosted on an official Google Play Store and evaded an automated application scan used for application screening. This service is leveraging two permissions on Android platform to mount its attack:

• BIND_ACCESSIBILITY_SERVICE
• SYSTEM_ALERT_WINDOW

At the first stage, malware is installed without special AccessibilityService permission. Using an overlay window, it performs a clickjacking attack on a user to grant him the second permission.

Once the application receives both permissions (is selected as accessibility service in Android system settings by a user clicking on clickjacking layer), it can perform almost anything.

• Read any text presented on the screen (such as OTP)
• Perform keylogging
• Read touch events (such as PIN on software keyboard of banking application)
• Device unlock through PIN injection (simulating touch events)

Protection by ThreatMark

Some companies are offering solutions actively changing isImportantForAccessibilityMethod or recommending to subclass View and use it throughout this application. According to our research, this method can be circumvented.

We think, that sophisticated attack like this should be addressed by layered approach maximizing probability, that the attacker will be detected at some point. This is where we recommend ThreatMark approach.

ThreatMark currently protects users against such attacks using multiple means. ThreatMark SDK performs a scan of all installed and running applications and compares it to it’s own and also third-party malware database.

The malware might be also zero-day – not seen before by any client. In this case, ThreatMark SDK reports all applications with dangerous permissions such as the ability to perform Overlay to its Security Operations Center for further classification. Meanwhile, signal Overlay is created in corresponding ThreatMark installation and based on rule engine configuration, this can result in termination of access token on an existing session, login denial, or silent notification for further investigation.

Further, in the fraud attempt, the attacker might want to use the credentials obtained by this attack. They will either perform such action from their device/emulator or try to robotically call banking internal APIs (use by banking application). In both cases, another layer of protection is there to prevent the attacker from doing so. Once any activity is registered by ThreatMark, various checks including behavioral profiling and bot detection are triggered, assessing the probability of the request being sent by a human and being genuine activity performed by the owner of the account.

In the upcoming version of our Android SDK, we are introducing a new, optional API method for active protection. Once host application calls protectAgainstAccessibility() in its Java/Kotlin code, all existing and future views are located by ThreatMark SDK and the hook is installed effectively preventing all AccessibilityEvents to be broadcasted.