Android 'Pixnapping' Attack Can Capture App Data Like 2FA Codes (theregister.com) 17
An anonymous reader quotes a report from The Register: 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 Android application to access and leak information displayed in other Android apps or on websites. It can, for example, steal data displayed in apps like Google Maps, Signal, and Venmo, as well as from websites like Gmail (mail.google.com). It can even steal 2FA codes from Google Authenticator.
"First, the malicious app opens the target app (e.g., Google Authenticator), submitting its pixels for rendering," explained [Alan Wang, a PhD candidate at UC Berkeley]. "Second, the malicious app picks the coordinates of a target pixel whose color it wants to steal. Suppose for example it wants to steal a pixel that is part of the screen region where a 2FA character is known to be rendered by Google Authenticator, and that this pixel is either white (if nothing was rendered there) or non-white (if part of a 2FA digit was rendered there). Third, the malicious app causes some graphical operations whose rendering time is long if the target pixel is non-white and short if it is white. The malicious app does this by opening some malicious activities (i.e., windows) in front of the target app. Finally, the malicious app measures the rendering time per frame of the above graphical operations to determine whether the target pixel was white or non-white. These last few steps are repeated for as many pixels as needed to run OCR over the recovered pixels and guess the original content."
The researchers have demonstrated Pixnapping on five devices running Android versions 13 to 16 (up until build id BP3A.250905.014): Google Pixel 6, Google Pixel 7, Google Pixel 8, Google Pixel 9, and Samsung Galaxy S25. Android 16 is the latest operating system version. Other Android devices have not been tested, but the mechanism that allows the attack to work is typically available. A malicious Android app implementing Pixnapping would not require any special permissions in its manifest file, the authors say. The researchers detail the attack in a paper (PDF) titled "Pixnapping: Bringing Pixel Stealing out of the Stone Age."
"First, the malicious app opens the target app (e.g., Google Authenticator), submitting its pixels for rendering," explained [Alan Wang, a PhD candidate at UC Berkeley]. "Second, the malicious app picks the coordinates of a target pixel whose color it wants to steal. Suppose for example it wants to steal a pixel that is part of the screen region where a 2FA character is known to be rendered by Google Authenticator, and that this pixel is either white (if nothing was rendered there) or non-white (if part of a 2FA digit was rendered there). Third, the malicious app causes some graphical operations whose rendering time is long if the target pixel is non-white and short if it is white. The malicious app does this by opening some malicious activities (i.e., windows) in front of the target app. Finally, the malicious app measures the rendering time per frame of the above graphical operations to determine whether the target pixel was white or non-white. These last few steps are repeated for as many pixels as needed to run OCR over the recovered pixels and guess the original content."
The researchers have demonstrated Pixnapping on five devices running Android versions 13 to 16 (up until build id BP3A.250905.014): Google Pixel 6, Google Pixel 7, Google Pixel 8, Google Pixel 9, and Samsung Galaxy S25. Android 16 is the latest operating system version. Other Android devices have not been tested, but the mechanism that allows the attack to work is typically available. A malicious Android app implementing Pixnapping would not require any special permissions in its manifest file, the authors say. The researchers detail the attack in a paper (PDF) titled "Pixnapping: Bringing Pixel Stealing out of the Stone Age."
Rendering time? (Score:2)
"whose rendering time is long if the target pixel is non-white and short if it is white"
Huh? There's nothing special about white in the colour gamut, why would it be quicker to render?
Aside from that I don't quite follow how the attack works. Does it try and render pixels in its own window then these somehow slow down depending on the pixels beneath in a masked window? This is all done in the GPU surely, not software?
Re:Rendering time? (Score:5, Funny)
It's white privilege - all this is happening because Google dropped their DEI policies. Let's fight for all pixels to be processed as equals NOW!
Re: (Score:3)
FTA:
What Android APIs does Pixnapping exploit?
Pixnapping forces sensitive pixels into the rendering pipeline and overlays semi-transparent activities on top of those pixels via Android intents. To induce graphical operations on these pixels, our instantiations use Android’s window blur API. To measure rendering time, our instantiations use VSync callbacks. For a more detailed explanation, we refer to the paper.
Re: (Score:2)
I still don't see why white would quicker to render transparency, blur or otherwise.
Re: (Score:2)
They link to "GPU.zip" which apparently is another side-channel based on the GPU's compressions - https://www.hertzbleed.com/gpu... [hertzbleed.com]
So apparently by asking it to blur the background, they can time it. Then the "core" of the attack is this GPU.zip so really it sounds like this is more of a "look we found a new way to exploit this."
Re: (Score:2)
Indeed. This seems to be a very limited vulnerability. Even in optimal conditions, this isn't likely to be able to "steal 2FA from Google Authenticator" because as GPU.zip site itself plainly stated in their FAQ:
>I am a user. Should I be worried?
>Under most circumstances, probably not. Most sensitive websites already deny being embedded by cross-origin websites. As a result, they are not vulnerable to >the pixel stealing attack we mounted using GPU.zip. However, some websites remain vulnerable. For
Re: (Score:2)
My guess is a white pixel would in a blur scatter more light in the visual effect, therefore having to compute more of the adjacent pixels, whereas a black pixel has no light to scatter visually, therefore no computation is needed on the surrounding pixels.
Re: (Score:2)
While I'm not sure of the details, in the world of drawing things on a screen or preparing them for drawing on a screen there's a world of optimisations involved. In many cases the act of changing something or not changing something involve different execution times. Certainly this is how many low level graphic operations work, especially if they are updated in a group. Not updating something = skip. Updating something = performing matrix manipulation.
Now I'm sure this isn't exactly what we're talking about
Re: (Score:2)
I'm more interested in how any app would know how long it took an image of that size to render, regardless of whether that differs for white/black pixels (I can see that with, say, transparency options etc. you might be able to make white pixels take longer).
Surely that's a function that you just lob at the renderer and it does it when it feels like it, it doesn't have to be performed in-line (maybe in order, but not in-line).
The fix for the API would appear to be simple... do checks on the bounds, etc. as
Re: (Score:2)
This is exploit they used.
https://www.hertzbleed.com/gpu... [hertzbleed.com]
This is their link to pre-print of their paper talking about details.
https://www.hertzbleed.com/gpu... [hertzbleed.com]
Re:Rendering time? (Score:4, Informative)
From the paper, for the TLDR crowd:
Generally, a browser is willing to load visual content requested by one page, but belonging to another distrustingpage, at the same time in the form of iframes. As part of the same-origin policy (SOP), iframes guarantee that even if the framing page is malicious, it cannot inspect either the source code for the iframed page, or the final visual product of the iframe. Since a page may contain visual data that is considered secret, e.g., usernames, email content, etc., it is important that this safety property is upheld.
However, some web standards allow for the framing page to apply additional visual effects, e.g., CSS filters, to that content. These include dozens of different filters, from complex visual effects (3D lighting) to simple convolutions, many of which are borrowed from the SVG standard. Unfortunately, allowing a framing page to apply semi-arbitrary computation to secret visual content has proven to be fertile ground for side-channel attacks
Ah, there it is, this bullshit again: bankofamericaloanapplication.hax0r.me can load bankofamerica.com in an iframe and then fuck with the content of it. In this case, not actually *reading* it per se, but applying graphical transformations to it that make it look different (bad enough) and being able to measure how long those transformations take to execute (worse), thus making inferences about the content of the iframe.
And since many/most? apps on Android are just a wrapper around the System Webview, apparently it works there too.
But ain't it PRETTY?
Re: (Score:2)
Thanks for the TLDR. So presumably the iframe logic (the enclosing code being able to do some manipulations of what is displayed in the iframe) was extended to apps opening other apps. i.e. even if an app doesn't have the permission to draw over other apps, it can still do some visual effects that are allowed in iframes for apps that it opens. I would argue that this is a bad idea and not an intuitive definition of what "draw / not draw over other apps" means. So this should be changed so that no operat
Re: (Score:2)
with planar video modes like with EGA and VGA, you had to write to 4 planes to make a white pixel. An efficient fill routine on VGA could use latch register to write to 4 planes at once but for a single putpixel you generally didn't want to do the extra setup.
Of course, none of this has been relevant in computing for the last 30 years. I just like [over] sharing.
Draw Over Other Apps? (Score:2)
If I want an app to draw over other apps (e.g. accessibility apps) I need to grant that permission (AOSP distro). How do they bypass that?
So... (Score:2)
Suppose for example it wants to steal a pixel that is part of the screen region where a 2FA character is known to be rendered by Google Authenticator, and that this pixel is either white (if nothing was rendered there) or non-white (if part of a 2FA digit was rendered there)
If I enable dark mode, it will completely negate this attack vector!
Hahaha, I am too smart for you hackers! I am always one step ahead!