Farlig SIM-bytte låseskjermomgåelse – oppdater Android nå!

En bug dusørjeger kalt David Schütz har nettopp publisert en detaljert rapport beskriver hvordan han krysset sverd med Google i flere måneder over det han anså som et farlig Android-sikkerhetshull.

I følge Schütz snublet han over en total Android-låseskjerm-bypass-feil helt ved et uhell i juni 2022, under virkelige forhold som lett kunne ha skjedd hvem som helst.

Med andre ord, det var rimelig å anta at andre mennesker kunne finne ut om feilen uten bevisst å lete etter feil, noe som gjør oppdagelsen og offentlig avsløring (eller privat misbruk) som et nulldagers hull mye mer sannsynlig enn vanlig.

Dessverre ble det ikke lappet før i november 2022, og det er grunnen til at han først har avslørt det nå.

Et serenditiøst batteribrudd

Enkelt sagt fant han feilen fordi han glemte å slå av eller lade telefonen før han la ut på en lengre reise, og lot enheten gå tom for juice ubemerket mens han var på veien.

I følge Schütz skyndte han seg å sende noen meldinger etter å ha kommet hjem (vi tipper han hadde vært på et fly) med den lille mengden strøm som fortsatt var igjen i batteriet...

…da telefonen døde.

Vi har alle vært der, letet etter en lader eller en reservebatteripakke for å få telefonen omstartet for å fortelle folk at vi har kommet trygt frem, venter på bagasjehenting, har nådd togstasjonen, forventer å komme hjem om 45 minutter, kunne stoppet i butikkene hvis noen akutt trenger noe, eller hva vi nå har å si.

Og vi har alle slitt med passord og PIN-koder når vi har det travelt, spesielt hvis det er koder som vi sjelden bruker og aldri utviklet "muskelminne" for å skrive inn.

I Schützs tilfelle var det den ydmyke PIN-koden på SIM-kortet hans som overrasket ham, og fordi SIM-PIN-er kan være så korte som fire sifre, er de beskyttet av en maskinvaresperre som begrenser deg til tre gjetninger på det meste. (Vi har vært der, gjort det, låst oss ute.)

Etter det må du skrive inn en 10-sifret "master PIN" kjent som PUK, en forkortelse for personlig opphevingsnøkkel, som vanligvis er trykt inne i emballasjen som SIM-kortet selges i, noe som gjør det stort sett manipulasjonssikkert.

Og for å beskytte mot PUK-gjettingangrep, friterer SIM-kortet seg automatisk etter 10 feil forsøk, og må byttes ut, noe som typisk betyr å fronte opp til en mobiltelefonbutikk med identifikasjon.

Hva gjorde jeg med den emballasjen?

Heldigvis, fordi han ikke ville ha funnet feilen uten den, fant Schütz den originale SIM-emballasjen oppbevart et sted i et skap, skrapte av den beskyttende stripen som skjuler PUK-en, og skrev den inn.

På dette tidspunktet, gitt at han var i ferd med å starte opp telefonen etter at den gikk tom for strøm, burde han ha sett telefonens låseskjerm som krever at han skriver inn telefonens opplåsningskode ...

...men i stedet innså han at han var det på feil type låseskjerm, fordi det ga ham en sjanse til å låse opp enheten med kun fingeravtrykket hans.

Det er bare ment å skje hvis telefonen låses mens den er i vanlig bruk, og ikke skal skje etter en slått av og omstart, når en fullstendig passordkodereautentisering (eller en av disse sveipe-for-ålåse "mønsterkodene" ) bør håndheves.

Er det virkelig en "lås" på låseskjermen din?

Som du sikkert vet fra mange ganger vi har skrevet om feil på låseskjermen i løpet av årene på Naked Security er problemet med ordet "lås" i låseskjermen at det rett og slett ikke er en god metafor for å representere hvor kompleks koden er som styrer prosessen med å "låse" og "låse opp" moderne telefoner.

En moderne mobil låseskjerm er litt som en husdør som har en deadbolt-lås av anstendig kvalitet montert ...

…men har også en postkasse (postluke), glasspaneler for å slippe inn lys, en katteluke, en strekkbar fjærlås som du har lært deg å stole på fordi låsen er litt mas, og en ekstern trådløs ringeklokke/ sikkerhetskamera som er lett å stjele selv om det inneholder Wi-Fi-passordet ditt i ren tekst og de siste 60 minuttene med videoopptak det har tatt opp.

Oh, og i noen tilfeller vil til og med en sikker inngangsdør ha nøklene "gjemt" under dørmatten uansett, noe som stort sett er situasjonen Schütz befant seg i på sin Android-telefon.

Et kart over kronglete passasjer

Moderne telefonlåseskjermer handler ikke så mye om å låse telefonen din som å begrense appene dine til begrensede driftsmoduser.

Dette gir vanligvis deg, og appene dine, med låseskjermtilgang til et stort utvalg av "spesielle tilfeller", for eksempel aktivering av kameraet uten å låse opp, eller dukker opp et utvalgt sett med varslingsmeldinger eller e-postemnelinjer der alle kan se dem uten passordet.

Det Schütz hadde kommet over, i en helt uunngåelig sekvens av operasjoner, var en feil i det som i sjargongen kalles låseskjermen statsmaskin.

En tilstandsmaskin er en slags graf, eller kart, over forholdene et program kan være i, sammen med de lovlige måtene programmet kan flytte fra en stat til en annen, for eksempel en nettverkstilkobling som bytter fra "lytting" til " koblet til", og deretter fra "tilkoblet" til "verifisert", eller en telefonskjerm som skifter fra "låst" enten til "opplåsbar med fingeravtrykk" eller til "opplåsbar, men bare med et passord".

Som du kan forestille deg, blir statlige maskiner for komplekse oppgaver raskt kompliserte selv, og kartet over forskjellige juridiske veier fra en stat til en annen kan ende opp full av vendinger...

…og noen ganger eksotiske hemmelige passasjer som ingen la merke til under testingen.

Faktisk var Schütz i stand til å omforme sin utilsiktede PUK-oppdagelse til en generisk låseskjerm-bypass som alle som plukket opp (eller stjal, eller på annen måte hadde kort tilgang til) en låst Android-enhet kunne lure den inn i ulåst tilstand bevæpnet med noe mer enn en eget SIM-kort og en binders.

I tilfelle du lurer, er bindersen for å løse ut SIM-kortet som allerede er i telefonen, slik at du kan sette inn det nye SIM-kortet og lure telefonen til "Jeg må be om PIN-koden for dette nye SIM-kortet av sikkerhetsgrunner". Schütz innrømmer at da han dro til Googles kontorer for å demonstrere hacket, var det ingen som hadde en skikkelig SIM-utkaster, så de prøvde først en nål, som Schütz klarte å stikke seg med, før de lyktes med en lånt ørering. Vi mistenker at det ikke fungerte å stikke nålen i punktet først (det er vanskelig å treffe utkasterpinnen med en liten spiss), så han bestemte seg for å risikere å bruke den peker utover mens han "være veldig forsiktig", og dermed snu et hackingforsøk til et bokstavelig talt hack. (Vi har vært der, gjort det, strukket oss i fingertuppen.)

Spill systemet med et nytt SIM

Gitt at angriperen kjenner både PIN-koden og PUK-en til det nye SIM-kortet, kan de bevisst få PIN-koden feil tre ganger og deretter umiddelbart få PUK-en riktig, og dermed bevisst tvinge låseskjermens tilstandsmaskin inn i den usikre tilstanden som Schütz oppdaget ved et uhell.

Med riktig timing fant Schütz ut at han ikke bare kunne lande på fingeravtrykkopplåsingssiden når den ikke skulle vises, men også lure telefonen til å godta den vellykkede PUK-opplåsingen som et signal om å avvise fingeravtrykkskjermen og "validere" hele opplåsingsprosessen som om han hadde skrevet inn telefonens fullstendige låsekode.

Lås opp bypass!

Dessverre beskriver mye av Schützs artikkel hvor lang tid det tok Google å reagere på og fikse denne sårbarheten, selv etter at selskapets egne ingeniører hadde bestemt at feilen faktisk var repeterbar og utnyttbar.

Som Schütz selv sa det:

Dette var den mest virkningsfulle sårbarheten jeg har funnet til nå, og den krysset en grense for meg der jeg virkelig begynte å bekymre meg for tidslinjen for fiksering og til og med bare for å holde den som en "hemmelighet" selv. Jeg overreagerer kanskje, men jeg mener ikke så lenge siden FBI kjempet med Apple om nesten det samme.

forsinkelser i avsløringen

Gitt Googles holdning til avsløring av feil, med sitt eget Project Zero-team som er notorisk fast på behovet for å sette strenge avsløringstider og holde seg til dem, har du kanskje forventet at selskapet skulle holde seg til 90-dager-pluss-14-ekstra-i-spesielle-tilfeller-reglene.

Men ifølge Schütz kunne ikke Google administrere det i dette tilfellet.

Tilsynelatende hadde han avtalt en dato i oktober 2022 hvor han planla å avsløre feilen offentlig, slik han nå har gjort, noe som virker som god tid til en feil han oppdaget tilbake i juni 2022.

Men Google gikk glipp av den oktober-fristen.

Oppdateringen for feilen, kalt feilnummer CVE-2022-20465, dukket endelig opp i Androids sikkerhetsoppdateringer fra november 2022, datert 2022-11-05, med Google som beskriver løsningen som: "Ikke avvis tastaturlåsen etter SIM PUK-låsing."

I tekniske termer var feilen det som er kjent a løp tilstand, hvor den delen av operativsystemet som så PUK-inntastingsprosessen for å holde styr på "er det trygt å låse opp SIM-kortet nå?" staten endte opp med å produsere et suksesssignal som trumfet koden som samtidig holdt styr på "er det trygt å låse opp hele enheten?"

Likevel er Schütz nå betydelig rikere takket være Googles bug-premieutbetaling (rapporten hans antyder at han håpet på $100,000 70,000, men han måtte nøye seg med $XNUMX XNUMX til slutt).

Og han ventet på å avsløre feilen etter fristen 15. oktober 2022, og aksepterte at skjønn er den noen ganger bedre delen av tapperhet, og sa:

Jeg [var] for redd til å faktisk sette ut live-feilen, og siden reparasjonen var mindre enn en måned unna, var det egentlig ikke verdt det uansett. Jeg bestemte meg for å vente på løsningen.

Hva gjør jeg?

Sjekk at Android-en din er oppdatert: innstillinger > Sikkerhet > Sikkerhetsoppdatering > Se etter oppdatering.

Merk at da vi besøkte Sikkerhetsoppdatering skjerm, etter å ha ikke brukt Pixel-telefonen vår på en stund, forkynte Android frimodig Systemet ditt er oppdatert, som viser at den hadde sjekket automatisk et minutt eller så tidligere, men fortalte oss fortsatt at vi var på October 5, 2022 sikkerhetsoppdatering.

Vi tvang en ny oppdateringssjekk manuelt og ble umiddelbart fortalt Forbereder systemoppdatering …, etterfulgt av en kort nedlasting, en lang forberedende fase, og deretter en omstartsforespørsel.

Etter omstart hadde vi nådd November 5, 2022 lappnivå.

Vi gikk deretter tilbake og gjorde en til Se etter oppdatering for å bekrefte at det ikke var noen reparasjoner fortsatt utestående.

---

Vi brukte innstillinger > Sikkerhet > Sikkerhetsoppdatering for å komme til force-a-nedlasting-siden:

---

Datoen som ble rapportert virket feil, så vi tvang Android til å gjøre det Se etter oppdatering uansett:

---

Det var faktisk en oppdatering å installere:

---

I stedet for å vente brukte vi Fortsett for å fortsette med en gang:

---

En langvarig oppdateringsprosess fulgte:

---

Vi gjorde en til Se etter oppdatering for å bekrefte at vi var der:

---