En sårbarhet er identifisert i Android-plattformen (CVE-2022-20465), som lar deg deaktivere skjermlåsen ved å omorganisere SIM-kortet og taste inn PUK-koden. Muligheten til å deaktivere låsen har blitt demonstrert på Google Pixel-enheter, men siden løsningen påvirker Android-hovedkodebasen, er det sannsynlig at problemet påvirker fastvare fra andre produsenter. Problemet er løst i november lanseringen av Android-sikkerhetsoppdateringen. Forskeren som gjorde oppmerksom på problemet fikk en belønning på 70 tusen dollar fra Google.
Problemet er forårsaket av feil opplåsingsbehandling etter å ha tastet inn PUK-koden (Personal Unblocking Key), som brukes til å gjenoppta driften av et SIM-kort som har blitt blokkert etter gjentatte ganger å taste inn feil PIN-kode. For å deaktivere skjermlåsen, installer bare SIM-kortet i telefonen, som har PIN-kodebeskyttelse. Etter å ha byttet et SIM-kort beskyttet av en PIN-kode, vises først en PIN-kodeforespørsel på skjermen. Taster du feil PIN-kode tre ganger, vil SIM-kortet bli sperret, hvoretter du får mulighet til å taste inn PUK-koden for å låse det opp. Det viste seg at riktig inntasting av PUK-koden ikke bare låser opp SIM-kortet, men fører til en overgang til hovedgrensesnittet, omgå skjermspareren, uten å bekrefte tilgang ved å bruke hovedpassordet eller mønsteret.
Sårbarheten er forårsaket av en feil i logikken for kontroll av PUK-koder i KeyguardSimPukViewController-behandleren, som er ansvarlig for å vise tilleggsautentiseringsskjermen. Android bruker flere typer autentiseringsskjermer (for PIN, PUK, passord, mønster, biometrisk autentisering) og disse skjermene kalles sekvensielt når flere kontroller må utføres, for eksempel når en PIN-kode og et mønster kreves.
Hvis du taster inn PIN-koden riktig, utløses det andre stadiet av bekreftelse, som krever at du oppgir hovedopplåsingskoden, men når du taster inn PUK-koden, hoppes dette trinnet over og tilgang gis uten å spørre om hovedpassordet eller mønsternøkkelen . Det neste opplåsingstrinnet forkastes fordi når du ringer KeyguardSecurityContainerController#dismiss() er det ingen sammenligning mellom de forventede og beståtte verifiseringsmetodene, dvs. prosessoren mener at verifiseringsmetoden ikke har endret seg og fullføringen av PUK-kodeverifiseringen indikerer en vellykket bekreftelse av autoritet.
Sårbarheten ble oppdaget ved et uhell - brukerens telefon var død og etter å ha ladet og slått den på gjorde han en feil flere ganger da han tastet inn PIN-koden, hvoretter han låste den opp med PUK-koden og ble overrasket over at systemet ikke spurte for hovedpassordet som brukes til å dekryptere dataene, hvoretter det frøs med meldingen "Pixel starter...". Brukeren viste seg å være nøye, bestemte seg for å finne ut hva som foregikk og begynte å eksperimentere med å taste inn PIN- og PUK-koder på forskjellige måter, helt til han ved et uhell glemte å starte enheten på nytt etter å ha byttet SIM-kort og fikk tilgang til miljøet i stedet for fryser.
Av spesiell interesse er Googles reaksjon på kunngjøringen om sårbarhet. Informasjon om problemet ble sendt i juni, men fram til september klarte ikke forskeren å få et klart svar. Han mente at denne oppførselen ble forklart med at han ikke var den første som rapporterte denne feilen. Mistanker om at noe gikk galt oppsto i september, da problemet forble ukorrigert etter installasjon av en fastvareoppdatering utgitt 90 dager senere, da den oppgitte taushetserklæringen allerede var utløpt.
Siden alle forsøk på å finne ut statusen til den sendte meldingen om problemet bare førte til automatiserte svar og malsvar, forsøkte forskeren å kontakte Google-ansatte personlig for å avklare situasjonen med utarbeidelse av en løsning og demonstrerte til og med sårbarheten på Googles kontor i London. . Først etter dette gikk arbeidet for å eliminere sårbarheten videre. Under analysen viste det seg at noen allerede hadde rapportert problemet tidligere, men Google bestemte seg for å gjøre et unntak og betale en belønning for å rapportere problemet igjen, siden det kun var takket være utholdenheten til forfatteren at problemet ble lagt merke til.
Kilde: opennet.ru