Vulnerability in Android that allows you to bypass the lock screen

A vulnerability has been identified in the Android platform (CVE-2022-20465) that allows disabling the screen lock by swapping the SIM card and entering the PUK code. The ability to disable the lock has been demonstrated on Google Pixel devices, but since the fix affects the main Android codebase, it is likely that the problem also affects firmware from other manufacturers. The issue was addressed in the November Android Security Patch Roll. The researcher who drew attention to the problem received a $70 reward from Google.

The issue is caused by incorrect unlock processing after a PUK (Personal Unblocking Key) code is entered, which is used to reactivate a SIM card that has been locked after multiple incorrect PIN entries. To disable the screen lock, all you need to do is insert your SIM card into your phone, which has PIN-based protection. After changing the PIN-protected SIM card, a PIN code request is first displayed on the screen. If the PIN code is entered incorrectly three times, the SIM card will be blocked, after which you will be given the opportunity to enter the PUK code to unlock it. It turned out that the correct entry of the PUK code not only unlocks the SIM card, but leads to a transition to the main interface bypassing the screen saver, without confirming access using the main password or pattern.

The vulnerability is caused by an error in the logic for checking PUK codes in the KeyguardSimPukViewController handler, which is responsible for displaying an additional authentication screen. Android uses several types of authentication screens (for PIN, PUK, password, pattern, biometric authentication) and these screens are invoked sequentially when multiple verifications are required, such as when both PIN and pattern are required.

If the PIN code is entered correctly, the second stage of verification is triggered, requiring the entry of the main unlock code, but when entering the PUK code, this stage is skipped and access is granted without asking for the main password or pattern. The next unblocking stage is discarded because when KeyguardSecurityContainerController#dismiss() is called, the expected and passed check method is not compared, i.e. the handler considers that the change of the verification method did not occur and the completion of the PUK code verification indicates a successful confirmation of the authority.

The vulnerability was discovered by accident - the user's phone ran out of battery, and after charging and turning it on, he made a mistake when entering the PIN code several times, after which he unlocked the PUK code and was surprised that the system did not request the main password used to decrypt the data, after which it hung with the message "Pixel is starting ...". The user turned out to be meticulous, decided to figure out what was going on and began experimenting with entering PIN and PUK codes in various ways, until he accidentally forgot to restart the device after changing the SIM card and got access to the environment instead of freezing.

Of particular interest is Google's response to the vulnerability report. Information about the problem was sent in June, but until September, the researcher could not get a clear answer. He considered that this behavior was due to the fact that he was not the first to report this error. Suspicions that something was going wrong arose in September when the problem remained uncorrected after a firmware update was released 90 days later, after the stated non-disclosure period had already expired.

Since all attempts to find out the status of the submitted problem report only led to automated and template unsubscribes, the researcher tried to personally contact Google employees to clarify the situation with the preparation of a fix, and even demonstrated a vulnerability in Google's London office. Only after that, the work to eliminate the vulnerability moved forward. During the analysis, it turned out that someone had already reported the problem before, but Google decided to make an exception and pay a reward for re-reporting the problem, since it was only thanks to the perseverance of its author that the problem was noticed.

Source: opennet.ru

Add a comment