Android lock screen bypass is a nightmare, as soon as you hear it, you know something disasterous did happen. A security researcher based in Hungary, David Schutz, discovered a lock screen bypass in Google Pixel 6 “accidentally” which lead to him being rewarded with $70,000 for this vulnerability that took months to fix.
David has been participating in Google’s Vulnerability Reward Program previously as well, he did discover a SSRF vulnerability on one of the Google Cloud’s API before. This time, he discovered a way to unlock his Google Pixel by accident when he ran into a problem.
The lock screen bypass just required a physical access to the Google Pixel device in order to bypass all of the lock screen protections such as Fingerprint lock, PIN etc.
The “Accident” Leading to $70,000 Android Lock Screen Bypass
David had to travel for complete 24 hours and because of that, his phone was about to die as the battery was drained. He was sending text messages and in between, the phone died. He followed the similar steps as any one of us would, he rushed towards the phone charger!
As soon as he turned his phone on, it asked for the Sim’s PIN code in order to start up, which he couldn’t remember at that time. Entering the Sim’s PIN code has three attempts as rate-limiting, after the user enters the PIN code incorrectly for three times, they are required to enter their PUK code.
This happened with him as well, he then rushed towards finding his PUK code. After entering it, he could reset his Sim’s PIN code and so he did. The phone booted normally afterwards but one thing caught his attention. When the phone booted, it was a normal boot but the lock screen was accepting his fingerprint as an unlocking method which is weird. The devices usually require the set PIN code for at-least once in order to decrypt the device. However, the fingerprint lock unlocked the phone normally, even though this device’s behavior was unusual.
“Accident” to Attack (CVE-2022-20465)
The very next day, the inquisitive side of David made him reproduce the issue again to see why was his Google Pixel 6 behaving this unusual. He repeated the procedure, rebooting his device from a locked state, entering incorrect Sim’s PIN code for three times, resetting the PIN code by entering the PUK code but when the phone booted up it usually got stuck at “Pixel is starting…” after authenticating him through the fingerprint lock.
However, for once he forgot to reboot his device. Instead, he hot-swapped the sim-tray when it was in the locked state and repeated the rest of the procedure. Entering incorrect PIN code for the sim three times, entering the PUK code and resetting the PIN code then. However, this time, the phone took him to his phone’s home screen. It didn’t even wait for a fingerprint lock or any other protection method to be authenticated but just unlocked itself!
Interestingly, he repeated these steps for a lot of times to verify if the issue really existed and the phone did unlock itself every time he did.
Moreover, he grabbed his previous Google Pixel 5 to try if it worked on that model and it did! Google Pixel 5 was unlocked using the same procedure and the lock screen was bypassed. This was when he realized he discovered an Android lock bypass that is reproducible.
For the exploitability of this vulnerability that was just discovered. The attacker in this scenario just needed the physical access to the device because the attacker can hot-swap the sim tray with his own SIM card for which he know the PUK code, easily resetting the PIN code and unlocking the device.
Getting in touch with Google
David immediately reported the vulnerability to Google and interestingly, Google filed an internal bug within the 37 minutes of David’s report.
However, the responses afterwards were delayed that did put him into doubting himself and drove him crazy because through all of it, he had to keep all of this to himself until the bug was fixed. He noticed from the Google’s reward table stating that any lock screen bypass that affected multiple or all Google Pixel phones could get him the maximum bounty of $100,000 which excited him even more.
RELATED: Is Multifactor Authentication becoming less effective?
Google’s Response towards the Lock Screen Bypass
After waiting for 31 days after reporting the bug, David woke up to an automated email that every security researcher prays to avoid.
“The Android Security Team believes that this is a duplicate of an issue previously reported by another external researcher.”
His report was marked as duplicate, which means someone already had let Google know about it therefore no reward for the late comers. The dream of $100,000 that he had for the whole month went to the reality of $0.
However after two months, he couldn’t see any update towards the bug fix so I contacted the team again and received a response mentioning that they’re still working on the fix.
Google was not interested?
Three months after the report, he was in London to attend Google’s bug hunter event. While staying in the hotel, he noticed his phone received an update which made him think that it must have been about fixing the lock screen bypass that he couldn’t stop thinking about. However, he tried reproducing it and his phone did unlock itself once again!
He reached out to few of the Google’s employees in the event, gave them a demo of how the vulnerability was reproduced and ended up giving a disclosure deadline of October but Google responded confirming that the fix was planned to roll out in November.
Duplicate Report Gets Rewarded
Two weeks after David had given his disclosure deadline, he received an usual email from Google’s team. They explained to him that his report was a duplicate which means someone else had reported the similar issue. However, it was his report that made them work on this specific issue and therefore, offered him a reward of $70,000!
He mentions that even before the reward, he had decided to wait for the fix before disclosing the vulnerability.
Behind the scenes: What caused the Android Lock Screen Bypass
As Android is open-source, the code commit that fixed this vulnerability has been publicly available. The bigger surprise was that the fix included of making fixes to dozens of files instead of a one-liner fix that David himself thought it would be.
Breaking it down, the issues were related to the “security screens” in Android. Examples for the security screens could be the fingerprint scanning screen, the PIN code entering screen, PUK entry screen and so on. Interestingly, these screens can be stacked on top of each other.
This vulnerability was due to the race-conditions. As soon as the PUK code was validated, a “.dismiss()” function is called to exit from the current security screen and moves on to the next security screen that is stacked next to it.
In this case, some other component of the system was monitoring the state of the SIM in the background. Apparently, when it did detect a change in SIM card’s state, it altered the current security screen.
For this scenario, it was observed that before the “.dismiss()” function for the PUK code security screen was called, the changing state of the SIM card did set the fingerprint security screen as the active screen and as soon as it did this, the “.dismiss()” function that was originally called for the PUK code security screen is now called for the fingerprint security screen. This function calls exits from the fingerprint security screen and unlocks the device.
The fix now requires an additional parameter to this function which includes which security screen to exit so that only the security screen of a specific type it is called for is dismissed.
We wish David luck with his future research, may he run towards more such accidents!
Have anything to add? Share it in comments or contact us.
