Vývojár Magisk zistil, že Google mohol začať používať hardvérové kontroly na zistenie, či bolo zariadenie odomknuté.
XDA uznávaný vývojár topjohnwuProjekt „Magisk“ sa v komunite Android v podstate stal synonymom pre „root“. Jedným z hlavných dôvodov, prečo je tak populárny, je to, že môže zakryť skutočnosť, že používateľ upravil svoje zariadenie. Google však môže zakročiť proti schopnosti Magisk skryť stav odomknutia zavádzača pred aplikáciami.
Aby ste mohli rootovať telefón, zvyčajne musíte odomknúť bootloader, ktorý vám umožní flashovať upravené bootovacie obrázky. Je to potrebné, pretože Magisk upravuje bootovací obraz tak, aby spoofoval stav zavádzača a/alebo kontroloval stav overeného spustenia. Rozhranie API SafetyNet Attestation od spoločnosti Google, ktoré je súčasťou Služieb Google Play, sa používa na informovanie aplikácie, či je spustená na napadnutom zariadení. ak SafetyNet API zistí, že bootloader bol odomknutý, vráti stav zlyhania pre kontrolu „Basic Integrity“. Zariadenia, ktoré neprejdú touto kontrolou, môžu byť zablokované z aplikácií, ktoré používajú SafetyNet API na určenie integrity zariadenia; takéto aplikácie zvyčajne zahŕňajú bankové aplikácie, platobné aplikácie (napríklad Google Pay) a mnoho online hier (napríklad Pokémon Go). Keďže však SafetyNet API doteraz používalo iba softvérové kontroly na zistenie, či so zariadením nebolo manipulované, Magisk môže jednoducho sfalšovať stav zavádzača a/alebo overeného spustenia, pretože je nainštalovaný na nižšej úrovni a s vyššími oprávneniami ako Služby Google Play a iný používateľský priestor aplikácie. Ako vysvetľuje topjohnwu, MagiskHide „[vytvára] izolované „bezpečné prostredie“ pre proces detekcie a prechádza cez API Google, aby vytvoril
utiecť Výsledok SafetyNet, ktorý neodráža skutočný stav zariadenia.“Nedávno si však používatelia všimli, že ich zariadenia odomknuté bootloaderom zlyhávajú pri kontrole základnej integrity SafetyNet, aj keď na opravu zavádzacieho obrazu použili Magisk. Podľa topjohnwu je to preto, že Google mohol implementovať atestáciu kľúča na úrovni hardvéru, aby overil, že so zavádzacím obrazom nebolo manipulované. Konkrétne to znamená, že Služby Google Play „[odošle] neupravený certifikát úložiska kľúčov na servery SafetyNet, overí jeho legitimitu a skontroluje údaje rozšírenia certifikátu, aby ste vedeli, či vaše zariadenie [má] overené spustenie povolené (stav zavádzača).“ To znamená, že už nemusí byť možné skryť skutočnosť, že bootloader bol odomknutý, čo spôsobí, že aplikácie ako Google Pay a Pokémon Go nebudú fungovať normálne.
Ako poznamenal topjohnwu, táto zmena spôsobu, akým SafetyNet kontroluje stav odomknutia zavádzača, prichádza prostredníctvom aktualizácie rozhrania SafetyNet API obsiahnutého v službách Google Play na strane servera. Nie každý používateľ však zlyhá v týchto aktualizovaných kontrolách SafetyNet, takže nové osvedčenie kľúča na úrovni hardvéru ešte nemusí byť široko presadzované.
Znovu a znovu sme videli, ako topjohnwu prekonáva technické prekážky. Google často zavádza nové kontroly v SafetyNet, ktoré topjohnwu potom objaví a obíde v Magisku. Každá nová verzia systému Android prináša zmeny v štruktúre oddielov alebo zavádzacom obraze, čo vyžaduje, aby topjohnwu študoval zmeny a potom implementoval novú metódu opráv. Avšak aj topjohnwu môže mať tentoraz problém nájsť obchvat.
Je to preto, že riešenie by tentoraz zahŕňalo hacknutie firmvéru Trusted Execution Environment (TEE) zariadení s cieľom získať súkromný kľúč. Je to však neuveriteľne ťažké, pretože to vyžaduje nájdenie zraniteľnosti vo firmvéri, ktorá je navrhnutá tak, aby bola neuveriteľne bezpečná. V skutočnosti mnohé spoločnosti ponúkajú platby v stovkách tisíc dolárov, ak by sa takáto zraniteľnosť našla. Spoločnosť Google napríklad platí 250 000 USD za chyby zabezpečenia vzdialeného spustenia kódu v prostredí dôveryhodného spustenia zariadenia Pixel a až 1 000 000 USD pre zraniteľnosti v Titan M bezpečnostný čip. Aj keby nejaký súkromný kľúč unikol, je nepravdepodobné, že by bol odvtedy veľmi užitočný Google môže kľúč odvolať na diaľku takže ho nemožno použiť na overenie integrity zariadení.
Keď bude pre SafetyNet široko presadzovaná atestácia kľúča na hardvérovej úrovni, väčšina zariadení s odomknutými bootloadermi so systémom Android 8.0 Oreo alebo vyšším neprejde kontrolou základnej integrity SafetyNet. Je to preto, že všetky zariadenia, ktoré boli spustené s Androidom 8.0 Oreo alebo vyšším, musia mať hardvérové úložisko kľúčov implementované v TEE. Niektoré zariadenia majú v súčasnosti dokonca vyhradené hardvérové bezpečnostné moduly (HSM), ktoré ešte viac sťažujú využívanie presunutím TEE preč od hlavného procesora; Titan M v Pixel 4 a Nový bezpečnostný čip Samsung v Galaxy S20 sú toho príkladom.
Topjohnwu tiež vysvetľuje že iné potenciálne riešenia sú buď nemožné alebo veľmi náročné. Použitie rámca Xposed na úpravu rozhrania SafetyNet Attestation API v službách Google Play pravdepodobne nebude fungovať, pretože „správne kontroly SafetyNet overia výsledky na vzdialenom serveri, nie na [] zariadenie, ktoré možno manipulovať pomocou rámcov na vkladanie kódu." Okrem toho sú služby Google Play veľmi nejasné, vďaka čomu je vytvorenie takéhoto modulu Xposed neuveriteľne náročné v prvom miesto. Sfalšovanie výsledku testu SafetyNet tiež nebude možné, pretože odpovede SafetyNet „pochádzajú zo serverov Google a sú podpísané súkromným kľúčom Google“.
Google má už niekoľko rokov možnosť sprísniť kontroly SafetyNet pomocou hardvérového overenia kľúča. Skutočnosť, že sa tak zdržali 3 roky, umožnila používateľom využívať moduly root a Magisk bez obetovania možnosti používať bankové aplikácie. Zdá sa však, že Magiskova schopnosť efektívne skrývať stav odomknutia bootloadera sa čoskoro blíži ku koncu. Je to zmena, ktorú sme očakávali roky, no je nám smutno, keď vidíme, že sa konečne prejavila. Dúfame, že spoločnosť Google aktualizuje rozhranie SafetyNet Attestation API, aby sa vrátilo, či sa kontrola stavu použila na základe hardvéru atestácia, pretože by to vývojárom aplikácií umožnilo rozhodnúť sa, či chcú zablokovať všetkých používateľov, ktorí odomkli bootloader.
Ďakujem Danielovi Micayovi (@DanielMicay) za jeho príspevok k tejto záležitosti!