Android 14 security feature aims to block malware from stealing 2FA codes

Mishaal Rahman
Try Esper for Free
Learn about Esper mobile device management software for Android and iOS

Android’s Accessibility API offers a way for developers to build tools that help users with disabilities. The API, for example, enables apps to read the contents of the screen and perform inputs on behalf of the user, functions that are essential to screen readers and alternative input systems. These same functions also enable malware to do things like steal a 2FA code from an authenticator app or press a button in a banking app to transfer money out of a user’s account. To mitigate these kinds of attacks, Android 14 introduces a new API that lets developers limit what kinds of accessibility services can interact with their apps.

In early 2020, Dutch mobile security firm ThreatFabric spotted a version of the “Cerberus” malware strain that could steal 2FA codes from the popular authenticator app Google Authenticator. Just last month, Italian firm Cleafy identified another malware strain called “Nexus” that had the ability to snoop on 2FA codes generated by Google Authenticator. Both of these malware strains were found to abuse Android’s Accessibility API to retrieve 2FA codes in the Google Authenticator app. 

Many other malware strains targeting Android have been identified over the years, and they’re commonly found to have abused the Accessibility API. That’s why Google has been cracking down on misuse of the Accessibility API for the past several years. 

In Android 12, for example, the company introduced the isAccessibilityTool attribute. Only apps that are actually designed to support people with disabilities (such as screen readers) are allowed to declare that they’re an accessibility tool and be uploaded to Google Play. Accessibility tools are exempt from completing the prominent disclosure and consent requirement that Google Play requires for non-accessibility tools, ie. apps that use the Accessibility API for any purpose other than aiding people with disabilities.

In Android 13, Google made another significant change to mitigate Accessibility API abuse. The Android OS now prevents the user from easily enabling the Accessibility Service of an app that was sideloaded from outside of an app store. The OS now keeps track of how an app was installed. If it was installed using a non-session-based installation method, then it probably wasn’t installed by an app store. If it was installed by an app that uses the session-based installation method, then the app that did the installation was probably an app store. In the former case, the user is restricted from enabling the sideloaded app’s Accessibility Service, because the non-session-based method is typically invoked through users opening an APK they downloaded from the web or from within an app that has no need to implement app store-like functionality.

Restricted setting
When an app is sideloaded using the non-session-based installation method (eg. by downloading an APK file through their browser and tapping to open the APK file, which invokes the system Package Installer), the Android OS blocks the user from enabling its Accessibility Service.

This new restriction made it harder for a malicious app to trick users into enabling its Accessibility Service, because the dialog gives users pause about what they’ve installed. However, the restriction wasn’t absolute. Users could manually go to a malicious app’s info page and tap “allow restricted setting” from the overflow menu, at least prior to Android 14. Malware authors could also use a dropper that implements the session-based installation API to sideload the malicious app payload that uses the Accessibility API. Once a user actually enables a malicious app’s Accessibility Service, there’s nothing stopping it from snooping on other apps or sending unwanted inputs on behalf of the user.

Starting in Android 14, though, developers can prevent non-accessibility tools from interacting with their app. By setting the new ACCESSIBILITY_DATA_PRIVATE_YES attribute on a View, only accessibility tools can interact with that View. This can be used by an app like Google Authenticator to ensure that only declared accessibility tools (like TalkBack) can read 2FA codes.

Accessibility data private
Documentation for the new ACCESSIBILITY_DATA_PRIVATE_YES attribute.

Android’s FLAG_SECURE attribute is commonly used to prevent DRM-protected content from appearing in screenshots, screen recordings, or on non-secure displays, but it does not protect against a rogue Accessibility Service, as demonstrated by researcher Yanick Fratantonio. Using his proof of concept as a basis, I created a mock authenticator app that shows a TOTP in a View without ACCESSIBILITY_DATA_PRIVATE_YES enabled, a View with FLAG_SECURE enabled, and a View with ACCESSIBILITY_DATA_PRIVATE_YES enabled. Only the View with ACCESSIBILITY_DATA_PRIVATE_YES enabled prevented the 2FA code from being leaked.

Android 14’s new ACCESSIBILITY_DATA_PRIVATE_YES attribute will be useful for apps that deal with sensitive user data like personal details or passwords or apps that want to limit fraud. Since it’s only available for apps compiled against the Android 14 SDK, however, it will take some time for it to be implemented broadly.

While there’s seemingly nothing preventing malware from falsely declaring the isAccessibilityTool attribute, in doing so they would have to implement seemingly genuine accessibility functionality for users with disabilities to make it onto Google Play. These malicious apps would then have a harder time targeting users without disabilities, however. Malware could falsely declare the isAccessibilityTool attribute in an app that appeals to those users if the malicious app is delivered outside of Google Play, but keep in mind that Android 13+ made it harder to enable a sideloaded app’s Accessibility Service.

Ultimately, this new Android 14 security feature presents just one more roadblock that malware has to overcome to harm users. Adding one more roadblock could save some users (primarily those who use trusted app stores like Google Play) from getting their data stolen.

Everything You Need to Know about MDM


No items found.
No items found.

Keep Exploring

No items found.
Mishaal Rahman
Mishaal Rahman

Mishaal Rahman is a Technical Editor at Esper. He has been an Android user for over a decade and has been at the forefront of Android news coverage for half a decade. His in-depth breakdowns of new Android versions have been referenced across the Internet.

Mishaal Rahman
Learn about Esper mobile device management software for Android and iOS
Featured resource
Read more
Featured resource
Considerations for Building Android Apps for Company-Owned Devices
Your app delivers your customer (or employee) experience, making it a crucial piece of your overall solution. Use this guide to understand the considerations of designing and building your perfect app for dedicated device use cases on Android hardware.
Download the Guide

Esper is Modern Device Management

For tablets, smartphones, kiosks, point of sale, IoT, and other business-critical edge devices.
MDM Software
Kiosk mode icon as a feature in mobile device management software

Kiosk mode

Hardened device lockdown for all devices (not just kiosks)
App management icon as a feature in mobile device management software

App management

Google Play, Apple App Store, private apps, or a mix of all three
Devices groups icon as a feature in mobile device management software

Device groups

Manage devices individually, in user-defined groups, or all at once
Remote tools icon as a feature in mobile device management software

Remote tools

Monitor, troubleshoot, and update devices without leaving your desk
Touchless provisioning as a feature in mobile device management software

Touchless provisioning

Turn it on and walk away — let your devices provision themselves
Reporting and alerts as a feature in mobile device management software

Reporting and alerts

Custom reports and granular device alerts for managing by exception