Google patches Pixel phone zero-days after exploitation by “forensic companies”

Google has issued a security advisory to owners of its Android Pixel smartphones, warning that it has discovered someone has been targeting some devices to bypass their built-in security.

What makes the reported attacks particularly interesting is that traditional cybercriminals may not be behind them, but rather "forensic companies" exploiting two vulnerabilities to extract information and prevent remote wiping.

That's the opinion of researchers at GrapheneOS, who tweeted a thread about their findings on the vulnerabilities known as CVE-2024-29745 and CVE-2024-29748.

The team at GrapheneOS team is knowledgeable about security and privacy. GrapheneOS is an alternative Android-based operating system for Google Pixel devices that prioritizes privacy and security.

The thought is that forensic companies may use these zero-day vulnerabilities in the Pixel's standard OS to bypass security measures on confiscated phones. This could potentially be at the behest of law enforcement agencies to access data not accessible through traditional means.

Anyone trying to extract information from a confiscated locked smartphone would clearly want to prevent it from being remotely wiped by its owner.

PC Magazine reports that a Swedish forensics firm released a since-deleted video demonstrating how an Android app called "Wasted" (for remote device wiping) can be bypassed.

The GrapheneOS maintainers made a copy of the video and used it to convince Google to take the vulnerabilities seriously. They said it was "evidence of in-the-wild exploitation."

GrapheneOS researchers claim that Google's firmware fix for Pixel smartphones is currently only a "partial solution" to the flaw. This flaw can prevent a remote owner from wiping their device but hasn't shared much information, presumably to avoid further exploitation and attacks.

Google plans to roll out vulnerability patches for affected Pixel devices in the next few days.

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor and do not necessarily reflect those of Tripwire.