Full Report
The author completely forgot their SIM pin on their phone. Since they were tired, they forgot the PIN 3 times and had to use the PUK code to unlock the device in order to get it to work again. They used this, set a new PIN code and all was good. Or was it? Upon the fresh boot the fingerprint icon was showing instead of a lock screen PIN or a password to decrypt the device. Is this real life? After coming across this anomaly as a hacker, they decided they had to replicate this issue. They played around with variations of what they had done. Turn off the phone, change SIM... until they found something that was consistent. The attack goes as follows: Force the phone to require a SIM card PIN code. Replace the SIM card in the phone toin order to know the SIM code. Use phone SIM code incorrectly 3 times. Enter in the SIM code. Lock screen is bypassed! The bug had already been reported to Google but couldn't be reproduced. After showing this to a Google engineer at a bug bounty conference, they decided to reward this engineer with the bounty since the issue was now reproducible. How does a bug come across like this? Surprisingly, this was a very complicated fix. When a security screen (password entry screen, SIM PIN, etc.) is rendered, it is essentially put onto a stack of devices on top of each other. When a security screen was done, it would call the dismiss() function to get rid of the current screen. But, this was vulnerable to a race condition. Something in the background was changing current screen state to the original, while the dismiss() call would remove the new current screen! By entering in only the one PIN code for the SIM, it would sometimes bypass the lock screen PIN as well. A pretty crazy bug! In order to fix this, the calls to dismiss() are now targeted at a particular screen and not generic. For instance, you would dismiss the SIM PUK screen instead of the screen in general. Overall, great write up with a fun story to tell! To me, takeaways are be observant and look into weird things that happen. Second, be persistent, as you may get the bounty if you provide more service than the other hacker.
Analysis Summary
# Vulnerability: Android Lock Screen Bypass via SIM PUK Reset Race Condition
## CVE Details
- CVE ID: CVE-2022-20465
- CVSS Score: N/A (Severity based on description: Critical/High severity due to full lock screen bypass)
- CWE: CWE-362 (Race Condition)
## Affected Systems
- Products: Google Pixel devices (confirmed on Pixel 6 and Pixel 5), potentially other Android vendors.
- Versions: Prior to the November 5, 2022 security update.
- Configurations: Devices requiring SIM PIN authentication, where the PUK sequence is performed after incorrect PIN entries.
## Vulnerability Description
The vulnerability existed within the Android security screen stack management, specifically concerning the handling of security screen dismissal during a SIM PIN reset sequence (using the PUK code).
The flaw was a **race condition** in the `dismiss()` function used by security screens (like the SIM PUK entry screen). When the system entered the PUK code and successfully set a new SIM PIN, the relevant component called `dismiss()` to remove the PUK entry screen. However, sometimes a background process monitoring the SIM state would update the *currently active* security screen state to the default lock screen (e.g., fingerprint or passcode screen) *before* the PUK dismissal call executed.
Because the original `dismiss()` call was generic, when it finally executed, it removed the *newly active* security screen (the intended device lock screen), effectively bypassing all subsequent authentication requirements and granting immediate access to the home screen.
## Exploitation
- Status: PoC available (The researcher demonstrated the exploit consistently).
- Complexity: Low (Requires physical access and a pre-configured, incorrect SIM PIN locked card whose PUK code is known).
- Attack Vector: Physical
The attack sequence is:
1. Obtain physical access to the locked device.
2. Insert a malicious SIM card that is PIN-locked.
3. Incorrectly enter the SIM PIN 3 times, triggering the PUK request.
4. Enter the correct PUK code and set a new (or temporary) SIM PIN.
5. The race condition executes, causing the lock screen to be dismissed without requiring the device's primary PIN/password/biometric authentication.
## Impact
- Confidentiality: High (Full unauthorized access to all user data on the device).
- Integrity: High (Ability to modify device settings and data).
- Availability: Low (The device remains functional).
## Remediation
### Patches
- Fix implemented in the **November 5, 2022, Android Security Update**.
- The fix involved refactoring the `dismiss()` function to require explicit targeting of the security screen to be removed (e.g., `dismiss(SecurityMode.SimPuk)`), preventing unintended dismissal of other screens due to race conditions.
### Workarounds
- No specific vendor-provided workarounds are detailed, but generally, ensuring the device is not left unlocked after a PUK procedure could prevent exploitation in theory. However, the core issue was code-level and required the patch.
## Detection
- Detection methods are focused on monitoring the system logs for unusual sequences of security state changes, rapid transitions between SIM PIN/PUK entry and Keyguard screens, or unexpected termination of keyguard processes.
- Indicators of Compromise would likely be subtle, involving the device immediately booting past the mandatory first reboot screen check into the home screen after a SIM unlock procedure.
## References
- Vendor Advisory: Google November 2022 Security Bulletin (Details related to CVE-2022-20465)
- Researcher Write-up: bugs.xdavidhu.me (defanged: bugs DOT xdavidhu DOT me)