Ohtlik SIM-kaardi vahetuse lukustuskuva ümbersõit – värskendage Androidi kohe!

Vigade pearahakütt nimega David Schütz avaldas äsja a üksikasjalik aruanne kirjeldades, kuidas ta mitu kuud Google'iga mõõkasid risustas selle üle, mida ta pidas ohtlikuks Androidi turvaauguks.

Schützi sõnul komistas ta 2022. aasta juunis täiesti juhuslikult Androidi lukustusekraani ümbersõiduveale reaalsetes tingimustes, mis võinuks kergesti juhtuda igaühega.

Teisisõnu oli mõistlik eeldada, et teised inimesed võisid veast teada saada, ilma et nad oleks asunud tahtlikult vigu otsima, muutes selle avastamise ja avalikuks (või eraviisilise kuritarvitamise) kui nullpäeva augu tavapärasest palju tõenäolisemaks.

Kahjuks sai see paigatud alles 2022. aasta novembris, mistõttu ta avalikustas selle alles nüüd.

Õudne aku katkestus

Lihtsamalt öeldes avastas ta vea, kuna unustas enne pikale teekonnale asumist telefoni välja lülitada või laadida, mistõttu jäi seade teel olles märkamatult tühjaks saama.

Schützi sõnul tormas ta pärast koju jõudmist (arvame, et ta oli lennukis) sõnumeid saatma, kuna akus oli veel vähe energiat...

…kui telefon suri.

Oleme kõik seal käinud ja otsinud laadijat või varuakut, et telefon taaskäivitada, et anda inimestele teada, et oleme turvaliselt kohale jõudnud, ootame pagasi äravõtmist, oleme jõudnud rongijaama, ootame 45 minuti pärast koju jõudmist, võiks poodides peatuda, kui kellelgi midagi hädasti vaja on või mida iganes meil öelda on.

Ja me kõik oleme hädas paroolide ja PIN-koodidega, kui meil on kiire, eriti kui need on koodid, mida kasutame harva ja millel pole kunagi sisestamiseks loodud lihasmälu.

Schützi puhul oli see SIM-kaardil olev tagasihoidlik PIN-kood, mis teda jahmatas, ja kuna SIM-i PIN-koodid võivad olla nii lühikesed kui neli numbrit, on need kaitstud riistvaralukuga, mis piirab maksimaalselt kolme oletust. (Oleme seal olnud, teinud seda, lukustanud end välja.)

Pärast seda peate sisestama 10-kohalise pea-PIN-koodi, mida tuntakse PUK-koodina, lühendina isiklik deblokeerimisvõti, mis on tavaliselt trükitud pakendisse, milles SIM-kaart müüakse, mis muudab selle suures osas võltsimiskindlaks.

PUK-i äraarvamise rünnakute eest kaitsmiseks praadib SIM-kaart ennast automaatselt pärast 10 vale katset ja see tuleb välja vahetada, mis tavaliselt tähendab identifitseerimisega mobiiltelefoni poodi pöördumist.

Mida ma selle pakendiga tegin?

Õnneks, kuna ta poleks ilma selleta viga leidnud, otsis Schütz kuskile kappi peidetud SIM-i originaalpakendi, kraapis PUK-koodi varjava kaitseriba maha ja trükkis selle sisse.

Arvestades, et ta käivitas telefoni pärast selle tühjenemist, oleks ta praegu pidanud nägema telefoni lukustuskuva, mis nõuab telefoni avamiskoodi sisestamist...

…aga selle asemel sai ta aru, et ta oli vales lukustuskuvas, sest see pakkus talle võimalust seade avada, kasutades ainult oma sõrmejälge.

See peaks juhtuma ainult siis, kui teie telefon lukustub tavapärase kasutamise ajal, ja see ei peaks juhtuma pärast väljalülitamist ja taaskäivitamist, kui täielik pääsukood uuesti autentitakse (või mõni neist libistades avamiseks mustrikoode). ) tuleks jõustada.

Kas teie lukustuskuval on tõesti "lukk"?

Nagu te ilmselt teate palju kordi me oleme kirjutatud lukustusekraani vead aastate jooksul alasti turvalisuse puhul seisneb lukustusekraani sõna "lukk" probleem selles, et see pole lihtsalt hea metafoor, et näidata, kui keeruline on kood, mis juhib tänapäevaste telefonide "lukustamise" ja "avamise" protsessi.

Moodne mobiilne lukustusekraan on natuke nagu maja välisuks, millele on paigaldatud korraliku kvaliteediga lukustus...

…aga sellel on ka kirjakast (postipesa), klaaspaneelid valguse sisselaskmiseks, kassiklapp, lahtikäiv vedrulukk, millele olete õppinud lootma, sest sulgurpolt on natuke vaevarikas, ja väline juhtmevaba uksekell/ turvakaamera, mida on lihtne varastada, kuigi see sisaldab lihttekstina teie WiFi-parooli ja viimase 60 minuti jooksul salvestatud videomaterjali.

Oh, ja mõnel juhul on isegi turvalise välimusega välisuksel võtmed nagunii uksemati alla “peidetud”, mis on üsna selline olukord, millesse Schütz oma Android-telefonis sattus.

Keeruliste läbikäikude kaart

Kaasaegsed telefoni lukustusekraanid ei tähenda niivõrd telefoni lukustamist, kuivõrd rakenduste piiramist piiratud töörežiimidega.

Tavaliselt jätab see teile ja teie rakendustele juurdepääsu lukustuskuvale suurele hulgale erijuhtumi funktsioonidele, nagu kaamera aktiveerimine ilma lukust vabastamata või kureeritud teavitussõnumite või e-kirjade teemaridade kuvamine, kus igaüks võib neid ilma vaadata. pääsukood.

See, millega Schütz täiesti erakordses toimingute jadas kokku puutus, oli viga selles, mida žargoonis tuntakse lukustuskuvana. olekumasin.

Olekumasin on omamoodi graafik või kaart tingimuste kohta, milles programm võib olla, koos seaduslike viisidega, kuidas programm saab ühest olekust teise liikuda, näiteks võrguühenduse üleminek kuulamiselt ühendatud“ ja seejärel „ühendatud“ olekust „kinnitatud“ või telefoni ekraan lülitub „lukustatud“ olekust „sõrmejäljega avatav“ või „avatav, kuid ainult pääsukoodiga“.

Nagu võite ette kujutada, muutuvad keeruliste ülesannete olekumasinad ise kiiresti keeruliseks ja ühest osariigist teise ulatuvate seaduslike teede kaart võib lõppeda keerdkäikudega...

…ja mõnikord eksootilisi salakäike, mida keegi katsetamise ajal ei märganud.

Tõepoolest, Schütz suutis oma tahtmatu PUK-i avastuse muuta üldiseks lukustusekraani möödasõiduks, mille abil kõik, kes lukustatud Android-seadme kätte võtsid (või varastavad või muul viisil lühiajalise juurdepääsu omasid), said selle lukustamata olekusse meelitada, olles relvastatud vaid seadmega. uus SIM-kaart ja kirjaklamber.

Kui teid huvitab, eemaldage kirjaklamber juba telefonis oleva SIM-kaardi, et saaksite sisestada uue SIM-kaardi ja meelitada telefoni olekusse „Mul on turvakaalutlustel vaja küsida selle uue SIM-i PIN-koodi”. Schütz tunnistab, et kui ta Google’i esindustesse häkkimist demonstreerima läks, polnud kellelgi korralikku SIM-i väljaviskajat, mistõttu prooviti esmalt nõela, millega Schützil õnnestus end torgata, enne kui õnnestus laenatud kõrvarõngaga. Kahtlustame, et esmalt nõela sisse torkamine ei andnud tulemust (väljavisketihvti on raske pisikese otsaga lüüa), mistõttu otsustas ta riskida selle teraviku kasutamisega väljapoole, olles samas "väga ettevaatlik", muutes häkkimiskatse sõnasõnaliseks. häkkima. (Oleme seal olnud, seda teinud, end näpuotsas torganud.)

Süsteemi mängimine uue SIM-iga

Arvestades, et ründaja teab nii uue SIM-i PIN-koodi kui ka PUK-koodi, võib ta PIN-koodi sihilikult kolm korda valesti eksida ja seejärel kohe PUK-i õigeks saada, sundides sellega lukustuskuva olekumasina teadlikult ebaturvalisse seisundisse, mille Schütz kogemata avastas.

Õige ajastusega avastas Schütz, et ta ei saa mitte ainult sattuda sõrmejäljega avamise lehele, kui see ei pidanud ilmuma, vaid ka meelitada telefoni aktsepteerima edukat PUK-avamist kui signaali sõrmejäljeekraani sulgemiseks. ja "valideerida" kogu avamisprotsess nagu oleks ta sisestanud telefoni täieliku lukukoodi.

Avage ümbersõit!

Kahjuks kirjeldab suur osa Schützi artiklist aega, mis kulus Google'il haavatavusele reageerimiseks ja selle parandamiseks, isegi pärast seda, kui ettevõtte enda insenerid olid otsustanud, et viga on tõepoolest korratav ja kasutatav.

Nagu Schütz ise ütles:

See oli kõige mõjuvam haavatavus, mille ma siiani leidnud olen, ja see ületas minu jaoks piiri, kus ma tõesti hakkasin muretsema parandamise ajaskaala ja isegi selle pärast, et hoida seda "saladusena". Võib-olla reageerin ma üle, aga ma mõtlen, et mitte nii kaua aega tagasi võitles FBI Apple'iga peaaegu sama asja pärast.

Avalikustamise viivitused

Arvestades Google'i suhtumist vigade avalikustamisesse, on projekti Zero meeskond kurikuulsalt kindel vajaduses kehtestada ranged avalikustamisajad ja jää nende juurde, oleksite võinud eeldada, et ettevõte peab kinni oma 90 päeva pluss 14 erijuhtumite reeglitest.

Kuid Schützi sõnul ei saanud Google seda antud juhul hallata.

Ilmselt oli ta 2022. aasta oktoobris kokku leppinud kuupäeva, milleks ta kavatses vea avalikult avaldada, nagu ta on nüüdseks teinud, mis tundub olevat piisavalt aega 2022. aasta juunis leitud vea jaoks.

Kuid Google jättis selle oktoobri tähtaja vahele.

Vea plaaster, mille veanumber on CVE-2022-20465, ilmus lõpuks Androidi 2022. aasta novembri turvapaikades kuupäevaga 2022-11-05 koos Google'iga paranduse kirjeldamine näiteks: „Ära loobu klahvilukust pärast SIM-kaardi PUK-koodi avamist.”

Tehnilises mõttes oli viga teadaolevalt a võistluse seisund, kus operatsioonisüsteemi osa, mis jälgis PUK-koodi sisestamise protsessi, et jälgida küsimust „Kas SIM-kaardi avamine on nüüd ohutu?” osariik andis lõpuks edusignaali, mis ületas koodi, mis jälgis samaaegselt küsimust "kas kogu seadme lukust avamine on ohutu?"

Siiski on Schütz nüüd oluliselt rikkam tänu Google'i vigade pearaha väljamaksele (tema aruanne viitab sellele, et ta lootis 100,000 70,000 dollarit, kuid lõpuks pidi ta leppima XNUMX XNUMX dollariga).

Ja ta hoidis vea avalikustamisest pärast 15. oktoobri 2022. aasta tähtaega, nõustudes, et diskreetsus on mõnikord vapruse parem osa, öeldes:

[Olin] liiga hirmul, et reaalajas viga tegelikult välja panna ja kuna paranduseni oli aega vähem kui kuu, polnud see niikuinii seda väärt. Otsustasin paranduse ära oodata.

Mida teha?

Kontrollige, kas teie Android on ajakohane. Seaded > TURVALISUS > Turvavärskendus > Otsi uuendusi.

Pange tähele, et kui me külastasime Turvavärskendus ekraan, olles meie Pixeli telefoni mõnda aega kasutanud, kuulutas Android julgelt Teie süsteem on ajakohane, mis näitab, et see oli umbes minut varem automaatselt kontrollitud, kuid annab meile siiski teada, et oleme võrgus October 5, 2022 turvavärskendus.

Sundisime uue värskenduse käsitsi kontrollima ja meile öeldi kohe Süsteemi värskenduse ettevalmistamine…, millele järgneb lühike allalaadimine, pikk ettevalmistusetapp ja seejärel taaskäivitamise taotlus.

Pärast taaskäivitamist olime jõudnud November 5, 2022 plaastri tase.

Läksime siis tagasi ja tegime veel ühe Otsi uuendusi kinnitamaks, et parandusi pole veel pooleli.

---

Me kasutasime Seaded > TURVALISUS > Turvavärskendus jõuga allalaadimise lehele pääsemiseks:

---

Teatatud kuupäev tundus vale, nii et sundisime Androidi seda tegema Otsi uuendusi igatahes:

---

Tõepoolest, installimiseks tuli värskendus:

---

Ootamise asemel kasutasime Kokkuvõte et kohe jätkata:

---

Järgnes pikk värskendusprotsess:

---

Tegime veel ühe Otsi uuendusi kinnitamaks, et me kohal olime:

---