Android 'Pixnapping' attack can capture app data like 2FA codes

Security researchers have resurrected a 12-year-old data-stealing attack on web browsers to pilfer sensitive info from Android devices. The attack, dubbed Pixnapping, has yet to be mitigated. Conceptually, it's the equivalent of a malicious Android app being able to screenshot other apps or websites. It allows a malicious …

[MiguelC]

Re: "it only leaks 0.6 to 2.1 pixels per second, though the authors say that's sufficient to recover Google Authenticator codes"

AFAIK Google Authenticator codes are 6 digits long and last for 30 seconds, so the hack would have to produce a valid result using a maximum of 50 pixels.

Only 50 pixels from 6 separate digits means a lot of guessing to get the right code.

[DS999]

50 pixels for 6 digits is probably sufficient to get it on your first try more often than not. For modern antialiased fonts on a high resolution display there is almost certainly one pixel that's unique to each digit, that means you need 60 pixels to unambiguously determine the digits. If so, getting 30 of them (1 pixel per second) gives you a 50/50 chance of getting the code. If they can hit 2 pixels per second they're at 100%.

If they emulated a 7 segment display then the problem is different - you want one pixel for each segment for each digit, meaning 42 pixels would be enough to reach 100%. If there is enough overlap between digit bitmaps for the font Google uses you might be able to use a combination of the 7 segment technique and the one pixel per digit technique to do slightly better than needing 60 pixels to hit 100% but that's guaranteed to be your worst case.

[dkohlbre]

co author here:

Yes, this is about right. For the 2FA app we only need to distinguish digits from a known font, with known placements.

The overlap-and-eliminate-possibilities approach works great here (we adapt the technique from Paul Stone's HTML5 work https://media.blackhat.com/us-13/US-13-Stone-Pixel-Perfect-Timing-Attacks-with-HTML5-WP.pdf)

Depending on the model of the device, this gets us anywhere from a 75-25% success rate on getting the entire 6-digit code correct. (And there is a nice accuracy-speed tradeoff knob we can tune.)

We have some details on our experiments in the paper (pixnapping.com/pixnapping.pdf)

[IGotOut]

Even if you had a valid result in those 30 seconds, then what? It's now no longer valid,

And if like me, you have 6 codes visible (Aegis rather than Google), plus all the information, such as the website it applies to and user name, it's going to be very hard to get any info

Plus if my authenticator app suddenly fired up for no reason, I'd be extremely suspicious.

[dkohlbre]

FWIW, many sites will take the last N codes, where N>1, to account for typing time and such.

Recovering static text (e.g. the account/website for a particular entry) is easier than dynamic text, and can be done before stealing the 2FA code itself.

In the PoC attack the target app fires up in the background automatically, and is not visible at any time to the user/victim during the attack.

There are some slightly jank visual effects that happen when the attack first starts, but they don't show the 2FA app at any point.

There is a demo video on pixnapping.com with a recording of the attack in realtime.

[Charlie Clark]

A simple way of thinking about this would be to take any code and start removing pixels, comparing the results with all other codes undergoing the same operation. In reality, you can model this mathematically per number per pixel to determine the minimum number of pixels per figure for accurate identification and group them in sets of six. This will give you groups of related codes, but also ways to differentiate between them to inform in future guesses.

[that one in the corner]

Tacky UI weaponised?

So, if I've understood TFA and the info on the pixnapping.com website, this works because Android allows you to render your UI to have as is background a blurred view of whatever is being displayed underneath your window. The clever bit then being to extract data from the actual process involved in that blurring.

In other words, a horrid and tacky bit of UI "functionality"[1] has geen weaponised. And as a mere end-user I can't protect myself by telling the OS to just not support this ghastliness.

Yay, I'm being put at risk because UI designers (hah, bet the call themselves "UX Engineers" or worse) decided that a cluttered display, with decreased contrast, is so damn clever and important that it went into the OS.

[1] I mean, come on, it was tacky and useless when Windows Aero did it.

[GNU Enjoyer]

Turns out that if proprietary malware is run on a device

It can deduce what is displayed on the screen.

Who would have thought?

Clearly the solution to this problem is to install more proprietary software.