Malicious app required to make "Pixnapping" attack work requires no permissions:
Android devices are vulnerable to a new attack that can covertly steal two-factor authentication codes, location timelines, and other private data in less than 30 seconds.
The new attack, named Pixnapping by the team of academic researchers who devised it, requires a victim to first install a malicious app on an Android phone or tablet. The app, which requires no system permissions, can then effectively read data that any other installed app displays on the screen. Pixnapping has been demonstrated on Google Pixel phones and the Samsung Galaxy S25 phone and likely could be modified to work on other models with additional work. Google released mitigations last month, but the researchers said a modified version of the attack works even when the update is installed.
Pixnapping attacks begin with the malicious app invoking Android programming interfaces that cause the authenticator or other targeted apps to send sensitive information to the device screen. The malicious app then runs graphical operations on individual pixels of interest to the attacker. Pixnapping then exploits a side channel that allows the malicious app to map the pixels at those coordinates to letters, numbers, or shapes.
"Anything that is visible when the target app is opened can be stolen by the malicious app using Pixnapping," the researchers wrote on an informational website. "Chat messages, 2FA codes, email messages, etc. are all vulnerable since they are visible. If an app has secret information that is not visible (e.g., it has a secret key that is stored but never shown on the screen), that information cannot be stolen by Pixnapping."
The new attack class is reminiscent of GPU.zip, a 2023 attack that allowed malicious websites to read the usernames, passwords, and other sensitive visual data displayed by other websites. It worked by exploiting side channels found in GPUs from all major suppliers. The vulnerabilities that GPU.zip exploited have never been fixed. Instead, the attack was blocked in browsers by limiting their ability to open iframes, an HTML element that allows one website (in the case of GPU.zip, a malicious one) to embed the contents of a site from a different domain.
Pixnapping targets the same side channel as GPU.zip, specifically the precise amount of time it takes for a given frame to be rendered on the screen.
"This allows a malicious app to steal sensitive information displayed by other apps or arbitrary websites, pixel by pixel," Alan Linghao Wang, lead author of the research paper "Pixnapping: Bringing Pixel Stealing out of the Stone Age," explained in an interview. "Conceptually, it is as if the malicious app was taking a screenshot of screen contents it should not have access to. Our end-to-end attacks simply measure the rendering time per frame of the graphical operations to determine whether the pixel was white or nonwhite."
[...] In an online interview, paper coauthor Ricardo Paccagnella described the attack in more detail:
Step 1: The malicious app invokes a target app to cause some sensitive visual content to be rendered.
Step 2: The malicious app uses Android APIs to "draw over" that visual content and cause a side channel (in our case, GPU.zip) to leak as a function of the color of individual pixels rendered in Step 1 (e.g., activate only if the pixel color is c).
Step 3: The malicious app monitors the side effects of Step 2 to infer, e.g., if the color of those pixels was c or not, one pixel at a time.
Steps 2 and 3 can be implemented differently depending on the side channel that the attacker wants to exploit. In our instantiations on Google and Samsung phones, we exploited the GPU.zip side channel. When using GPU.zip, measuring the rendering time per frame was sufficient to determine if the color of each pixel is c or not. Future instantiations of the attack may use other side channels where controlling memory management and accessing fine-grained timers may be necessary (see Section 3.3 of the paper). Pixnapping would still work then: The attacker would just need to change how Steps 2 and 3 are implemented.
[...] In an email, a Google representative wrote, "We issued a patch for CVE-2025-48561 in the September Android security bulletin, which partially mitigates this behavior. We are issuing an additional patch for this vulnerability in the December Android security bulletin. We have not seen any evidence of in-the-wild exploitation."
Pixnapping is useful research in that it demonstrates the limitations of Google's security and privacy assurances that one installed app can't access data belonging to another app. The challenges in implementing the attack to steal useful data in real-world scenarios, however, are likely to be significant. In an age when teenagers can steal secrets from Fortune 500 companies simply by asking nicely, the utility of more complicated and limited attacks is probably of less value.
(Score: 4, Interesting) by VLM on Wednesday October 22, @11:32AM (4 children)
In one step, yes. Its a two step, display the 2FA key or the passkey or whatever, then pixnap it.
Overall its not much of an invention to create a new word for "take a screenshot" although how this works is very technically interesting so I see their motivation in trying to give it a new name. But to the end user or anyone not trying to defend against this type of thing, its just "take a screenshot"
The article seems long winded to explain its basically the old variable time strcmp password breach. Lets say you allow A-Z in passwords and passwords are 100 characters long. Simplistically you think you have 26 ** 100 keys to crack. In the real world a simplistic string compare might take different amounts of time for matching or not. So you feed it A1234... B1234... C1234 etc then one of the 26 first letters takes a different amount of time from the other 25 that are not a match. Lets say you determine the first letter of the password is therefore B because all the other letter have different matching timing. Then you feed 26 more passwords BA1234... BB1234... BC1234... to figure out the "odd man out" in the second letter. So your actual number of keys to check is 26 * 100 not 26 ** 100 which is slightly larger (sarcasm intended). This "attack" is just reading a screenshot by repeatedly slapping a pop up on top of a "secret" window and doing the strcmp() thing but with pixels. Ta Da this paragraph pretty accurately summarized the multi page story. Now on to figuring out an automobile analogy.... "I can guess your VIN number as a game" and the instant I get one digit wrong you immediately yell out "no nope totally wrong" so I know every digit before the last one I spoke is correct, then on average it takes me 5 tries to guess each digit times the number of digits in your VIN (which are actually alphanumeric but whatever).
Its interesting. Not totally new, but an interesting application of a VERY old security problem. Ironically massively overcomplicating a system with thermal throttling and hard to predict caching and multiprocessing makes it a lot harder (but not impossible) to exploit a variable timing compare attack.
(Score: 2) by PiMuNu on Wednesday October 22, @02:22PM (3 children)
> massively overcomplicating a system
That's okay for a password/security system, but for the main graphics display on my device to be slowed in this way is hard to contemplate. Is there any defence that will not slow down all graphics display?
(Score: 2) by aafcac on Thursday October 23, @03:58AM (2 children)
I'd assume that it would just be authenticator apps and SMS, neither of which are sensitive the way that most other apps are. I just wonder how long until we start using physical decoder rings and cards the way that they used to to translate the numbers being shown. I think I might still have one from the social security administration or the treasury.
(Score: 2) by PiMuNu on Thursday October 23, @01:11PM (1 child)
I insist on using a physical dongle for my banking second factor as banking access represents my "most secret" secret, with life-changing impact if the secret is hacked. The dongle never leaves a secret location in my house.
My bank keeps trying to get me to use my phone (presumably it is cheaper for them), which I regard as way less secure for many reasons both software and wetware related.
(Score: 2) by aafcac on Thursday October 23, @06:17PM
It's not that expensive to allow people to use their own physical dongle. A significant chunk of the logins I have these days allow that, or an authenticator program that doesn't use SMS at all.
It's somewhat less than ideal when you consider that the phones capable of using such things have a bunch of extra stuff to spy more closely and that there are things that legitimately do benefit from being accessed away from home.And that you typically do want to have both a record of all the sites using a dongle as well as having a spare one in case the first fails for whatever reason.
(Score: 3, Insightful) by SomeGuy on Wednesday October 22, @12:09PM (1 child)
> Android devices are vulnerable to a new attack that can covertly steal...
I think you mean to say let others besides Google steal.
If anyone truly appreciated how many vectors of attack there are in a so-called "smart" phone, having a voice system call you and read you a code on a proper land-line suddenly seems infinitely more secure.
On a side note, a smell phone does NOT identify me, and it is NOT ok.
(Score: 2) by aafcac on Wednesday October 22, @02:03PM
I recently switched back to KaiOS for my phone and 2FA is the biggest annoyance other than that it's version of Google Maps doesn't automatically update to the next step as I progress. Which, isn't the biggest deal if I'm not driving. But not having an official equivalent of Authy or Google Authenticator can be a bit of a big deal as it means the only way of receiving that sort of stuff is either through it's email client or through SMS that generally is also available through VM.
Even with most of the notifications turned off, the android one was still depleting my attention.