Google repareert bug in Pixel-telefoons die pukcode toegang geeft tot apparaat

Beveiligingsonderzoeker David Schütz vond een kwetsbaarheid in Android waarmee een telefoon die met een pincode of vingerafdruk beveiligd is, ontgrendeld kon worden met de pukcode van een simkaart. De kwetsbaarheid is inmiddels door Google gerepareerd.

De kwetsbaarheid werkte in ieder geval met Pixel 6- en Pixel 5-telefoons en mogelijk ook met andere smartphones, zegt Schütz. De kwetsbaarheid werkte door de simkaart uit een telefoon te halen en deze weer in te voeren, zodat de gebruiker om de pincode van de simkaart wordt gevraagd. Een aanvaller moet dan de pincode bewust driemaal verkeerd invoeren, zodat de gebruiker om een pukcode wordt gevraagd.

Bij het correct invoeren van die pukcode ontgrendelt de telefoon meteen. Dus ook als er een vingerafdruk of pincode was ingesteld. Voor de kwetsbaarheid moet de aanvaller toegang hebben tot de telefoon en ook de pukcode weten van een simkaart. Dit laatste zou de aanvaller kunnen bereiken door zelf een simkaart in te voeren waarvan de pukcode bekend is.

De CVE-2022-20465-kwetsbaarheid werkte volgens die CVE-notering in Android-versies 10 tot en met 13 en zat in het KeyguardHostViewController.java-bestand en aanverwante bestanden. Vanwege een fout in dit bestand sloot het besturingssysteem na een correct ingevulde pukcode alle andere beveiligingsschermen, waardoor het besturingssysteem in de praktijk een correcte pukcode zag als een juist ingevulde pincode of vingerafdruk. De bug zit niet in alle telefoons: Tweakers testte de kwetsbaarheid op een Galaxy A51 die nog niet was geüpdatet en het invoeren van de pukcode ontgrendelde deze telefoon niet.

Schütz nam in juni contact op met Google, maar pas in november werd de bug gefixt. De beveiligingsonderzoeker zegt dat de communicatie stroef verliep en Google het pas serieus oppakte toen hij de bug op een bugbountybeurs aan een aantal Google-medewerkers kon laten zien. Schütz kreeg wel een beloning van zeventigduizend dollar voor het melden van de kwetsbaarheid, als uitzondering. Hij was namelijk niet de eerste onderzoeker die de bug meldde, maar omdat hij herhaaldelijk contact opnam, kreeg hij alsnog de beloning.

Reacties (26)

[HenkEisDS]

Ik weet niet hoor, maar is er dan niet iets structureel mis met het ontwerp van de software? Waarom zou het uitmaken via welke applicatie je het toestel ontgrendeld?

[Kees]

Dat ontwerp hebben ze nu dus ook aangepast, waarschijnlijk duurde het daardoor iets langer.

Als ik dit zo lees en simpel probeer samen te vatten dan hield het toestel een lijst met lockscreens bij die je moet doorlopen voordat je toestel geunlocked is. In een normaal scenario is dat alleen je 'hoofd'-lockscreen. Na een reboot of SIM-wissel komt daar nog eens je 'sim-pin' lockscreen bij. En als je die 3x fout doet dan krijg je een 'sim-puk'-lockscreen erbij.

Die laatste bevatte een foutje waardoor hij bij een succescolle puk-code niet alleen zichzelf uit het lijstje haalde, maar de hele lijst leeggooide, en dan was ineens de telefoon ge-unlocked.

[rvt1]

Haha iemand duidelijk een integratie testje vergeten, maar in alle eerlijkheid, dit hint alleen maal op een slecht ontwerp van de software waar onvoldoende over nagedacht is. Je zou verwachten dat dit soort bugs anno 2022 niet meer voor zouden moeten komen.

[Anoniem: 1832746]

Wel grappig hoe op Tweakers het sentiment steeds meer wordt dat iedere security bug een 'fundamentele fout' is.
Dit soort bugs doen zich juist meer voor, simpelweg omdat 1. Software meer code heeft 2. Er meer aandacht is voor dit soort dingen.

Dat 'dit soort bugs' zich niet meer voor mogen doen is heel naief natuurlijk. Software verandert dus kwetsbaarheden veranderen. Je weet niet of dit systeem 5 jaar geleden fundamenteel anders werkte, dus dan kun je niet zeggen 'ja het is nieuw, maar alle bugs moeten er toch wel uit zijn (want ja, ergens moet heet fundamenteel fout zijn )'

[rvt1]

Dit soort bug op het Home Screen / unlock zijn absoluut bekend en moet dan ook absoluut de aandacht krijgen. Zeker van een bedrijf als Google die maar al te graag fouten in andermans software wilt vinden zou zeker hier intern veel aandacht aan moeten besteden. Iemand is dan ook echt vergeten hier een robuuste test voor te schrijven, zeker als het een en anders is veranderd, wat natuurlijk begrijpelijk is maar moet wel afgedekt worden..

[Johan1995]

Helemaal mee eens! Google wil ook 2-factor auth pushen, maar als deze basale dingen fout gaan, dan zouden ze toch meer naar zichzelf moeten kijken...

[YopY]

idd, je zou denken dat een telefoon en alle data vergrendeld is totdat er een code ingevuld is. Maar wat elders uitgelegd werd, dan zouden apps in de achtergrond niet goed meer werken.

[jpfx]

Altijd gedacht dat dit by-design was. Heb dat al een paar keer gedaan bij een wat ouder familielid die het wachtwoord was vergeten. Ik zou toch liever een simkaart vervangen dan een hele telefoon als je je ww bent vergeten.

[RoanV]

Lijkt me zeker niet wenselijk, zo kom je wel heel makkelijk bij (mogelijk) gevoelige data.

Telefoon hoeft natuurlijk niet vervangen te worden als het wachtwoord kwijt is, resetten naar fabrieksinstellingen kan altijd.

[Argantonis]

Tja als dat zo zou zijn dan kon je deze telefoons wel compleet afschrijven voor iedereen die niet alles met de wereld wilt delen. Dan hoeft een overheid niet eens een dure zero-day exploit te gebruiken om een telefoon te unlocken, gewoon ff sim-kaartje wisselen!

[Jrz]

$70k misgelopen😉

[Yzord]

Schütz kreeg wel een beloning van zeventigduizend dollar voor het melden van de kwetsbaarheid, als uitzondering. Hij was namelijk niet de eerste onderzoeker die de bug meldde, maar omdat hij herhaaldelijk contact opnam, kreeg hij alsnog de beloning.

Das ook gek. Meerdere mensen hadden dit dus al gemeld, maar omdat Schútz in spammodus stond krijgt hij een beloning als uitzondering. Hoe zit dat dan met die andere onderzoekers? Of is dat een manier om zo min mogelijk bugbounties uit te keren door te zeggen dat je niet de eerste bent die dit meldt? Dat kan je toch niet controleren.

En als het dan niet zo adequaat wordt opgepakt, zou dit niet een van de 'backdoors' kunnen zijn voor overheidsdiensten?

[vanaalten]

Je zou kunnen zeggen dat de bug die beloond is hier niet de PUK-code bug is, maar dat het bugreport-proces bij Google zelf wat fouten bevat. Als je een serieuze bug aanmeldt en die valt tussen wal en schip... is dat op zich wel een bug.

[kodak]

Maar de vraag is hoe het zit met de andere onderzoekers. Het feit dat die iets melden wat uiteindelijk toch is opgepakt als security bug wil niet zeggen dat die dus maar geen beloning verdienen.

En om te stellen dat google hier een fout in het proces had wat hij opmerkte blijkt niet. Hij wist ze van gedachten te veranderen voor deze bug. Maar dat is geen fout in het proces, dat is de vrijheid om van mening te verschillen over de urgentie. Als je daar 70.000 voor krijgt dan vermoed ik dat andere duplicate melders daar ook wel voor in aanmerking kwamen.

[nzall]

Volgens het artikel van Schütz heeft Google een zeldzame uitzondering gemaakt omdat er bij de oorspronkelijke melding blijkbaar iets was misgelopen waardoor deze niet heeft geleid tot het in gang zetten van het bugfixproces. Omdat door zijn aandringen de bug serieus werd genomen en alsnog opgelost, hebben ze hem alsnog een beloning gegeven.

Overigens is Schütz ook gewond geraakt tijdens het demonstreren van de bug volgens zijn blog. Hij had zich geprikt met een naald tijdens het openmaken van het sim schuifje, en één van de Google medewerkers moest hem een pleister geven. Het zou kunnen dat dit invloed heeft gehad op de keuze tot het maken van deze uitzondering.

Ik heb zonet nog eens de correspondentie gelezen die Schütz heeft bijgehouden. Volgens de medewerker van Google konden de Google engineers de bug niet reproduceren aan de hand van de oorspronkelijke melding en was het door de nieuwe melding dat ze deze bug pas konden reproduceren. Ik vermoed dat dit ook zeker en vast heeft meegespeeld.

[Reactie gewijzigd door nzall op 23 juli 2024 17:47]

[kodak]

Er valt niet zomaar van een duplicate te spreken als ze de eerste melding niet eens te reproduceren zou zijn. Een bug gaat namelijk niet alleen om de melding dat iets hetzelfde lijkt, het moet ook aantoonbaar een zelfde oorzaak hebben.

Daarbij houden ze constant vol dat ze aan die eerdere melding werken tot deze onderzoeker dreigde publiek te gaan en er voor die melding zelfs ook al 90 dagen verstreken waren.

Google toont dus nergens aan dat het werkelijk dupicate was en werkelijk de oorspronkelijke melding als securitybug aan het oplossen waren. Maar ze tonen wel pas in actie te komen als een melder dreigt publiek te gaan. Dat stelt mij niet gerust hoe google hier eerlijk is om dit duplicate te noemen en de oorspronkelijke melders te belonen.

[henk717]

Heb hem meteen getest op mijn Android 10 telefoon met custom rom met een beveiligingspatch van 5 oktober 2020 (Ja ik weet het, niet de nieuwste). In mijn geval blijft de telefoon netjes vergrendeld. Dus het kan inderdaad zijn dat de bug pixel specifiek is, of pas later is toegevoegd.

Update: Dit was zonder de simkaart te verwijderen en via een reguliere reboot, mocht dit uitmaken dan is mijn test niet accuraat. Ik heb geen sim eject tool bij de hand om dit te checken.

Update 2: Exploit uitgevoerd zoals aangetoond op de video, niet kwetsbaar. Iemand anders met een Pixel 2 (In mijn geval OnePlus 3T met custom rom) heeft dezelfde security patch als ik heb en ook die persoon heeft de bug niet.

[Reactie gewijzigd door henk717 op 23 juli 2024 17:47]

[RoanV]

When in doubt: paperclip!

[Xerxes249]

Wauw dat is superheftig als het enige nodige om een telefoon te hacken een simkaart is, also, is op Android stuff niet encrypted zolang de telefoon gelockt is? Dit ruikt naar slechte beveiligingsarchitectuur.

[Thijn41]

Alles is encrypted opgeslagen, maar wordt decrypted op het moment dat je voor de eerste keer je pin code invoert na een herstart. Als je je telefoon lockt blijft dat decrypted in memory draaien natuurlijk, anders kunnen apps niet in de achtergrond blijven draaien en zul je nooit notificaties of iets dergelijks krijgen.
Daarnaast zal het veel te lang duren om alles te decrypted elke keer als je je telefoon unlockt.
Hetzelfde zal ongetwijfeld bij iOS gebeuren.

[Xerxes249]

Hardwarematige decrypten en wel of niet beveiligingssleutels in memory hebben. Op iOS heb je verschillende encryptie-niveaus, dus sommige data is beschikbaar na eerste unlock, andere alleen als unlocked. Als ontwikkelaar heb je daar ook controle over. Wil je bijv je app laten communiceren met een Apple Watch in de achtergrond dan moet je de benodigde data opslaan met een 'after first unlock' beschikbare sleutel.

[sdziscool]

Incorrect, een groot deel van je data is gewoon encrypted tijdens het runnen en wordt pas decrypted zodra je de data accessed, en zodra je ze sluit blijft alleen het decrypted bestand over. dit is mogelijk dankzij encryptie schemas zoals xts-aes. Alles in RAM (zoals bijvoorbeeld live applicaties) draaien daar wel decrypted zoals je aangeeft.
Heel je telefoon decrypten tijdens startup zou ongeveer een uur duren zelfs op hedendaagse snelle opslag/cpu snelheden.

[Vyo]

Huh, nooit zo bij stil gestaan. Als het allemaal encrypted is en de hele zwik bij elke OS update geverifieerd moet worden etc. snap ik ineens waarom updates op mobiele telefoons (en Apple devices in 't algemeen als ik er bij stil sta) rustig tientallen minuten lang duren.

[Luchtbakker]

Hoe simpel kan een bug eigenlijk zijn he.

[snrwo1]

de aanhouder wint

[Mel33]

Ha mooi ik kom al jaren niet meer in mijn oude Samsung met Android 10 en een oud google account.
Eens kijken of dit werkt.