Vývojář Magisk zjistil, že Google možná začal používat hardwarové kontroly, aby zjistil, zda bylo zařízení odemčeno bootloaderem.
XDA uznávaný vývojář topjohnwuProjekt „Magisk“ se v komunitě Android v podstatě stal synonymem pro „root“. Jedním z hlavních důvodů, proč je tak populární, je to, že může skrýt skutečnost, že uživatel své zařízení upravil. Google však může zasáhnout proti schopnosti Magisku skrýt stav odemknutí bootloaderu před aplikacemi.
Abyste mohli rootovat svůj telefon, musíte obvykle odemknout bootloader, který vám umožní flashovat upravené spouštěcí obrazy. To je potřeba, protože Magisk upravuje spouštěcí obraz tak, aby spoofoval stav bootloaderu a/nebo kontroly stavu Verified Boot. Google SafetyNet Attestation API, které je součástí Služeb Google Play, se používá k tomu, aby aplikace zjistila, zda běží na neoprávněném zařízení; pokud SafetyNet API zjistí, že bootloader byl odemčen, vrátí stav selhání pro kontrolu „Základní integrity“. Zařízení, která neprojdou touto kontrolou, mohou být zablokována z aplikací, které používají SafetyNet API k určení integrity zařízení; takové aplikace obvykle zahrnují bankovní aplikace, platební aplikace (jako Google Pay) a mnoho online her (jako Pokémon Go). Protože však SafetyNet API dosud používalo pouze softwarové kontroly k určení, zda bylo se zařízením neoprávněně manipulováno, může Magisk jednoduše zfalšovat stav bootloaderu a/nebo Verified Boot, protože je nainstalován na nižší úrovni a má vyšší oprávnění než Služby Google Play a další uživatelský prostor aplikací. Jak vysvětluje topjohnwu, MagiskHide „[vytváří] izolované „bezpečné prostředí“ pro proces detekce a prochází rozhraním Google API, aby vytvořil
Nedávno si však uživatelé všimli, že jejich zařízení odemknutá bootloaderem selhávají při základní kontrole integrity SafetyNet, i když použili Magisk k opravě spouštěcího obrazu. Podle topjohnwu je to proto, že Google možná implementoval atestaci klíče na hardwarové úrovni, aby ověřil, že se spouštěcím obrazem nebylo manipulováno. Konkrétně to znamená, že Služby Google Play „[odešle] neupravený certifikát úložiště klíčů na servery SafetyNet, ověří jeho legitimitu a zkontroluje data rozšíření certifikátu, abyste věděli, zda vaše zařízení [má] ověřené spouštění povoleno (stav bootloaderu)." To znamená, že již nemusí být možné skrýt skutečnost, že bootloader byl odemčen, což povede k tomu, že aplikace jako Google Pay a Pokémon Go nebudou fungovat normálně.
Jak poznamenal topjohnwu, tato změna ve způsobu, jakým SafetyNet kontroluje stav odemčení bootloaderu, přichází prostřednictvím aktualizace rozhraní SafetyNet API obsažené ve službách Google Play na straně serveru. Ne každý uživatel však neprochází těmito aktualizovanými kontrolami SafetyNet, takže nová atestace klíče na úrovni hardwaru zatím nemusí být široce vynucována.
Znovu a znovu jsme viděli topjohnwu překonávat technické překážky. Google často zavádí nové kontroly v SafetyNet, které topjohnwu poté objeví a obchází v Magisku. Každá nová verze Androidu přináší změny ve struktuře oddílu nebo spouštěcím obrazu, což vyžaduje, aby topjohnwu prostudoval změny a poté implementoval novou metodu záplatování. Nicméně i topjohnwu může mít tentokrát potíže s hledáním obchvatu.
Je to proto, že řešení by tentokrát zahrnovalo hacknutí firmwaru Trusted Execution Environment (TEE) zařízení za účelem získání soukromého klíče. To je však neuvěřitelně obtížné, protože to vyžaduje nalezení zranitelnosti ve firmwaru, která je navržena tak, aby byla neuvěřitelně bezpečná. Ve skutečnosti mnoho společností nabízí platby ve stovkách tisíc dolarů, pokud by byla taková zranitelnost nalezena. Google například platí 250 000 $ za zranitelnost vzdáleného spuštění kódu v prostředí Pixel's Trusted Execution Environment a až 1 000 000 $ za zranitelnosti v Titan M bezpečnostní čip. I kdyby soukromý klíč nějak unikal, je nepravděpodobné, že by od té doby byl hodně užitečný Google může vzdáleně odvolat klíč takže jej nelze použít k ověření integrity zařízení.
Jakmile bude pro SafetyNet široce prosazována atestace klíče na úrovni hardwaru, většina zařízení s odemčenými bootloadery se systémem Android 8.0 Oreo nebo vyšším neprojde základní kontrolou integrity SafetyNet. Je to proto, že všechna zařízení, která byla uvedena na trh se systémem Android 8.0 Oreo nebo vyšším, musí mít hardwarové úložiště klíčů implementované v TEE. Některá zařízení mají v dnešní době dokonce vyhrazené hardwarové bezpečnostní moduly (HSM), které ještě více ztěžují využití tím, že se TEE přesune pryč od hlavního procesoru; Titan M v Pixel 4 a Nový bezpečnostní čip Samsung v Galaxy S20 jsou toho příkladem.
Topjohnwu také vysvětluje že další potenciální řešení jsou buď nemožná, nebo velmi náročná. Použití rozhraní Xposed Framework k úpravě SafetyNet Attestation API ve Službách Google Play pravděpodobně nebude fungovat, protože „správné kontroly SafetyNet ověří výsledky na vzdáleném serveru, nikoli na [] zařízení, se kterým lze manipulovat pomocí rámců pro vkládání kódu." Kromě toho jsou služby Google Play velmi nejasné, takže vytvoření takového modulu Xposed je neuvěřitelně náročné v prvním místo. Falšování výsledku testu SafetyNet nebude možné, protože odpovědi SafetyNet „pocházejí ze serverů Google a jsou podepsány soukromým klíčem Google“.
Google má již několik let možnost zpřísnit kontroly SafetyNet pomocí hardwarově podporované atestace klíče. Skutečnost, že se tak zdrželi po dobu 3 let, umožnila uživatelům využívat root a Magisk moduly, aniž by museli obětovat možnost používat bankovní aplikace. Zdá se však, že schopnost Magisku efektivně skrývat stav odemčení bootloaderu se brzy chýlí ke konci. Je to změna, na kterou jsme čekali roky, ale je nám smutno, když vidíme, že konečně vstoupila v platnost. Doufáme, že Google aktualizuje SafetyNet Attestation API, aby se vrátilo, zda byla kontrola stavu použita na základě hardwaru atestace, protože by to vývojářům aplikací umožnilo rozhodnout, zda chtějí zablokovat všechny uživatele, kteří odemkli zavaděč.
Díky Daniel Micay (@Daniel Micay) za jeho příspěvek k této záležitosti!