Key Sniffing with Android

A few years back I worked with a colleague who was blind. Whilst this has the side effect of showing me that playing with a guide dog in the office is a good way to release stress, it introduced me to the world of accessibility devices and services.

He had a selection of devices that allowed him to do his job: from a braille PDA, to a keyboard with a braille “display” underneath, to screen readers, dedicated watches and reading books through scanners, OCRs and an audio reader.

The idea always occurred to me about how the software and feedback coped with passwords: what gets fed back to the speakers or Braille reader.

uiautomator

Move on a few years and I’m messing around with Android and discover the built in testing command, uiautomator. This was useful whilst I was writing my PIN cracking script, but it was whilst messing around with some of the other arguments I discover a more interesting facility: the “events” parameter.

This parameter simply dumps accessibility events to the current session until the process is killed:

This could be interesting, so let’s see what’s happening when we’re entering the unlock password for the device. So, I set a simple password on the device (“dave”), locked it, started uiautomator and unlocked the device:

The bits I’ve highlighted in there are from the Android AccessibilityEvent object, which breaks down into the following bits:

This is a bit disappointing, the events understand that a UI item can take a password and blank out the event as appropriate.

Oh well, I’m used to disappointment and trying multiple things. Next, let’s set up a PIN and attempt to use this to unlock the device. To cut out the unwanted code I wrote a bit of native code (called sniffkeystrokes) that spawns uiautomator in the background and filters the response to only output the Text section of TYPE_VIEW_CLICKED events.

So, I unlocked the device, set up a PIN, then loaded Chrome as a test to make sure my sniffer was working. Then locked the device and unlocked it:

And there we see my PIN sniffed from the command line in cleartext. Like, WTF?!
There are some things to note about this:

1. I’m the standard shell user, not root – this is the default user when connecting through adb (USB debugging mode)
2. I tried this first on version 4.2.2 (Jelly Bean). This is valid all the way up to, at least, version 4.4.2 (Kit Kat). I haven’t tried it on later versions yet
3. This was performed on a device (my Hudl) with a vanilla Android keyguard; your mileage may vary with devices made by manufacturers who alter these (e.g. Samsung, HTC)

Why Does This Happen

So why is this behaviour different? One of the nice things about Android (other than its superior interface and lack of Appleness) is that it is mostly open source, so we can actually go and have a look and see what the differences are.

We can find the source of the screen lock by looking up its component name (keyguard) at android.googlesource.com. Each of the modules are broken out by name and can be read separately . Note, the directory structure of the keyguard source changes for Kit Kat, I’m taking this from Jelly Bean (4.3 to be precise).

We’ll also need to look at the layout files for the screens. These are XML files that describe the UI elements.

First off, we can look at the password interface, in the layout (keyguard_password_view.xml), we can see it’s a simple password entry text field:

This tells the UI that it should be treated as a password field, as the UI itself handles the keyboard it doesn’t need to worry about anything else.

If we look at the layout for the PIN view (keyguard_pin_view.xml), we see a much different story; in essence the keys are built up with each button being a single entity of the class com.android.keyguard.NumPadKey:

We can look at the code for NumPadKey (NumPadKey.java), this shows that the NumPadKey is inherited from Button (so will send accessibility events):

How to Abuse It

We already know that we can sniff the keystrokes from an adb interface, if somebody is foolish enough to leave USB debugging enabled. A custom executable can be written in about 20 lines of code and can be uploaded over adb in seconds (storing it somewhere like /data/local/tmp). This could allow somebody to prime a phone if the owner has left it for some time (e.g. while going off to get a coffee).

That’s not enough though! Can we do this as an app so that we can grab the PIN of people who haven’t or don’t know how to enable USB debugging?

Yes, although it may not be quite as easy to do as it sounds. First off, we need to understand a bit about how Android apps work. Simply stated apps can have components that can either be:

1. An Activity (something that interfaces with the user)
2. A Service (something that sits in the background and does stuff)
3. A Broadcast Receiver (something that sits in the background and receives messages)

TalkBack

To set up a trap here we need to set up an accessibility service called, because I’m not feeling creative today, Beardiness; to sit in the background and trap messages. The documentation about accessibility services is particularly useless in that special “too much information way”; i.e. the API is fully documented, but there’s nothing to suggest how it ought to be brought together, which made this hard for me as I’m not an Android developer and I’m an old C coder, so can read Java better than I can code it.

So I did what any Proof of Concept merchant does: I steal, from where there’s a minimalist service that just records events to the system log. It just needs one permission:
BIND_ACCESSIBILITY_SERVICE.

I added a simple activity to the code (to “pretend to be a real app”) and then wondered why it still didn’t run. As it’s an accessibility service it needs an extra step to be taken in Settings – Accessibility to turn it on (here’s the default screen, showing the standard TalkBack service). Once you enable it you get a special warning to tell you that it have a security risk for any text field, but notice the words “except passwords.” Not quite true…

So, we get our victim to install our dodgy app and turn it on in the accessibility settings, then we can watch them enter the PIN. As our proof of concept is simply recording it in the system log, we’re going to show it from there, although in a real attack we would either send it to a malicious webserver or store the keystrokes on the SD-card so that we can remove it later at our leisure.

Conclusions

And there we have an exploit that we can use from either adb or from an app. It’s not perfect as one requires that the user enables debugging mode (and doesn’t use authorisation for it) and the second requires a bit of social engineering, but it could still allow the gathering of the user’s PIN.

Remember that in Android, the PIN doesn’t just allow the unlocking of the device, it also is used as the key for hardware encryption and also for the keystore; potentially allowing us access to these.

The root problem here is that the developers made the classic mistake of rolling their own interface and not thinking about the security aspects. The fix is easy: stop accessibility events from firing from keyguard, or alert the user not to use a PIN to lock their device if they’re using accessibility features.