En bug-prisjägare som heter David Schütz har precis publicerat en detaljerad rapport beskrev hur han korsade svärd med Google i flera månader över vad han ansåg vara ett farligt säkerhetshål för Android.

Enligt Schütz, snubblade han på ett totalt Android-låsskärmsbypass-fel helt av en slump i juni 2022, under verkliga förhållanden som lätt kunde ha hänt vem som helst.

Med andra ord, det var rimligt att anta att andra människor kan få reda på felet utan att medvetet leta efter buggar, vilket gör upptäckten och offentliggörandet (eller privat missbruk) som ett nolldagarshål mycket mer sannolikt än vanligt.

Tyvärr lappades det inte förrän i november 2022, vilket är anledningen till att han har avslöjat det först nu.

Ett serenditiskt batteriavbrott

Enkelt uttryckt hittade han felet eftersom han glömde att stänga av eller ladda sin telefon innan han gav sig ut på en lång resa, och lämnade enheten att ta slut på juice obemärkt medan han var på vägen.

Enligt Schütz skyndade han sig att skicka några meddelanden efter att ha kommit hem (vi gissar att han hade suttit på ett flygplan) med den lilla mängden ström kvar i batteriet...

…när telefonen dog.

Vi har alla varit där och letat efter en laddare eller ett reservbatteri för att få omstart av telefonen för att låta folk veta att vi har kommit fram säkert, väntar på bagageutlämning, har nått tågstationen, räknar med att komma hem om 45 minuter, kunde stanna till i butikerna om någon akut behöver något, eller vad vi nu har att säga.

Och vi har alla kämpat med lösenord och PIN-koder när vi har bråttom, speciellt om det är koder som vi sällan använder och aldrig utvecklat "muskelminne" för att skriva in.

I Schütz fall var det den ödmjuka PIN-koden på hans SIM-kort som störde honom, och eftersom SIM-PIN-koder kan vara så korta som fyra siffror, är de skyddade av en hårdvarulåsning som begränsar dig till tre gissningar som mest. (Vi har varit där, gjort det, låst oss ute.)

Efter det måste du ange en 10-siffrig "huvud-PIN" känd som PUK, förkortning för personlig upplåsningsnyckel, som vanligtvis är tryckt inuti förpackningen som SIM-kortet säljs i, vilket gör det i stort sett manipulationssäkert.

Och för att skydda sig mot PUK-gissningsattacker fritar SIM-kortet sig automatiskt efter 10 felaktiga försök och måste bytas ut, vilket vanligtvis innebär att man vänder sig till en mobiltelefonbutik med identifiering.

Vad gjorde jag med den förpackningen?

Lyckligtvis, eftersom han inte skulle ha hittat felet utan det, hittade Schütz den ursprungliga SIM-förpackningen gömd någonstans i ett skåp, repade av skyddsremsan som skymmer PUK-koden och skrev in den.

Vid det här laget, med tanke på att han höll på att starta telefonen efter att den tog slut, borde han ha sett telefonens låsskärm som kräver att han skulle skriva in telefonens upplåsningskod...

…men i stället insåg han att han var det vid fel typ av låsskärm, eftersom det erbjöd honom en chans att låsa upp enheten med endast hans fingeravtryck.

Det är bara tänkt att hända om din telefon låser sig när den används regelbundet, och inte ska hända efter en avstängning och omstart, när en fullständig lösenordskod återautentisering (eller en av dessa "mönsterkoder" genom att dra för att låsa upp ) bör verkställas.

Finns det verkligen ett "lås" på din låsskärm?

Som du säkert vet från många gånger vi har skrivit om buggar på låsskärmen över åren på Naked Security är problemet med ordet "lås" i låsskärmen att det helt enkelt inte är en bra metafor för att representera hur komplex koden är som hanterar processen att "låsa" och "låsa upp" moderna telefoner.

En modern mobil låsskärm påminner lite om en ytterdörr i ett hus som har ett lås av anständig kvalitet...

…men har också en brevlåda (postfack), glaspaneler för att släppa in ljus, en kattlucka, ett sänkbart fjäderlås som du har lärt dig att lita på eftersom låskolven är lite krångligt och en extern trådlös dörrklocka/ säkerhetskamera som är lätt att stjäla även om den innehåller ditt Wi-Fi-lösenord i klartext och de senaste 60 minuterna av videofilmer som den spelade in.

Åh, och i vissa fall kommer även en säker ytterdörr att ha nycklarna "dolda" under dörrmattan i alla fall, vilket i stort sett är den situation som Schütz hamnade i på sin Android-telefon.

En karta över krokiga passager

Moderna telefonlåsskärmar handlar inte så mycket om att låsa din telefon som att begränsa dina appar till begränsade driftlägen.

Detta lämnar vanligtvis dig och dina appar med låsskärmsåtkomst till en mängd funktioner för "specialfall", som att aktivera kameran utan att låsa upp, eller att poppa upp en utvald uppsättning aviseringsmeddelanden eller e-postämnesrader där vem som helst kan se dem utan lösenordet.

Det Schütz hade stött på, i en helt onormal sekvens av operationer, var ett fel i det som på jargongen kallas låsskärmen statsmaskin.

En tillståndsmaskin är en sorts graf, eller karta, över de förhållanden som ett program kan befinna sig i, tillsammans med de lagliga sätt som programmet kan flytta från ett tillstånd till ett annat, såsom en nätverksanslutning som växlar från "lyssna" till " ansluten", och sedan från "ansluten" till "verifierad", eller en telefonskärm som växlar från "låst" antingen till "upplåsbar med fingeravtryck" eller till "upplåsbar men endast med ett lösenord".

Som du kan föreställa dig blir statliga maskiner för komplexa uppgifter snabbt komplicerade själva, och kartan över olika rättsliga vägar från en stat till en annan kan hamna full av vändningar...

…och ibland exotiska hemliga gångar som ingen märkte under testningen.

Schütz kunde faktiskt tolka sin oavsiktliga PUK-upptäckt i en generisk förbikoppling av låsskärmen genom vilken alla som plockade upp (eller stal, eller på annat sätt hade kort tillgång till) en låst Android-enhet kunde lura den till det olåsta tillståndet beväpnad med ingenting mer än en ett eget SIM-kort och ett gem.

Om du undrar är gemen att mata ut SIM-kortet som redan finns i telefonen så att du kan sätta in det nya SIM-kortet och lura telefonen till "Jag måste begära PIN-koden för detta nya SIM-kort av säkerhetsskäl". Schütz medger att när han gick till Googles kontor för att demonstrera hacket var det ingen som hade en ordentlig SIM-utkastare, så de provade först en nål, som Schütz lyckades sticka sig med, innan de lyckades med ett lånat örhänge. Vi misstänker att det inte fungerade att sticka in nålen först (det är svårt att träffa utkastarstiftet med en liten spets) så han bestämde sig för att riskera att använda den utåt samtidigt som han "var riktigt försiktig", vilket förvandlade ett hackningsförsök till ett bokstavligt hacka. (Vi har varit där, gjort det, sträckt oss i fingerspetsen.)

Spela systemet med ett nytt SIM-kort

Med tanke på att angriparen känner till både PIN-koden och PUK-koden för det nya SIM-kortet, kan de medvetet få PIN-koden fel tre gånger och sedan omedelbart få PUK-koden rätt, vilket medvetet tvingar låsskärmens tillståndsmaskin till det osäkra tillståndet som Schütz upptäckte av misstag.

Med rätt timing fann Schütz att han inte bara kunde landa på fingeravtrycksupplåsningssidan när den inte skulle dyka upp, utan också lura telefonen att acceptera den lyckade PUK-upplåsningen som en signal för att stänga av fingeravtrycksskärmen och "validera" hela upplåsningsprocessen som om han hade skrivit in telefonens fullständiga låskod.

Lås upp bypass!

Tyvärr beskriver mycket av Schütz artikel hur lång tid det tog Google att reagera på och åtgärda denna sårbarhet, även efter att företagets egna ingenjörer hade beslutat att buggen verkligen var repeterbar och exploaterad.

Som Schütz själv uttryckte det:

Detta var den mest påverkande sårbarheten som jag har hittat hittills, och den passerade en gräns för mig där jag verkligen började oroa mig för fixtidslinjen och till och med bara för att hålla den som en "hemlig" själv. Jag kanske överreagerar, men jag menar för inte så länge sedan FBI kämpade med Apple för nästan samma sak.

Avslöjande förseningar

Med tanke på Googles inställning till avslöjande av buggar, med sitt eget Project Zero-team som är notoriskt bestämda om behovet av att fastställa strikta avslöjandetider och hålla fast vid dem, du kanske hade förväntat dig att företaget skulle hålla sig till sina 90-dagars-plus-14-extra-i-speciella-fall-regler.

Men enligt Schütz kunde Google inte hantera det i det här fallet.

Tydligen hade han kommit överens om ett datum i oktober 2022 då han planerade att avslöja buggen offentligt, som han nu har gjort, vilket verkar som gott om tid för en bugg som han upptäckte redan i juni 2022.

Men Google missade den deadline i oktober.

Patchen för felet, betecknat buggnummer CVE-2022-20465, dök äntligen upp i Androids säkerhetskorrigeringar från november 2022, daterade 2022-11-05, med Google som beskriver fixen som: "Stäng inte knapplåset efter att SIM PUK-låset har låsts upp."

I tekniska termer var buggen vad som är känt a loppskick, där den del av operativsystemet som tittade på PUK-inmatningsprocessen för att hålla reda på "är det säkert att låsa upp SIM-kortet nu?" staten slutade med att producera en framgångssignal som trumfade koden som samtidigt höll reda på "är det säkert att låsa upp hela enheten?"

Ändå är Schütz nu betydligt rikare tack vare Googles bug-bounty-utbetalning (hans rapport tyder på att han hoppades på $100,000 70,000, men han fick nöja sig med $XNUMX XNUMX till slut).

Och han väntade med att avslöja felet efter deadline den 15 oktober 2022, och accepterade att diskretion är den ibland bättre delen av mod, och sa:

Jag [var] för rädd för att faktiskt lägga ut live-buggen och eftersom korrigeringen var mindre än en månad bort var det inte riktigt värt det ändå. Jag bestämde mig för att vänta på åtgärden.

Vad göra?

Kontrollera att din Android är uppdaterad: Inställningar > Säkerhet > Säkerhetsuppdatering > Sök efter uppdatering.

Observera att när vi besökte Säkerhetsuppdatering skärm, efter att inte ha använt vår Pixel-telefon på ett tag, utropade Android djärvt Ditt system är uppdaterat, som visar att den hade kontrollerat automatiskt någon minut tidigare, men ändå berättade för oss att vi var på October 5, 2022 säkerhetsuppdatering.

Vi tvingade fram en ny uppdateringskontroll manuellt och fick genast besked Förbereder systemuppdatering..., följt av en kort nedladdning, ett långt förberedande skede och sedan en begäran om omstart.

Efter omstart hade vi nått November 5, 2022 lappnivå.

Vi gick sedan tillbaka och gjorde en till Sök efter uppdatering för att bekräfta att det inte fanns några korrigeringar fortfarande utestående.

Vi använde Inställningar > Säkerhet > Säkerhetsuppdatering för att komma till force-a-download-sidan:

Datumet som rapporterades verkade fel så vi tvingade Android att göra det Sök efter uppdatering i alla fall:

Det fanns verkligen en uppdatering att installera:

Istället för att vänta använde vi CV för att fortsätta på en gång:

En lång uppdateringsprocess följde:

Vi gjorde en till Sök efter uppdatering för att bekräfta att vi var där: