Dezvoltatorul Magisk a descoperit că este posibil ca Google să fi început să utilizeze verificări hardware pentru a determina dacă un dispozitiv a fost deblocat bootloader.
Dezvoltator recunoscut XDA topjohnwuProiectul „Magisk” al lui a devenit în esență sinonim cu „rădăcină” în comunitatea Android. Unul dintre principalele motive pentru care este atât de popular este că poate ascunde faptul că utilizatorul și-a modificat dispozitivul. Cu toate acestea, este posibil ca Google să reprime capacitatea Magisk de a ascunde starea de deblocare a bootloaderului din aplicații.
Pentru a vă roota telefonul, de obicei trebuie să deblocați bootloader-ul, care vă permite să flashați imaginile de boot modificate. Acest lucru este necesar deoarece Magisk modifică imaginea de pornire pentru a falsifica starea încărcării de pornire și/sau verificările de stare a pornirii verificate. API-ul Google SafetyNet Attestation, care face parte din Serviciile Google Play, este folosit pentru a spune unei aplicații dacă rulează pe un dispozitiv manipulat; dacă API-ul SafetyNet detectează că bootloader-ul a fost deblocat, atunci va returna o stare de eșec pentru verificarea „Integritate de bază”. Dispozitivele care eșuează această verificare pot fi apoi blocate din aplicațiile care utilizează API-ul SafetyNet pentru a determina integritatea dispozitivului; astfel de aplicații includ de obicei aplicații bancare, aplicații de plată (cum ar fi Google Pay) și multe jocuri online (cum ar fi Pokémon Go). Cu toate acestea, deoarece API-ul SafetyNet a folosit până acum doar verificări software pentru a determina dacă dispozitivul a fost modificat, Magisk poate pur și simplu falsifica bootloader și/sau Verified Boot status deoarece este instalat la un nivel inferior și cu privilegii mai mari decât serviciile Google Play și alt spațiu de utilizator aplicatii. După cum explică topjohnwu, MagiskHide „[creează] un „mediu sigur” izolat pentru procesul de detectare și trece prin API-ul Google pentru a crea un
legitim Rezultat SafetyNet care nu reflectă starea reală a dispozitivului.”Recent, totuși, utilizatorii au observat că dispozitivele lor deblocate cu bootloader nu reușesc verificarea de bază a integrității SafetyNet, chiar dacă au folosit Magisk pentru a corecta imaginea de pornire. Potrivit topjohnwu, acest lucru se datorează faptului că este posibil ca Google să fi implementat atestarea cheii la nivel hardware pentru a verifica dacă imaginea de pornire nu a fost modificată. Mai exact, aceasta înseamnă că Serviciile Google Play „[trimite] un certificat de depozit de chei nemodificat către serverele SafetyNet, verifică legitimitatea acestuia și verifică date de extensie a certificatului pentru a ști dacă dispozitivul dvs. [are] pornit verificat activat (starea încărcător de pornire)." Aceasta înseamnă că este posibil să nu mai fie posibil să se ascundă faptul că bootloader-ul a fost deblocat, ceea ce va duce la eșecul aplicațiilor precum Google Pay și Pokémon Go în mod normal.
După cum a remarcat topjohnwu, această modificare a modului în care SafetyNet verifică starea de deblocare a încărcării de pornire vine printr-o actualizare la nivelul serverului a API-ului SafetyNet conținut în Serviciile Google Play. Cu toate acestea, nu toți utilizatorii eșuează aceste verificări SafetyNet actualizate, astfel încât noua atestare a cheii la nivel de hardware poate să nu fie aplicată încă pe scară largă.
L-am văzut pe topjohnwu depășind obstacole tehnice din nou și din nou. Google lansează frecvent noi verificări în SafetyNet pe care topjohnwu le descoperă și le ocolește în Magisk. Fiecare nouă versiune de Android aduce modificări structurii partiției sau imaginii de pornire, necesitând ca topjohnwu să studieze modificările și apoi să implementeze o nouă metodă de corecție. Cu toate acestea, chiar și topjohnwu s-ar putea lupta să găsească un bypass de data aceasta.
Asta pentru că soluția de această dată ar implica piratarea firmware-ului Trusted Execution Environment (TEE) al dispozitivelor pentru a recupera cheia privată. Cu toate acestea, acest lucru este incredibil de dificil de făcut, deoarece necesită găsirea unei vulnerabilități în firmware care este concepută pentru a fi incredibil de sigură. De fapt, multe companii oferă plăți în sute de mii de dolari dacă ar fi găsită o astfel de vulnerabilitate. Google, de exemplu, plătește 250.000 USD pentru vulnerabilitățile de execuție a codului de la distanță în mediul de execuție de încredere al Pixel și până la 1.000.000 USD pentru vulnerabilități în Titan M cip de securitate. Chiar dacă s-ar scurge cumva o cheie privată, este puțin probabil să fie de mare folos, deoarece Google poate revoca cheia de la distanță deci nu poate fi folosit pentru a verifica integritatea dispozitivelor.
Odată ce atestarea cheii la nivel de hardware este aplicată pe scară largă pentru SafetyNet, majoritatea dispozitivelor cu bootloadere deblocate care rulează Android 8.0 Oreo sau o versiune ulterioară nu vor trece de verificarea de bază a integrității SafetyNet. Acest lucru se datorează faptului că toate dispozitivele care s-au lansat cu Android 8.0 Oreo sau o versiune ulterioară trebuie să aibă un depozit de chei hardware implementat într-un TEE. Anumite dispozitive din zilele noastre au chiar module dedicate de securitate hardware (HSM) care fac exploatarea și mai dificilă prin îndepărtarea TEE-ului de procesorul principal; Titan M din Pixel 4 și Noul cip de securitate al Samsung în Galaxy S20 sunt exemple în acest sens.
Topjohnwu explica de asemenea că alte posibile soluții sunt fie imposibile, fie extrem de provocatoare. Utilizarea Xposed Framework pentru a modifica API-ul SafetyNet Attestation în Serviciile Google Play probabil că nu va funcționa, deoarece „verificările adecvate SafetyNet vor verifica rezultatele pe un server la distanță, nu pe [the] dispozitiv care poate fi manipulat de cadre de injectare a codului.” În plus, serviciile Google Play sunt foarte obscure, făcând crearea unui astfel de modul Xposed incredibil de provocatoare în primul rând. loc. Falsificarea unui rezultat al testului SafetyNet nu va fi posibilă, deoarece răspunsurile SafetyNet „vin de la serverele Google și sunt semnate cu cheia privată Google”.
De câțiva ani, Google are capacitatea de a întări verificările SafetyNet utilizând atestarea cheii susținute de hardware. Faptul că s-au abținut să facă acest lucru timp de 3 ani a permis utilizatorilor să se bucure de modulele root și Magisk fără a sacrifica capacitatea de a utiliza aplicații bancare. Cu toate acestea, se pare că capacitatea Magisk de a ascunde efectiv starea de deblocare a bootloader-ului se apropie în curând de sfârșit. Este o schimbare la care ne-am așteptat de ani de zile, dar suntem tristi să vedem că în sfârșit intră în vigoare. Sperăm că Google actualizează API-ul SafetyNet Attestation pentru a returna dacă verificarea stării a folosit bazate pe hardware atestare, deoarece aceasta le-ar permite dezvoltatorilor de aplicații să decidă dacă doresc să blocheze toți utilizatorii care au deblocat bootloader.
Mulțumim lui Daniel Micay (@DanielMicay) pentru contribuția sa cu privire la această chestiune!