Ascunderea accesului rădăcină în Magisk este pe cale să devină mult mai greu de făcut datorită unei schimbări recente în SafetyNet care aduce atestarea hardware.
În martie, câțiva utilizatori cu Magisk instalat observat că dispozitivele lor nu eșau atestarea SafetyNet. Această știre a fost îngrijorătoare pentru comunitatea de la XDA, deoarece înseamnă că multe aplicații bancare/financiare esențiale și jocuri populare precum Pokémon Go și Fate/Grand Order refuzau să ruleze pe dispozitive rootate. De ceva timp, s-a părut că restricțiile înăsprite din SafetyNet au fost retrase, doar pentru a fi lansate din nou pentru câțiva utilizatori în ultimele câteva săptămâni. Cu toate acestea, Google a confirmat în liniște la începutul lunii mai că testează atestarea susținută de hardware pentru Răspunsurile SafetyNet, ceea ce a făcut ca Magisk să nu poată ascunde din nou starea de deblocare a bootloader-ului Martie. Dacă această modificare va fi lansată pe scară largă, va însemna că utilizatorii vor trebui să aleagă între a avea acces la ROM-uri rădăcină/personalizate/kernel-uri/etc. sau aplicațiile și jocurile lor bancare preferate. Una dintre cele mai mari atracții ale Android pentru utilizatorii puternici ar putea dispărea în curând.
Pentru a recapitula această serie de evenimente, ar trebui să vorbim mai întâi despre SafetyNet în sine. SafetyNet este un set de API-uri din Serviciile Google Play. API-ul SafetyNet Attestation este unul dintre aceste API-uri și poate fi apelat de aplicații terțe pentru a verifica dacă mediul software al dispozitivului a fost modificat în vreun fel. API-ul verifică diverse lucruri, cum ar fi semne de binare de superutilizator, starea de deblocare a încărcării de boot și multe altele. Când rootați un dispozitiv cu Magisk, acesta „[creează] un „mediu sigur” izolat pentru procesul de detectare [SafetyNet] și trece prin API-ul Google pentru a crea un legitim Rezultat SafetyNet care nu reflectă starea reală a dispozitivului”, conform XDA Senior Recognized Developer topjohnwu. Acest lucru permite utilizatorului să își rooteze telefonul, asigurându-se în același timp că API-ul returnează întotdeauna „false” pentru orice verificări de deblocare a bootloader-ului. Această metodă de ocolire a detectării deblocării bootloader-ului SafetyNet a funcționat pentru Magisk în ultimele câteva ani, dar asta doar pentru că Google a renunțat la verificarea integrității imaginii de boot folosind hardware atestare. În martie, se părea că Google începea în sfârșit să folosească atestarea hardware în SafetyNet pentru a verifica imaginea de boot, dar nu am primit niciodată o declarație oficială de la Google care să confirme schimbarea și doar câțiva utilizatori au fost afectat. După cum a observat un membru senior XDA Displax, cu toate acestea, Google a confirmat pe 5 mai 2020 că răspunsurile SafetyNet Attestation API de la unele dispozitive includ acum verificări susținute de hardware.
În Grupul Google pentru „Clienți API SafetyNet”, Google a detaliat o nouă funcție pentru API-ul de atestare: evaluationType. Răspunsul JSON Web Signature (JWS) de la unele dispozitive va avea un câmp numit „evaluationType” care „va oferi dezvoltatorilor informații în tipurile de semnale/măsurători care au contribuit la fiecare răspuns individual SafetyNet Attestation API.” Unul dintre indicatoarele acceptate în acest câmp este „HARDWARE_BACKED”, ceea ce indică faptul că API-ul „[a folosit] caracteristicile de securitate disponibile cu suport hardware ale dispozitivului la distanță (de exemplu. atestarea cheii cu suport hardware) pentru a influența evaluarea [sa].” Google spune că „în prezent evaluează și ajustează criteriile de eligibilitate pentru dispozitivele în care ne vom baza pe suport hardware funcții de securitate.” Ceea ce înseamnă că, pe unele dispozitive, serviciile Google Play utilizează acum o atestare susținută de hardware pentru a detecta că software-ul dispozitivului nu a fost manipulat. Google nu a documentat oficial această schimbare în afara anunțului din Grupul Google, așa că unii dezvoltatori care folosesc SafetyNet pot nu fiți conștienți de această modificare (și, prin urmare, nu verificați încă câmpul „HARDWARE_BACKED” din răspunsurile JWS.) Cu toate acestea, pentru acele aplicații care verifică acest câmp, acum nu există nicio modalitate de a ascunde accesul root de la aceștia, cu condiția ca dispozitivul dvs. să facă parte din testul conform căruia Google este alergare.
Potrivit topjohnwu, atestarea susținută de hardware înseamnă că serviciile Google Play acum „[trimite] un certificat de depozit de chei nemodificat către serverele SafetyNet, [verifică] legitimitatea acestuia și [verifică] datele de extensie a certificatului pentru a ști dacă dispozitivul dvs. [are] pornit verificat activat (starea încărcător de pornire).” Deoarece cheile private din care sunt derivate certificatele depozitului de chei sunt susținute de mediul izolat securizat al telefonului, recuperarea acestora ar implica înfrângerea securității mediului de execuție de încredere (TEE) al telefonului sau a securității hardware dedicate modul (HSM). Dacă cineva ar fi putut într-un fel să scurgă o cheie privată, cheile ar fi revocate rapid odată ce Google a aflat. Google oferă recompense de sute de mii de dolari pentru orice vulnerabilități critice de securitate care afectează TEE în telefoanele Pixel, ceea ce arată că este incredibil de puțin probabil ca aceasta să fie o cale potențială pentru a ocoli detectarea deblocării bootloader-ului oricum.
O altă modalitate potențială prin care Magisk ar putea continua să falsifice starea de deblocare a încărcării de pornire este prin modificarea codului de la parte client al SafetyNet pentru a utiliza întotdeauna evaluarea BASIC. La fel de note topjohnwu, totuși, acest lucru ar necesita injectarea unui cod personalizat în Serviciile Google Play printr-un cadru de conectare precum Xposed Framework. Acest lucru nu este doar dificil de făcut, deoarece Serviciile Google Play sunt foarte obstrucționate, dar este și imposibil de ascuns, deoarece „o analiză a spațiului de memorie va dezvălui manipularea codului foarte mult. În plus, acest lucru ar funcționa numai dacă serverele Google continuă să accepte evaluări BASIC și dacă evaluările HARDWARE_BACKED nu sunt aplicate pe dispozitivele care acceptă lor. (Răspunsurile SafetyNet „[vin] de la serverele Google și sunt semnate cu cheia privată Google”, conform topjohnwu, astfel încât răspunsurile reale nu pot fi falsificate.)
De la Android 7 Nougat, Google a cerut ca toate dispozitivele să aibă un mediu izolat securizat, ceea ce înseamnă că această modificare a modului în care SafetyNet verifică deblocarea bootloader-ului va afecta majoritatea dispozitivelor care nu sunt Acolo. Deoarece dispozitivele mai vechi fără un mediu securizat izolat, evident, nu pot efectua atestarea cu suport hardware, Magisk va putea în continuare să ascundă accesul root pe acele dispozitive. Dar dacă această schimbare se va desfășura pe scară largă, toți ceilalți vor trebui să facă o alegere grea între accesul root și aplicațiile bancare.
Din păcate, probabil că există o mulțime de aplicații care folosesc verificări SafetyNet atunci când nu au nevoie. Un exemplu citat de topjohnwu este aplicația oficială McDonald's, care aparent refuză să ruleze pe un dispozitiv deblocat cu bootloader. Pe Twitter, topjohnwu evoca aplicațiile care folosesc excesiv API-ul ca creând un mediu ostil pentru utilizatorii cu putere. Dezvoltator recunoscut XDA Quinny899 se alătură cu o anecdotă despre modul în care echipa sa a luat în considerare utilizarea SafetyNet pentru a verifica starea securității dispozitivului. În cele din urmă, au decis să nu treacă prin asta, deoarece aplicația echipei sale criptează toate datele sensibile cu care lucrează. SafetyNet, susține el, nu ar trebui utilizat în locul practicilor adecvate de securitate și manipulare a datelor, în special atunci când se ia în considerare posibilitatea de exploatare a superutilizatorului.
Pentru mai multe informații despre modul în care noua modificare SafetyNet afectează Magisk, consultați topjohnwu's Întrebări frecvente excelente pe Twitter. Dacă doriți doar să verificați dacă dispozitivul dvs. face parte din noul test SafetyNet al Google, atunci puteți urmări acest ghid de XDA Senior Member Displax sau descărcați cea mai recentă versiune Magisk Manager.
Acest articol a fost actualizat la 10:46 AM EST pe 30 iunie 2020, pentru a corecta faptul că Google plătește recompense numai pentru vulnerabilitățile TEE găsite în telefoanele Pixel. În plus, au fost adăugate detalii cu privire la cea mai recentă versiune Magisk Manager, care arată acum câmpul evaluationType în verificatorul SafetyNet încorporat.