Veszélyes SIM-csere zárolási képernyő megkerülése – frissítse az Androidot most!

A Schütz Dávid nevű bogárfejvadász most publikálta a részletes jelentés leírja, hogyan ütött kardot a Google-lal több hónapon át az általa veszélyesnek tartott Android biztonsági résen.

Schütz elmondása szerint 2022 júniusában teljesen véletlenül botlott bele egy teljes Android lockscreen bypass hibába, valós körülmények között, ami könnyen előfordulhatott volna bárkivel.

Más szavakkal, ésszerű volt azt feltételezni, hogy mások is tudomást szerezhetnek a hibáról anélkül, hogy szándékosan hibákat keresnének, így a szokásosnál sokkal valószínűbb, hogy felfedezik és nyilvánosságra hozzák (vagy magáncélú visszaélést), mint nulladik napi lyukat.

Sajnos csak 2022 novemberében javították ki, ezért csak most hozta nyilvánosságra.

Borzalmas akkumulátor leállás

Egyszerűen fogalmazva, azért találta meg a hibát, mert elfelejtette kikapcsolni vagy feltölteni a telefonját, mielőtt hosszabb útra indult, így a készülék észrevétlenül kifogyott, miközben úton volt.

Schütz elmondása szerint a hazaérkezés után sietett üzeneteket küldeni (azt sejtjük, hogy repülőn ült), miközben az akkumulátorban még maradt egy kis energia…

…amikor a telefon meghalt.

Mindannyian ott voltunk, töltőt vagy tartalék akkumulátort keresve, hogy újraindíthassuk a telefont, hogy tudathassuk az emberekkel, hogy biztonságban megérkeztünk, várakoztunk a poggyászátvételnél, elértük a vasútállomást, és várhatóan 45 percen belül hazaérünk. Megállhat a boltokban, ha valakinek sürgősen szüksége van valamire, vagy bármit, amit mondanunk kell.

Mindannyian küszködtünk a jelszavakkal és a PIN-kódokkal, amikor rohanunk, különösen, ha olyan kódokról van szó, amelyeket ritkán használunk, és soha nem fejlesztettek ki „izommemóriát” a beíráshoz.

Schütz esetében a SIM-kártyáján lévő szerény PIN-kód döbbentette meg, és mivel a SIM-kódok akár négy számjegyből is állhatnak, hardveres zár védi őket, amely legfeljebb három tippelésre korlátozza. (Ott voltunk, megtettük, kizártuk magunkat.)

Ezt követően meg kell adnia egy 10 számjegyű „mester PIN-kódot”, amely PUK-ként ismert, rövidítése személyes feloldó kulcs, amelyet általában a SIM-kártya csomagolásába nyomtatnak, ami nagymértékben hamisításbiztossá teszi.

A PUK-kitaláló támadások elleni védelem érdekében a SIM 10 hibás próbálkozás után automatikusan megsül, és ki kell cserélni, ami általában azt jelenti, hogy be kell menni egy mobiltelefon-boltba azonosítással.

Mit csináltam ezzel a csomagolással?

Szerencsére, mivel enélkül nem találta volna meg a hibát, Schütz megkereste az eredeti SIM-csomagolást valahol egy szekrényben, lekaparta a PUK-kódot eltakaró védőcsíkot, és begépelte.

Ezen a ponton, tekintettel arra, hogy éppen elindította a telefont, miután az lemerült, látnia kellett volna a telefon lezárási képernyőjét, amely megköveteli, hogy írja be a telefon feloldó kódját…

…de ehelyett rájött, hogy az rossz típusú lezárási képernyőn, mert lehetőséget kínált neki, hogy csak az ujjlenyomatával oldja fel az eszközt.

Ennek csak akkor kellene megtörténnie, ha a telefon rendszeres használat közben leblokkol, és ez nem történhet meg ki- és újraindítás után, amikor a teljes jelszó-újrahitelesítés (vagy az egyik legyintéssel feloldható „mintakód” ) érvényesíteni kell.

Valóban van „zár” a lezárási képernyőn?

Amint azt valószínűleg a sokszor voltunk írt róla lockscreen hibák az évek alatt A Naked Security esetében az a probléma a zárolási képernyőn megjelenő „zár” szóval, hogy ez egyszerűen nem jó metafora annak ábrázolására, hogy mennyire bonyolult a modern telefonok „zárolásának” és „feloldásának” folyamatát kezelő kód.

A modern mobil zár képernyője kicsit olyan, mint egy ház bejárati ajtaja, amelyre megfelelő minőségű reteszzár van felszerelve…

...de van egy levélszekrény (postanyílás), az üveglapok, amelyek átengedik a fényt, egy macskaajtó, egy lehajtható rugós zár, amelyre megtanult támaszkodni, mert a retesz egy kicsit gondot okoz, és egy külső vezeték nélküli ajtócsengő/ egy biztonsági kamera, amelyet könnyű ellopni, még akkor is, ha az Ön Wi-Fi jelszavát egyszerű szövegként tartalmazza, és az utolsó 60 perces videófelvételt.

Ja, és bizonyos esetekben még egy biztonságosnak tűnő bejárati ajtónál is a lábtörlő alatt „rejtették” el a kulcsokat, nagyjából ez a helyzet, amibe Schütz került Androidos telefonján.

Kanyargós átjárók térképe

A modern telefonzár képernyők nem annyira a telefon zárolásáról szólnak, mint inkább az alkalmazások korlátozott működési módokra való korlátozásáról.

Ez jellemzően Ön és alkalmazásai számára biztosít hozzáférést a lezárási képernyőhöz számos „különleges eset” funkcióhoz, mint például a kamera aktiválása feloldás nélkül, vagy értesítési üzenetek vagy e-mail tárgysorok összeválogatott készletének felbukkanása, ahol bárki láthatja őket anélkül. a jelszót.

Amire Schütz a műveletek tökéletesen kifogásolhatatlan sorozata során rábukkant, az a zsargonban lezárt képernyőként ismert hiba volt. állapotgép.

Az állapotgép egyfajta grafikon vagy térkép azokról a feltételekről, amelyekben egy program lehet, valamint a program egyik állapotból a másikba való átlépésének legális módjaival együtt, például a hálózati kapcsolat „hallgatásról” „hallgatásról” csatlakoztatva”, majd a „csatlakozott” állapotból az „ellenőrzött” állapotba, vagy a telefon képernyője „zárolt” állapotból „ujjlenyomattal feloldható” vagy „feloldható, de csak jelszóval” állapotra vált.

Képzelheti, hogy az összetett feladatokat ellátó állapotgépek maguk is gyorsan bonyolulttá válnak, és az egyik államból a másikba vezető különböző jogi utak térképe tele lehet fordulatokkal és fordulatokkal…

…és néha egzotikus titkos átjárók, amelyeket senki sem vett észre a tesztelés során.

Valójában Schütz képes volt véletlen PUK-felfedezését egy általános lezárási képernyő megkerülésére fordítani, amellyel bárki, aki felkapott (vagy ellopott, vagy más módon rövid ideig hozzáfért) egy lezárt Android-eszközt, becsaphatta azt a feloldott állapotba, és csak egy új SIM-kártya és egy gemkapocs.

Ha kíváncsi, a gémkapocs az, hogy kivegye a már a telefonban lévő SIM-kártyát, így behelyezheti az új SIM-kártyát, és becsaphatja a telefont „Biztonsági okokból PIN-kódot kell kérnem ehhez az új SIM-hez” állapotba. Schütz bevallja, hogy amikor a Google irodáiba ment bemutatni a feltörést, senkinek nem volt megfelelő SIM-kidobója, ezért először egy tűvel próbálkoztak, amellyel Schütznek sikerült megszúrnia magát, majd sikerült egy kölcsön fülbevalóval. Gyanítjuk, hogy a tű első beszúrása nem működött (a kivetőtüskét nehéz egy apró heggyel eltalálni), ezért úgy döntött, hogy megkockáztatja, hogy kifelé használja, miközben „nagyon óvatos volt”, így a hackelési kísérletet szó szerint átváltoztatja. csapkod. (Ott voltunk, megtettük, az ujjbegyébe nyúltunk.)

A rendszer játéka új SIM-kártyával

Tekintettel arra, hogy a támadó ismeri az új SIM PIN-kódját és PUK-kódját is, szándékosan háromszor is elhibázhatja a PIN-kódot, majd azonnal beállíthatja a PUK-kódot, így szándékosan kényszeríti a zárképernyő állapotú gépét a Schütz által véletlenül felfedezett bizonytalan állapotba.

Megfelelő időzítéssel Schütz úgy találta, hogy nemcsak az ujjlenyomat-feloldó oldalon tud landolni, amikor annak nem kellett volna megjelennie, hanem arra is ráveheti a telefont, hogy elfogadja a sikeres PUK-feloldást, mint az ujjlenyomat-képernyő kikapcsolásának jelét. és „validálja” a teljes feloldási folyamatot mintha beírta volna a telefon teljes zárkódját.

A bypass feloldása!

Sajnos Schütz cikkének nagy része leírja, hogy a Google-nak mennyi időbe telt reagálni és kijavítani ezt a sérülékenységet, még akkor is, ha a cég saját mérnökei úgy döntöttek, hogy a hiba valóban megismételhető és kihasználható.

Ahogy maga Schütz fogalmazott:

Ez volt a leghatásosabb sebezhetőség, amit eddig találtam, és átlépett számomra egy határt, ahol már tényleg elkezdtem aggódni a javítási idővonal miatt, sőt, még csak azért is, hogy „titokban” tartsam. Lehet, hogy túlreagálom, de úgy értem, nem is olyan régen az FBI szinte ugyanazért harcolt az Apple-lel.

Közzétételi késések

Tekintettel a Google-nak a hibák feltárásához való hozzáállására, saját Project Zero csapata köztudottan határozottan kitart amellett, hogy szigorú közzétételi időket kell meghatározni és ragaszkodj hozzájuk, azt várhatta volna, hogy a vállalat betartsa a 90 nap plusz 14 extra különleges esetekre vonatkozó szabályait.

Schütz szerint azonban a Google ebben az esetben nem tudta kezelni.

Nyilvánvalóan 2022 októberében megállapodott egy időpontban, amikorra azt tervezi, hogy nyilvánosságra hozza a hibát, ahogy most meg is tette, ami bőven elég időnek tűnik egy 2022 júniusában felfedezett hibára.

A Google azonban elmulasztotta ezt az októberi határidőt.

A hiba javítása, a CVE-2022-20465 hibaszám, végül megjelent az Android 2022. novemberi biztonsági javításaiban, 2022. november 11. dátummal a Google-nál. a javítás leírása például: „Ne kapcsolja be a billentyűzárat a SIM PUK-kód feloldása után.”

Technikai értelemben a hiba az volt, amit a versenyfeltétel, ahol az operációs rendszer azon része, amely a PUK beviteli folyamatot figyelte, hogy nyomon kövesse a „Biztonságos a SIM feloldása most?” állam sikerjelzést adott, amely felülmúlta a kódot, amely egyidejűleg követte a „biztonságos-e a teljes eszköz zárolásának feloldása?”

Ennek ellenére Schütz mostanra lényegesen gazdagabb a Google hibajavító kifizetésének köszönhetően (jelentése szerint 100,000 70,000 dollárban reménykedett, de végül XNUMX XNUMX dollárral kellett megelégednie).

És a 15. október 2022-i határidő után elzárkózott a hiba feltárásától, és elfogadta, hogy a diszkréció a bátorság néha jobb része, és ezt mondta:

Túlságosan féltem, hogy ténylegesen kioltsam az élő hibát, és mivel a javítás kevesebb mint egy hónapra volt hátra, amúgy sem igazán érte meg. Úgy döntöttem, megvárom a javítást.

Mit kell tenni?

Ellenőrizze, hogy Android-eszköze naprakész: beállítások > Biztonság > Biztonsági frissítés > Ellenőrizze a frissítést.

Vegye figyelembe, hogy amikor meglátogattuk a Biztonsági frissítés képernyőt, miután egy ideig nem használtuk Pixel telefonunkat, az Android bátran hirdette Rendszere naprakész, amely azt mutatja, hogy körülbelül egy perccel korábban automatikusan ellenőrizte, de továbbra is jelzi, hogy a készüléken vagyunk October 5, 2022 biztonsági frissítés.

Kényszerítettünk egy új frissítési ellenőrzést manuálisan, és azonnal értesítettük Rendszerfrissítés előkészítése…, majd egy rövid letöltés, egy hosszas előkészítő szakasz, majd egy újraindítási kérés következik.

Újraindítás után elértük a November 5, 2022 patch szinten.

Aztán visszamentünk és csináltunk még egyet Ellenőrizze a frissítést annak megerősítésére, hogy nincs még függőben lévő javítás.

---

Használtuk beállítások > Biztonság > Biztonsági frissítés az erőltetett letöltés oldalának eléréséhez:

---

A jelentett dátum hibásnak tűnt, ezért rákényszerítettük az Androidot Ellenőrizze a frissítést akárhogyan is:

---

Valóban volt egy frissítést telepíteni:

---

Várakozás helyett használtuk Folytatás azonnal folytatni:

---

Hosszú frissítési folyamat következett:

---

Csináltunk még egyet Ellenőrizze a frissítést annak megerősítésére, hogy ott voltunk:

---