How accessibility undermines Android's security

As smartphones become more powerful and ubiquitous the incentives for malicious actors to hijack them continue to grow. Gaining access to a target's phone can yield bank account passwords, 2-factor authentication codes, contacts information, and all kinds of other juicy data. Google is constantly trying to protect their platform while still giving app developers freedom to make what they want, and for the most part they succeed. Applications are generally sandboxed from each other, and require granular permissions that users must manually accept in order to access hardware and OS resources. But there's one area where Android subverts its own strong sanboxing principles: accessibility services.

As the name suggests, accessibility services are designed to help users with disabilities, and include functionality like screen readers. But in order to do this accessibility services need to be able to access all UI elements and interactions. This means that any accessibility you have enabled can read and interact with anything that appears on your phone's screen.

Leaking passwords

Google has put in place a few security protections from these services. For example, whenever you type into a text field an accessibility event is sent with the new text to any accessibility services. When using a password text field, only the transformed characters are sent (so the service would only see something like •••••••••••••).

But to make passwords easier to type Android shows the last character in plain text for 1.5 seconds. The whole visible text is sent as an accessibility event every time the text content changes, so the last character typed is always sent in plain text. In this way, every password you type is leaked to accessibility services one character at a time.

Enabling third-party keyboards

The keyboard you're using (or "input method editor" (IME) in Android-speak) obviously has access to privileged information, so it can normally only be changed manually by the user in the settings app. This prevents apps from automatically setting a malicious keyboard as the default and using it to steal typed information. However, with an accessibility service's ability to simulate user interaction this service can install and enable a new IME all by itself without the user's knowledge.

Tricking users into enabling accessibility services

Fortunately the only way an app can get access to accessibility events is if the user manually enables it as an accessibility service in the settings app. The OS displays a dialog box listing all the permissions the accessibility service will have access to, and the user must manually accept these in order to enable it.

To prevent click-jacking attacks where malicious apps would overlay false information on top of system pop-ups like these, the Android AppOpsManager prevents apps from displaying overlays when permission dialogs are open. This is a good step, but it doesn't apply to the new "picture-in-picture" feature that allows an app to display videos on top of other apps. Attackers could use this to put misleading information on top of the permissions dialog, thereby tricking users into enabling a rogue accessibility service.

In Kalysch et al. researchers were able to trick users with misleading permissions descriptions into enabling an accessibility service that recorded UI events from other apps. They also discuss social engineering methods to trick users, for example a trojaned Google Play app that requires accessibility permissions to "function properly."

How to protect yourself

The easiest way is to simply not enable any accessibility services. Carefully examine the permissions of each app you install to make sure you're not accidentally giving away access to your passwords. Google is always working on ways to protect sensitive info from these services, but ultimately security comes down to the the responsibility of the end user.

References

1. Kalysch, A., Bove, D., & Müller, T. (2018, November). How Android's UI Security is Undermined by Accessibility. In Proceedings of the 2nd Reversing and Offensive-oriented Trends Symposium (pp. 1-10).