{"id":105525,"date":"2022-11-11T21:36:51","date_gmt":"2022-11-11T19:36:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-android-pozvolyayushhaya-obojti-blokirovku-ekrana"},"modified":"2022-11-11T21:36:51","modified_gmt":"2022-11-11T19:36:51","slug":"uyazvimost-v-android-pozvolyayushhaya-obojti-blokirovku-ekrana","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/uyazvimost-v-android-pozvolyayushhaya-obojti-blokirovku-ekrana","title":{"rendered":"A vulnerability in Android allows bypassing of the screen lock.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
A vulnerability (CVE-2022-20465) has been identified in the Android platform that allows the screen lock to be bypassed by rearranging 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 core Android codebase, it's likely that the issue also pertains to firmware from other manufacturers. The problem has been addressed in the November security patch for Android. The researcher who highlighted the issue received a reward of $70,000 from Google. <\/p>\n
The issue is caused by improper handling of the unlock process after the PUK (Personal Unblocking Key) code is entered, which is used to reactivate a SIM card that has been blocked after multiple incorrect PIN entries. To disable the screen lock, simply inserting your SIM card, which has a PIN-based protection, into the phone is sufficient. Upon changing to the PIN-protected SIM card, the screen prompts for the PIN code first. If the PIN code is entered incorrectly three times, the SIM card will be blocked, after which an option to enter the PUK code will be provided for unlocking. It turns out that entering the correct PUK code not only unlocks the SIM card but also leads to bypassing the lock screen interface without confirming access through the main password or pattern.
\r\n \r\n
<\/div>\r\n <\/div><\/center> <\/p>\n
The vulnerability is caused by an error in the logic of PUK code verification in the KeyguardSimPukViewController, which is responsible for displaying the additional authentication screen. Android employs multiple types of authentication screens (for PIN, PUK, password, pattern, biometric authentication), and these screens are called sequentially when multiple checks are required, such as when both a PIN and a pattern are needed. <\/p>\n
When the PIN code is entered correctly, the second stage of verification is triggered, requiring the entry of the main unlock code. However, when the PUK code is entered, this stage is skipped, and access is granted without requesting the main password or graphical key. The next unlocking step is bypassed because the call to KeyguardSecurityContainerController#dismiss() does not compare the expected and passed verification methods, meaning the handler assumes that the verification method has not changed, and the completion of the PUK code verification indicates successful authorization. <\/p>\n
The vulnerability was discovered accidentally \u2014 the user's phone ran out of battery, and after charging and turning it back on, they mistakenly entered the PIN code several times. They then unlocked it using the PUK code and were surprised that the system did not prompt for the main password used to decrypt data, after which it froze with the message 'Pixel is starting...'. The user, being meticulous, decided to investigate the issue and began experimenting with entering the PIN and PUK codes in various ways, until they accidentally forgot to restart the device after changing the SIM card and gained access to the environment instead of experiencing a freeze. <\/p>\n
Google's reaction to the vulnerability report is particularly interesting. The information about the issue was submitted in June, but by September, the researcher still had not received a coherent response. He believed that this behavior could be explained by the fact that he was not the first to report this error. Concerns that something was wrong arose in September when the issue remained unresolved after installing a firmware update released 90 days later when the stated disclosure period had already expired. <\/p>\n
As all attempts to inquire about the status of the reported issue resulted only in automated and template responses, the researcher attempted to contact Google employees directly to clarify the situation regarding the preparation of a fix and even demonstrated the vulnerability at Google's London office. Only after this did the work on resolving the vulnerability begin to move forward. During the review, it turned out that someone had reported the issue earlier, but Google decided to make an exception and pay a reward for the resubmission of the problem, as it was only thanks to the author's persistence that attention was drawn to the issue. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Play](\"https:\/\/img.youtube.com\/vi\/dSgSnYPgzT0\/hqdefault.jpg\")
\r\n