Ocolire periculoasă a ecranului de blocare prin schimbarea SIM – actualizați Android acum!

Un vânător de recompense numit David Schütz tocmai a publicat un raport detaliat descriind modul în care a încrucișat săbiile cu Google timp de câteva luni în ceea ce el considera o gaură periculoasă în securitatea Android.

Potrivit lui Schütz, el s-a împiedicat de o eroare totală de ocolire a ecranului de blocare Android, în totalitate accidentală, în iunie 2022, în condiții de viață reale care s-ar fi putut întâmpla cu ușurință oricui.

Cu alte cuvinte, era rezonabil să presupunem că alți oameni ar putea afla despre defect fără a căuta în mod deliberat erori, făcând descoperirea și dezvăluirea sa publică (sau abuzul privat) ca o gaură de zi zero mult mai probabilă decât de obicei.

Din păcate, nu a fost corectat până în noiembrie 2022, motiv pentru care a dezvăluit-o abia acum.

O întrerupere fortuită a bateriei

Mai simplu spus, a găsit bug-ul pentru că a uitat să-și închidă telefonul sau să-și încarce telefonul înainte de a porni într-o călătorie lungă, lăsând dispozitivul să rămână fără suc neobservat în timp ce era pe drum.

Potrivit lui Schütz, se grăbea să trimită niște mesaje după ce a ajuns acasă (bănuim că fusese într-un avion) ​​cu puțina putere rămasă în baterie...

... când telefonul a murit.

Am fost cu toții acolo, căutând un încărcător sau o baterie de rezervă pentru a reporni telefonul pentru a le anunța oamenilor că am sosit în siguranță, că așteptăm la preluarea bagajelor, am ajuns la gară, ne așteptăm să ajungem acasă în 45 de minute, ne-ar putea opri la magazine dacă cineva are nevoie urgentă de ceva sau orice avem de spus.

Și cu toții ne-am luptat cu parolele și codurile PIN atunci când ne grăbim, mai ales dacă sunt coduri pe care le folosim rar și nu le-am dezvoltat niciodată „memorie musculară” pentru a le introduce.

În cazul lui Schütz, codul PIN umil de pe cartela lui SIM a fost cel care l-a încurcat și, deoarece codurile PIN SIM pot fi de până la patru cifre, sunt protejate de un blocare hardware care vă limitează la cel mult trei presupuneri. (Am fost acolo, am făcut asta, ne-am închis.)

După aceea, trebuie să introduceți un „PIN principal” de 10 cifre cunoscut sub numele de PUK, prescurtare pentru cheie personală de deblocare, care este de obicei imprimat în interiorul ambalajului în care este vândut SIM-ul, ceea ce îl face în mare măsură rezistent la manipulare.

Și pentru a se proteja împotriva atacurilor de ghicire PUK, SIM-ul se prăjește automat după 10 încercări greșite și trebuie înlocuit, ceea ce înseamnă de obicei să te adresezi unui magazin de telefoane mobile cu identificare.

Ce am făcut cu acel ambalaj?

Din fericire, pentru că nu ar fi găsit bug-ul fără el, Schütz a găsit ambalajul original al SIM-ului ascuns undeva într-un dulap, a zgâriat banda de protecție care ascunde PUK-ul și a introdus-o.

În acest moment, având în vedere că era în proces de pornire a telefonului după ce acesta a rămas fără putere, ar fi trebuit să vadă ecranul de blocare al telefonului cerându-i să introducă codul de deblocare al telefonului...

… dar, în schimb, și-a dat seama că era la tipul greșit de ecran de blocare, pentru că îi oferea șansa de a debloca dispozitivul folosind doar amprenta sa.

Acest lucru ar trebui să se întâmple numai dacă telefonul se blochează în timpul utilizării obișnuite și nu ar trebui să se întâmple după o oprire și repornire, atunci când o reautentificare completă a codului de acces (sau unul dintre acele „coduri de model” cu glisare pentru a debloca ) ar trebui puse în aplicare.

Există într-adevăr o „blocare” în ecranul tău de blocare?

După cum probabil știți din multe ori ne-am scris despre erori de blocare a ecranului de-a lungul anilor pe Naked Security, problema cu cuvântul „blocare” în ecranul de blocare este că pur și simplu nu este o metaforă bună pentru a reprezenta cât de complex este codul care gestionează procesul de „blocare” și „deblocare” telefoanelor moderne.

Un ecran de blocare mobil modern este un pic asemănător cu o ușă de intrare a unei case care are montat un șurub de blocare de calitate decentă...

…dar are, de asemenea, o cutie poștală (slot pentru poștă), panouri de sticlă pentru a lăsa să pătrundă lumina, o clapă pentru pisică, un încuietoare cu arc compatibil, pe care ați învățat să vă bazați, deoarece șurubul este puțin o bătaie de cap și o sonerie externă fără fir/ cameră de securitate care este ușor de furat, chiar dacă conține parola dvs. Wi-Fi în text simplu și ultimele 60 de minute de înregistrare video pe care le-a înregistrat.

A, și, în unele cazuri, chiar și o ușă din față cu aspect sigur va avea cheile „ascunse” sub preș, care este aproape situația în care s-a găsit Schütz pe telefonul său Android.

O hartă a pasajelor întortocheate

Ecranele moderne de blocare ale telefonului nu se referă atât la blocarea telefonului, cât la restricționarea aplicațiilor la moduri limitate de operare.

Acest lucru vă lasă, de obicei, dvs. și aplicațiilor dvs., cu acces pe ecranul de blocare la o gamă largă de funcții pentru „cazuri speciale”, cum ar fi activarea camerei fără deblocare sau afișarea unui set de mesaje de notificări sau linii de subiect ale e-mailului, unde oricine le-ar putea vedea fără a le debloca. codul de acces.

Ceea ce a întâlnit Schütz, într-o secvență de operații perfect neexcepțională, a fost o greșeală în ceea ce este cunoscut în jargon drept ecranul de blocare. mașină de stat.

O mașină de stări este un fel de grafic, sau hartă, a condițiilor în care se poate afla un program, împreună cu modalitățile legale prin care programul se poate muta dintr-o stare în alta, cum ar fi o conexiune de rețea care trece de la „ascultare” la „ conectat”, apoi de la „conectat” la „verificat”, sau un ecran de telefon care trece de la „blocat” fie la „deblocat cu amprentă” fie la „deblocat, dar numai cu o parolă”.

După cum vă puteți imagina, mașinile de stat pentru sarcini complexe se complică rapid de la sine, iar harta diferitelor căi legale de la un stat la altul poate ajunge plină de întorsături și întorsături...

… și, uneori, pasaje secrete exotice pe care nimeni nu le-a observat în timpul testării.

Într-adevăr, Schütz a reușit să-și transforme descoperirea PUK din neatenție într-o ocolire generică a ecranului de blocare prin care oricine a ridicat (sau a furat, sau a avut în alt mod acces scurt la) un dispozitiv Android blocat îl putea păcăli în starea deblocat, înarmat cu nimic mai mult decât un cartelă SIM nouă și o agrafă de hârtie.

În cazul în care vă întrebați, agrafa este pentru a scoate SIM-ul deja în telefon, astfel încât să puteți introduce noul SIM și să păcăliți telefonul în starea „Trebuie să solicit PIN-ul pentru acest nou SIM din motive de securitate”. Schütz recunoaște că, atunci când a mers la birourile Google pentru a demonstra hack-ul, nimeni nu avea un ejector SIM adecvat, așa că au încercat mai întâi un ac, cu care Schütz a reușit să se înjunghie, înainte de a reuși cu un cercel împrumutat. Bănuim că nu a funcționat mai întâi introducerea acului în vârf (este greu să lovești știftul ejectorului cu un vârf mic), așa că a decis să riște să-l folosească spre exterior, „fiind cu adevărat atent”, transformând astfel o încercare de hacking într-un literal literal. hack. (Am fost acolo, am făcut asta, ne-am băgat în vârful degetului.)

Jocuri sistemul cu un SIM nou

Având în vedere că atacatorul cunoaște atât PIN-ul, cât și PUK-ul noului SIM, poate greși în mod deliberat PIN-ul de trei ori și apoi poate corecta imediat PUK-ul, forțând astfel în mod deliberat mașina de stare a ecranului de blocare în starea nesigură pe care Schütz a descoperit-o accidental.

La momentul potrivit, Schütz a descoperit că nu numai că poate ajunge pe pagina de deblocare cu amprentă atunci când nu trebuia să apară, ci și să păcălească telefonul să accepte deblocarea cu succes a PUK-ului ca un semnal pentru a închide ecranul cu amprentă. și „validați” întregul proces de deblocare de parcă ar fi tastat codul complet de blocare al telefonului.

Deblocați bypass-ul!

Din nefericire, o mare parte din articolul lui Schütz descrie timpul pe care Google a avut nevoie pentru a reacționa și pentru a remedia această vulnerabilitate, chiar și după ce inginerii companiei au decis că eroarea este într-adevăr repetabilă și exploatabilă.

După cum a spus însuși Schütz:

Aceasta a fost cea mai puternică vulnerabilitate pe care am găsit-o până acum și a depășit o linie pentru mine în care am început cu adevărat să-mi fac griji cu privire la cronologia remedierii și chiar să o păstrez eu ca „secret”. S-ar putea să reacționez exagerat, dar vreau să spun că nu cu mult timp în urmă, FBI-ul se lupta cu Apple pentru aproape același lucru.

Întârzieri de dezvăluire

Având în vedere atitudinea Google față de dezvăluirile de erori, cu propria sa echipă Project Zero notoriu fermă cu privire la necesitatea de a stabili timpi stricte de divulgare și ține-te de ei, s-ar putea să vă fi așteptat ca compania să respecte regulile de 90 de zile-plus-14-extra-în cazuri speciale.

Dar, potrivit lui Schütz, Google nu a putut gestiona acest lucru în acest caz.

Aparent, el a convenit asupra unei date în octombrie 2022 până la care plănuia să dezvăluie public bug-ul, așa cum a făcut-o acum, ceea ce pare a fi suficient timp pentru o eroare descoperită în iunie 2022.

Dar Google a ratat termenul limită din octombrie.

Patch-ul pentru defecțiune, desemnat cu numărul de eroare CVE-2022-20465, a apărut în sfârșit în corecțiile de securitate Android din noiembrie 2022, datate 2022-11-05, cu Google descriind remedierea ca: „Nu închideți blocarea tastaturii după deblocarea SIM PUK.”

În termeni tehnici, bug-ul a fost ceea ce se știe a starea cursei, unde partea sistemului de operare care urmărea procesul de introducere a PUK pentru a ține evidența „este sigur să deblochezi SIM-ul acum?” starea a ajuns să producă un semnal de succes care a depășit codul care urmărea simultan „este sigur să deblochezi întregul dispozitiv?”

Totuși, Schütz este acum semnificativ mai bogat datorită plății recompensei de către Google (raportul său sugerează că spera la 100,000 de dolari, dar a trebuit să se mulțumească cu 70,000 de dolari în cele din urmă).

Și a amânat să dezvăluie eroarea după termenul limită de 15 octombrie 2022, acceptând că discreția este partea uneori cea mai bună a curajului, spunând:

Eram prea speriat ca să sting bug-ul live și, din moment ce remedierea era la mai puțin de o lună, oricum nu a meritat cu adevărat. Am decis să aștept remedierea.

Ce să fac?

Verificați dacă Android-ul dvs. este actualizat: setări cont > Securitate > Actualizare de securitate > Verifica pentru actualizare.

Rețineți că atunci când am vizitat Actualizare de securitate ecran, nefolosind telefonul Pixel de ceva vreme, a declarat Android cu îndrăzneală Sistemul dvs. este actualizat, arătând că s-a verificat automat cu un minut și ceva mai devreme, dar tot ne spune că suntem pe October 5, 2022 actualizare de securitate.

Am forțat manual o nouă verificare a actualizării și ni s-a spus imediat Se pregătește actualizarea sistemului..., urmată de o scurtă descărcare, o etapă pregătitoare lungă și apoi o solicitare de repornire.

După repornire, am ajuns la November 5, 2022 nivelul patch-ului.

Ne-am întors apoi și am mai făcut una Verifica pentru actualizare pentru a confirma că nu existau remedieri încă nerezolvate.

---

Noi am folosit setări cont > Securitate > Actualizare de securitate pentru a ajunge la pagina de descărcare forțată:

---

Data raportată părea greșită, așa că am forțat Android să o facă Verifica pentru actualizare oricum:

---

Într-adevăr, a fost o actualizare de instalat:

---

În loc să așteptăm, am folosit Relua a proceda imediat:

---

A urmat un proces îndelungat de actualizare:

---

Am mai făcut una Verifica pentru actualizare pentru a confirma că am fost acolo:

---