På plattformen Android Det er identifisert et sikkerhetsproblem (CVE-2022-20465) som gjør at skjermlåsen kan deaktiveres ved å bytte SIM-kort og taste inn PUK-koden. Muligheten til å deaktivere låsen har blitt demonstrert på Google Pixel-enheter, men siden løsningen påvirker kjernekodebasen, Android, er det sannsynlig at problemet også påvirker fastvare fra andre produsenter. Problemet ble løst i sikkerhetsoppdateringen for november for AndroidForskeren som brakte problemet frem i lyset mottok en belønning på 70 000 dollar fra Google.
Problemet skyldes feil opplåsing etter at PUK-koden (Personal Unblocking Key) er tastet inn. Denne koden brukes til å gjenoppta bruken av SIM-kortet som er blokkert etter flere feilaktige PIN-kodeinntastinger. For å deaktivere skjermlåsen, setter du ganske enkelt inn SIM-kortet i telefonen, som har PIN-kodebeskyttelse angitt. Etter at du har byttet SIM-kort som er beskyttet av en PIN-kode, vises først en forespørsel om PIN-kode på skjermen. Hvis PIN-koden tastes inn feil tre ganger, låses SIM-kortet, hvoretter du får muligheten til å taste inn PUK-koden for å låse det opp. Det viste seg at riktig PUK-inntasting ikke bare låser opp SIM-kortet, men også fører til en overgang til hovedgrensesnittet, uten å bekrefte tilgang ved hjelp av hovedpassordet eller grafikknøkkelen.
Sårbarheten skyldes en feil i PUK-kodeverifiseringslogikken i KeyguardSimPukViewController-håndtereren, som er ansvarlig for å vise et ekstra autentiseringsskjermbilde. Android Flere typer autentiseringsskjermbilder brukes (for PIN, PUK, passord, mønster, biometrisk autentisering), og disse skjermbildene kalles opp sekvensielt når flere kontroller må utføres, for eksempel når en PIN og et mønster er påkrevd.
Hvis PIN-koden tastes inn riktig, utløses det andre verifiseringstrinnet, som krever at hovedopplåsningskoden tastes inn. Men hvis PUK-koden tastes inn, hoppes et slikt trinn over, og tilgang gis uten å spørre om hovedpassordet eller den grafiske nøkkelen. Det neste opplåsingstrinnet forkastes fordi når KeyguardSecurityContainerController#dismiss() kalles, foretas ingen sammenligning mellom forventede og godkjente verifiseringsmetoder. Dvs. behandleren anser at det ikke var noen endring i verifiseringsmetoden, og fullføringen av PUK-kodeverifiseringen indikerer vellykket bekreftelse av autorisasjon.
Sårbarheten ble oppdaget ved et uhell – brukerens telefon gikk tom for batteri, og etter å ha ladet og slått den på, gjorde han flere feil da han tastet inn PIN-koden, hvoretter han fjernet PUK-kodelåsen og ble overrasket over at systemet ikke ba om hovedpassordet som ble brukt til å dekryptere dataene, hvoretter det frøs med meldingen «Pixel starter...». Brukeren viste seg å være nøyaktig, 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 i stedet for å fryse, fikk han tilgang til miljøet.
Av spesiell interesse er Googles svar på sårbarhetsrapporten. Problemet ble rapportert i juni, men forskeren hadde ikke mottatt et klart svar før i september. Han mente at denne oppførselen skyldtes at han ikke var den første som rapporterte feilen. Mistanke om at noe var galt oppsto i september, da problemet forble uløst etter at man installerte en fastvareoppdatering som ble utgitt 90 dager etter at den oppgitte taushetserklæringsperioden var utløpt.
Siden alle forsøk på å finne ut statusen til den sendte problemrapporten kun resulterte i automatiserte svar og malsvar, prøvde 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 med å 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 en ny rapport om problemet, siden problemet bare ble oppdaget takket være forfatterens utholdenhet.
Kilde: opennet.ru
