En sårbarhet har identifierats i Android-plattformen (CVE-2022-20465) som gör det möjligt att inaktivera skärmlåset genom att byta SIM-kort och ange PUK-koden. Möjligheten att inaktivera låset har demonstrerats på Google Pixel-enheter, men eftersom fixen påverkar den huvudsakliga Android-kodbasen är det troligt att problemet även påverkar firmware från andra tillverkare. Problemet togs upp i november Android Security Patch Roll. Forskaren som uppmärksammade problemet fick en belöning på 70 XNUMX dollar från Google.
Problemet orsakas av felaktig upplåsningsbehandling efter att en PUK-kod (Personal Unblocking Key) har angetts, som används för att återaktivera ett SIM-kort som har låsts efter flera felaktiga PIN-inmatningar. För att inaktivera skärmlåset behöver du bara sätta in ditt SIM-kort i telefonen, som har PIN-baserat skydd. Efter byte av det PIN-skyddade SIM-kortet visas först en PIN-kodsbegäran på skärmen. Om PIN-koden skrivs in felaktigt tre gånger spärras SIM-kortet, varefter du får möjlighet att ange PUK-koden för att låsa upp det. Det visade sig att korrekt inmatning av PUK-koden inte bara låser upp SIM-kortet, utan leder till en övergång till huvudgränssnittet förbi skärmsläckaren, utan att bekräfta åtkomst med hjälp av huvudlösenordet eller mönstret.
Sårbarheten orsakas av ett fel i logiken för kontroll av PUK-koder i KeyguardSimPukViewController-hanteraren, som ansvarar för att visa ytterligare en autentiseringsskärm. Android använder flera typer av autentiseringsskärmar (för PIN, PUK, lösenord, mönster, biometrisk autentisering) och dessa skärmar anropas sekventiellt när flera verifieringar krävs, till exempel när både PIN och mönster krävs.
Om PIN-koden skrivs in korrekt utlöses det andra verifieringssteget, vilket kräver inmatning av huvudupplåsningskoden, men när PUK-koden skrivs hoppas detta steg över och åtkomst beviljas utan att fråga efter huvudlösenordet eller mönstret. Nästa avblockeringssteg kasseras eftersom när KeyguardSecurityContainerController#dismiss() anropas, jämförs inte den förväntade och godkända kontrollmetoden, dvs. hanteraren anser att ändringen av verifieringsmetoden inte inträffade och slutförandet av PUK-kodverifieringen indikerar en framgångsrik bekräftelse av myndigheten.
Sårbarheten upptäcktes av misstag - användarens telefon tog slut på batteri, och efter att ha laddat och slagit på den gjorde han ett misstag när han angav PIN-koden flera gånger, varefter han låste upp PUK-koden och blev förvånad över att systemet inte gjorde det. begär huvudlösenordet som används för att dekryptera data, varefter det hängde med meddelandet "Pixel startar ...". Användaren visade sig vara noggrann, bestämde sig för att ta reda på vad som pågick och började experimentera med att ange PIN- och PUK-koder på olika sätt, tills han av misstag glömde att starta om enheten efter att ha bytt SIM-kort och fick tillgång till miljön istället för frysning.
Av särskilt intresse är Googles svar på sårbarhetsrapporten. Information om problemet skickades i juni, men fram till september kunde forskaren inte få något tydligt svar. Han trodde att detta beteende berodde på att han inte var den första som rapporterade detta fel. Misstankar om att något var fel uppstod i september när problemet förblev okorrigerat efter att en firmwareuppdatering släppts 90 dagar senare, efter att den angivna sekretessperioden redan hade löpt ut.
Eftersom alla försök att ta reda på statusen för den inskickade problemrapporten endast ledde till automatiserade och mallavregistreringar, försökte forskaren personligen kontakta Google-anställda för att klargöra situationen med förberedelserna av en fix, och visade till och med en sårbarhet i Googles kontor i London. Först efter det gick arbetet med att eliminera sårbarheten framåt. Under analysen visade det sig att någon redan hade rapporterat problemet tidigare, men Google bestämde sig för att göra ett undantag och betala en belöning för att återrapportera problemet, eftersom det bara var tack vare författarens uthållighet som problemet uppmärksammades .
Källa: opennet.ru