Een bug premiejager genaamd David Schütz heeft zojuist een gedetailleerd rapport waarin hij beschrijft hoe hij gedurende enkele maanden de degens kruiste met Google over wat hij als een gevaarlijk beveiligingslek in Android beschouwde.
Volgens Schütz stuitte hij in juni 2022 per ongeluk op een totale Android-lockscreen-bypass-bug, onder realistische omstandigheden die iedereen gemakkelijk had kunnen overkomen.
Met andere woorden, het was redelijk om aan te nemen dat andere mensen de fout zouden ontdekken zonder opzettelijk op zoek te gaan naar bugs, waardoor de ontdekking en openbare onthulling (of privémisbruik) als een zero-day-gat veel waarschijnlijker is dan normaal.
Helaas werd het pas in november 2022 gepatcht, daarom heeft hij het nu pas bekendgemaakt.
Een serenditous batterijstoring
Simpel gezegd, hij vond de bug omdat hij vergat zijn telefoon uit te zetten of op te laden voordat hij aan een lange reis begon, waardoor het apparaat onopgemerkt leeg raakte terwijl hij onderweg was.
Volgens Schütz haastte hij zich om wat berichten te verzenden nadat hij thuis was gekomen (we vermoeden dat hij in een vliegtuig had gezeten) met de kleine hoeveelheid stroom die nog in de batterij zat...
...toen de telefoon het begaf.
We zijn er allemaal geweest, op zoek naar een oplader of een reservebatterij om de telefoon opnieuw op te starten om mensen te laten weten dat we veilig zijn aangekomen, wachten bij de bagageophaaldienst, het treinstation hebben bereikt, verwachten binnen 45 minuten thuis te zijn, zou kunnen stoppen bij de winkels als iemand dringend iets nodig heeft, of wat we ook te zeggen hebben.
En we hebben allemaal geworsteld met wachtwoorden en pincodes als we haast hebben, vooral als het codes zijn die we zelden gebruiken en nooit 'spiergeheugen' hebben ontwikkeld om in te typen.
In het geval van Schütz was het de nederige pincode op zijn simkaart die hem verbaasde, en omdat sim-pincodes maar vier cijfers kunnen hebben, worden ze beschermd door een hardwarevergrendeling die je beperkt tot maximaal drie keer raden. (We zijn daar geweest, hebben dat gedaan, hebben onszelf buitengesloten.)
Daarna moet u een 10-cijferige "master PIN" invoeren die bekend staat als de PUK, een afkorting voor persoonlijke deblokkeringssleutel, die meestal wordt afgedrukt in de verpakking waarin de simkaart wordt verkocht, waardoor deze grotendeels fraudebestendig is.
En om te beschermen tegen PUK-gisaanvallen, breekt de simkaart zichzelf automatisch af na 10 verkeerde pogingen en moet deze worden vervangen, wat meestal betekent dat je met identificatie naar een mobiele telefoonwinkel moet gaan.
Wat heb ik met die verpakking gedaan?
Gelukkig, omdat hij de bug niet zou hebben gevonden zonder de bug, vond Schütz de originele verpakking van de simkaart ergens in een kast, kraste hij de beschermende strip die de puk verduistert en typte deze in.
Op dit moment, aangezien hij bezig was met het opstarten van de telefoon nadat deze zonder stroom kwam te zitten, had hij het vergrendelscherm van de telefoon moeten zien en hem gevraagd hebben de ontgrendelingscode van de telefoon in te voeren...
... maar in plaats daarvan realiseerde hij zich dat hij... op het verkeerde soort lockscreen, omdat het hem de kans bood om het apparaat te ontgrendelen met alleen zijn vingerafdruk.
Dat zou alleen moeten gebeuren als je telefoon vergrendelt tijdens normaal gebruik, en het is niet de bedoeling dat dit gebeurt na het uitschakelen en opnieuw opstarten, wanneer een volledige toegangscode opnieuw wordt geverifieerd (of een van die swipe-to-unlock "patrooncodes" ) moet worden gehandhaafd.
Zit er echt een "slot" in je lockscreen?
Zoals je waarschijnlijk weet van de vele keren wij hebben geschreven over bugs op het lockscreen Door de jaren heen op Naked Security is het probleem met het woord "vergrendelen" in lockscreen dat het gewoon geen goede metafoor is om aan te geven hoe complex de code is die het proces van het "vergrendelen" en "ontgrendelen" van moderne telefoons beheert.
Een modern mobiel vergrendelingsscherm lijkt een beetje op een voordeur van een huis met een nachtschootslot van goede kwaliteit ...
...maar heeft ook een brievenbus (postsleuf), glazen panelen om licht binnen te laten, een kattenluik, een hangbaar veerslot waar je op hebt leren vertrouwen omdat de nachtschoot een beetje gedoe is, en een externe draadloze deurbel/ beveiligingscamera die gemakkelijk te stelen is, ook al bevat deze uw wifi-wachtwoord in platte tekst en de laatste 60 minuten aan videobeelden die hij heeft opgenomen.
Oh, en in sommige gevallen zal zelfs een veilig ogende voordeur de sleutels toch "verborgen" hebben onder de deurmat, wat ongeveer de situatie is waarin Schütz zich bevond op zijn Android-telefoon.
Een kaart met bochtige gangen
Moderne telefoonvergrendelingsschermen gaan niet zozeer over het vergrendelen van uw telefoon als wel over het beperken van uw apps tot beperkte werkingsmodi.
Dit laat u en uw apps doorgaans met lockscreen-toegang tot een overvloedige reeks "speciale case" -functies, zoals het activeren van de camera zonder te ontgrendelen, of het opduiken van een samengestelde set meldingsberichten of e-mailonderwerpregels waar iedereen ze kan zien zonder de toegangscode.
Wat Schütz was tegengekomen, in een volkomen onopvallende volgorde van bewerkingen, was een fout in wat in het jargon bekend staat als het lockscreen staat machine.
Een toestandsmachine is een soort grafiek, of kaart, van de omstandigheden waarin een programma zich kan bevinden, samen met de legale manieren waarop het programma van de ene toestand naar de andere kan gaan, zoals een netwerkverbinding die overschakelt van "luisteren" naar " verbonden", en vervolgens van "verbonden" naar "geverifieerd", of een telefoonscherm dat van "vergrendeld" naar "ontgrendelbaar met vingerafdruk" of naar "ontgrendelbaar maar alleen met een toegangscode" schakelt.
Zoals je je kunt voorstellen, worden staatsmachines voor complexe taken zelf al snel gecompliceerd, en de kaart van verschillende juridische paden van de ene staat naar de andere kan vol wendingen en bochten eindigen...
...en soms exotische geheime doorgangen die niemand tijdens het testen opmerkte.
Schütz was inderdaad in staat zijn onbedoelde PUK-ontdekking om te zetten in een generieke lockscreen-bypass waarmee iedereen die een vergrendeld Android-apparaat oppakte (of stal of anderszins korte tijd toegang had tot) het in de ontgrendelde staat kon brengen, gewapend met niets meer dan een nieuwe simkaart en een paperclip.
Voor het geval je het je afvraagt: de paperclip is bedoeld om de simkaart die al in de telefoon zit uit te werpen, zodat je de nieuwe simkaart kunt plaatsen en de telefoon kunt misleiden tot de status 'Ik moet om veiligheidsredenen de pincode voor deze nieuwe simkaart aanvragen'. Schütz geeft toe dat toen hij naar het kantoor van Google ging om de hack te demonstreren, niemand een goede SIM-uitwerper had, dus probeerden ze eerst een naald, waarmee Schütz zichzelf kon steken, voordat ze slaagden met een geleende oorbel. We vermoeden dat het niet werkte om de naald eerst in de punt te steken (het is moeilijk om de uitwerppen met een klein punt te raken), dus besloot hij het risico te nemen om de punt naar buiten te gebruiken terwijl hij "heel voorzichtig" was, waardoor een hackpoging letterlijk werd hacken. (We zijn daar geweest, hebben dat gedaan, hebben ons in de vingertop geprikt.)
Het systeem gamen met een nieuwe simkaart
Aangezien de aanvaller zowel de pincode als de pukcode van de nieuwe simkaart kent, kunnen ze de pincode drie keer met opzet verkeerd krijgen en vervolgens de puk meteen goed krijgen, waardoor de lockscreen-statusmachine opzettelijk in de onveilige toestand wordt gedwongen die Schütz per ongeluk ontdekte.
Met de juiste timing ontdekte Schütz dat hij niet alleen op de ontgrendelingspagina voor vingerafdrukken kon komen wanneer deze niet had moeten verschijnen, maar ook de telefoon kon misleiden om de succesvolle PUK-ontgrendeling te accepteren als een signaal om het vingerafdrukscherm te sluiten en "valideer" het hele ontgrendelingsproces alsof hij de volledige blokkeringscode van de telefoon had ingetypt.
Ontgrendel de bypass!
Helaas beschrijft een groot deel van het artikel van Schütz de tijd die Google nodig had om op deze kwetsbaarheid te reageren en deze op te lossen, zelfs nadat de eigen ingenieurs van het bedrijf hadden besloten dat de bug inderdaad herhaalbaar en exploiteerbaar was.
Zoals Schütz het zelf verwoordde:
Dit was de meest impactvolle kwetsbaarheid die ik tot nu toe heb gevonden, en het overschreed voor mij een grens waar ik me echt zorgen begon te maken over de tijdlijn van de fix en zelfs om het zelf als een "geheim" te houden. Ik reageer misschien overdreven, maar ik bedoel, niet zo lang geleden vocht de FBI met Apple voor bijna hetzelfde.
Vertragingen in de openbaarmaking
Gezien de houding van Google ten aanzien van het vrijgeven van bugs, is het met zijn eigen Project Zero-team notoir vastberaden over de noodzaak om strikte openbaarmakingstijden en blijf bij hen, had je misschien verwacht dat het bedrijf zich aan de regels van 90 dagen plus 14 extra in speciale gevallen zou houden.
Maar volgens Schütz kon Google het in dit geval niet redden.
Blijkbaar had hij in oktober 2022 een datum afgesproken waarop hij van plan was de bug publiekelijk bekend te maken, zoals hij nu heeft gedaan, wat voldoende tijd lijkt voor een bug die hij in juni 2022 ontdekte.
Maar Google miste die deadline van oktober.
De patch voor de fout, aangeduid met bugnummer CVE-2022-20465, verscheen uiteindelijk in Android's beveiligingspatches van november 2022, gedateerd 2022-11-05, met Google de oplossing beschrijven als: "Verwijder toetsbeveiliging niet na SIM PUK-ontgrendeling."
In technische termen was de bug wat bekend staat als een race conditie, waar het deel van het besturingssysteem dat het PUK-invoerproces bekeek om de "is het veilig om de simkaart nu te ontgrendelen?" state produceerde uiteindelijk een successignaal dat de code overtroefde die tegelijkertijd bijhield van "is het veilig om het hele apparaat te ontgrendelen?"
Toch is Schütz nu aanzienlijk rijker dankzij de bug bounty-uitbetaling van Google (zijn rapport suggereert dat hij hoopte op $ 100,000, maar hij moest uiteindelijk genoegen nemen met $ 70,000).
En hij bleef uit bij het onthullen van de bug na de deadline van 15 oktober 2022, en accepteerde dat discretie soms het betere deel van moed is, en zei:
Ik [was] te bang om de live bug uit te brengen en aangezien de oplossing nog geen maand verwijderd was, was het toch niet echt de moeite waard. Ik besloot te wachten op de oplossing.
Wat te doen?
Controleer of je Android up-to-date is: Instellingen > Security > Beveiligingsupdate > Controleer op updates.
Merk op dat toen we de . bezochten Beveiligingsupdate scherm, nadat we onze Pixel-telefoon een tijdje niet hebben gebruikt, verklaarde Android stoutmoedig: Uw systeem is up to date, waaruit blijkt dat het een minuut of zo eerder automatisch had gecontroleerd, maar ons nog steeds vertelde dat we op de waren October 5, 2022 beveiligingsupdate.
We hebben handmatig een nieuwe updatecontrole geforceerd en kregen onmiddellijk te horen Systeemupdate voorbereiden…, gevolgd door een korte download, een lange voorbereidende fase en vervolgens een herstartverzoek.
Na het opnieuw opstarten hadden we de . bereikt November 5, 2022 patchniveau.
We gingen toen terug en deden er nog een Controleer op updates om te bevestigen dat er geen oplossingen meer waren.
We gebruikten Instellingen > Security > Beveiligingsupdate om naar de force-a-download-pagina te gaan:
De gerapporteerde datum leek verkeerd, dus we dwongen Android ertoe Controleer op updates in ieder geval:
Er was inderdaad een update om te installeren:
In plaats van te wachten gebruikten we Hervat om meteen verder te gaan:
Er volgde een langdurig updateproces:
We hebben er nog een gedaan Controleer op updates om te bevestigen dat we er waren:
