A Magisk fejlesztője felfedezte, hogy a Google elkezdhetett hardverellenőrzéseket használni annak megállapítására, hogy az eszköz rendszerbetöltője feloldva van-e.
XDA elismert fejlesztő topjohnwuA "Magisk" projekt lényegében a "root" szinonimájává vált az Android közösségben. Az egyik fő oka annak, hogy olyan népszerű, mert képes elrejteni azt a tényt, hogy a felhasználó módosította eszközét. A Google azonban felléphet a Magisk azon képessége ellen, hogy elrejtse a rendszerbetöltő feloldási állapotát az alkalmazások elől.
A telefon rootolásához általában fel kell oldania a rendszerbetöltőt, amely lehetővé teszi a módosított rendszerindító képek felvillantását. Erre azért van szükség, mert a Magisk úgy módosítja a rendszerindító lemezképet, hogy meghamisítsa a rendszerbetöltő állapotát és/vagy a Verified Boot állapotellenőrzéseket. A Google SafetyNet Attestation API-ja, amely a Google Play Services része, arra szolgál, hogy közölje az alkalmazásokkal, ha az egy manipulált eszközön fut; ha a SafetyNet API azt észleli, hogy a rendszerbetöltő fel van oldva, akkor hibaállapotot ad vissza az „Alapvető integritás” ellenőrzéshez. Azok az eszközök, amelyek nem felelnek meg az ellenőrzésnek, ezután kizárhatók azokból az alkalmazásokból, amelyek a SafetyNet API-t használják az eszköz integritásának meghatározására; az ilyen alkalmazások általában banki alkalmazásokat, fizetési alkalmazásokat (például Google Pay) és sok online játékot (például Pokémon Go) tartalmaznak. Mivel azonban a SafetyNet API eddig csak szoftveres ellenőrzéseket használt annak megállapítására, hogy az eszközt manipulálták-e, a Magisk egyszerűen meghamisíthatja a rendszerbetöltő és/vagy Verified Boot állapot, mivel alacsonyabb szinten és magasabb jogosultságokkal van telepítve, mint a Google Play szolgáltatások és más felhasználói területek alkalmazások. Ahogy topjohnwu elmagyarázza, a MagiskHide „egy elszigetelt „biztonságos környezetet” hoz létre az észlelési folyamathoz, és a Google API-ján keresztül hoz létre egy
legális A SafetyNet eredménye, amely nem tükrözi az eszköz valós állapotát."A közelmúltban azonban a felhasználók észrevették, hogy rendszerbetöltővel feloldott eszközeik nem felelnek meg a SafetyNet alapvető integritásellenőrzésének, noha a Magisk segítségével javították a rendszerindító lemezképet. Topjohnwu szerint ennek az az oka, hogy a Google hardverszintű kulcstanúsítást alkalmazott annak ellenőrzésére, hogy a rendszerindító lemezképet nem manipulálták-e. Ez konkrétan azt jelenti, hogy a Google Play Services "[küld] egy módosítatlan kulcstároló tanúsítványt a SafetyNet szervereinek, ellenőrzi annak legitimitását, és tanúsítvány kiterjesztés adatait, hogy megtudja, hogy az eszköz [van] ellenőrizve, hogy engedélyezve van-e a rendszerindítás (bootloader állapot)." Ez azt jelenti, hogy már nem elrejthető a tény, hogy a rendszerbetöltő feloldásra került, ami azt eredményezi, hogy az olyan alkalmazások, mint a Google Pay és a Pokémon Go nem fognak működni normális esetben.
Ahogyan topjohnwu megjegyezte, ez a változás a SafetyNet rendszerbetöltő feloldási állapotának ellenőrzésében a Google Play-szolgáltatásokban található SafetyNet API szerveroldali frissítésén keresztül történik. Azonban nem minden felhasználó bukja meg ezeket a frissített SafetyNet-ellenőrzéseket, így előfordulhat, hogy az új hardverszintű kulcstanúsítványt még nem kényszerítik széles körben.
Láttuk, hogy topjohnwu újra és újra legyőzi a technikai akadályokat. A Google gyakran vezet be új ellenőrzéseket a SafetyNetben, amelyeket a topjohnwu felfedez és megkerül a Magiskben. Az Android minden új verziója változásokat hoz a partíciószerkezetben vagy a rendszerindító lemezképben, ami megköveteli, hogy a topjohnwu tanulmányozza a változtatásokat, majd új javítási módszert alkalmazzon. Ezúttal azonban még topjohnwu is nehézségekbe ütközhet, hogy elkerülő utat találjon.
Ez azért van így, mert a megoldás ezúttal az eszközök Trusted Execution Environment (TEE) firmware-ének feltörését jelentené a privát kulcs lekérése érdekében. Ezt azonban hihetetlenül nehéz megtenni, mivel meg kell találni egy sebezhetőséget a hihetetlenül biztonságos firmware-ben. Valójában sok vállalat több százezer dolláros fizetést kínál, ha ilyen sérülékenységet találnak. A Google például 250 000 dollárt fizet a távoli kódfuttatási sebezhetőségekért a Pixel megbízható végrehajtási környezetében, és 1 000 000 dollárig a sebezhetőségek miatt Titan M biztonsági chip. Még ha egy privát kulcs valahogy kiszivárogna is, nem valószínű, hogy sok haszna lenne, mivel A Google távolról is visszavonhatja a kulcsot így nem használható az eszközök integritásának ellenőrzésére.
Miután a hardverszintű kulcsok tanúsítását széles körben bevezetik a SafetyNet számára, a legtöbb Android 8.0 Oreo vagy újabb rendszert futtató, feloldatlan rendszerbetöltővel rendelkező eszköz nem felel meg a SafetyNet alapvető integritásellenőrzésének. Ennek az az oka, hogy minden Android 8.0 Oreo vagy újabb verzióval elindított eszköznek rendelkeznie kell egy TEE-ben implementált hardveres kulcstárolóval. Egyes eszközök manapság még dedikált hardveres biztonsági modulokkal (HSM) is rendelkeznek, amelyek még megnehezítik a kiaknázást azáltal, hogy elmozdítják a TEE-t a fő processzortól; a Titan M a Pixel 4-ben és A Samsung új biztonsági chipje a Galaxy S20 példái erre.
Topjohnwu is magyarázza hogy más lehetséges megoldások lehetetlenek vagy nagy kihívást jelentenek. Az Xposed Framework használata a SafetyNet Attestation API módosítására a Google Play szolgáltatásokban valószínűleg nem fog működni, mivel "a megfelelő SafetyNet ellenőrzések egy távoli szerveren ellenőrzik az eredményeket, nem a [a] olyan eszköz, amelyet kódbefecskendezési keretrendszerekkel lehet manipulálni." Ezenkívül a Google Play Services nagyon homályos, így egy ilyen Xposed Modul létrehozása az első pillanatban hihetetlenül nagy kihívást jelent. hely. A SafetyNet teszteredményeinek meghamisítása sem kivitelezhető, mivel a SafetyNet válaszai „a Google szervereiről érkeznek, és a Google privát kulcsával vannak aláírva”.
A Google már több éve képes keményíteni a SafetyNet-ellenőrzéseket hardverrel támogatott kulcsok tanúsításával. Az a tény, hogy 3 évig tartózkodtak ettől, lehetővé tette a felhasználók számára, hogy élvezzék a root és a Magisk modulokat anélkül, hogy feláldozták volna a banki alkalmazások használatának lehetőségét. Úgy tűnik azonban, hogy a Magisk azon képessége, hogy hatékonyan elrejtse a rendszerbetöltő feloldási állapotát, hamarosan a végéhez közeledik. Ez egy olyan változás, amelyre évek óta vártunk, de szomorúan látjuk, hogy végre életbe lép. Reméljük, hogy a Google frissíti a SafetyNet Attestation API-t, és visszaadja, hogy az állapotellenőrzés hardveralapú-e tanúsítvány, mivel ez lehetővé tenné az alkalmazásfejlesztők számára, hogy eldöntsék, le akarják-e tiltani az összes olyan felhasználót, aki feloldotta a rendszerbetöltő.
Köszönet Daniel Micaynak (@DanielMicay) az üggyel kapcsolatos hozzászólásáért!