De ontwikkelaar van Magisk heeft ontdekt dat Google mogelijk hardwarecontroles is gaan gebruiken om te bepalen of een apparaat is ontgrendeld door de bootloader.
XDA erkende ontwikkelaar topjohnwuHet "Magisk"-project is in wezen synoniem geworden met "root" in de Android-gemeenschap. Een van de belangrijkste redenen waarom het zo populair is, is omdat het het feit kan verbergen dat de gebruiker zijn apparaat heeft aangepast. Google gaat echter mogelijk hard optreden tegen het vermogen van Magisk om de ontgrendelingsstatus van de bootloader voor applicaties te verbergen.
Om je telefoon te kunnen rooten, moet je meestal de bootloader ontgrendelen, waardoor je gewijzigde opstartimages kunt flashen. Dit is nodig omdat Magisk de opstartimage aanpast om de bootloaderstatus en/of de Verified Boot-statuscontroles te vervalsen. De SafetyNet Attestation API van Google, die deel uitmaakt van Google Play Services, wordt gebruikt om een app te vertellen of deze op een apparaat draait waar mee is geknoeid; als de SafetyNet API detecteert dat de bootloader is ontgrendeld, retourneert deze een foutstatus voor de "Basisintegriteit"-controle. Apparaten die deze controle niet doorstaan, kunnen vervolgens worden uitgesloten van apps die de SafetyNet API gebruiken om de apparaatintegriteit te bepalen; Dergelijke apps omvatten doorgaans bankapps, betalingsapps (zoals Google Pay) en veel online games (zoals Pokémon Go). Omdat de SafetyNet API tot nu toe echter alleen softwarecontroles heeft gebruikt om te bepalen of er met het apparaat is geknoeid, kan Magisk de gegevens eenvoudigweg vervalsen. bootloader en/of geverifieerde opstartstatus omdat deze op een lager niveau en met hogere rechten is geïnstalleerd dan Google Play Services en andere gebruikersruimte toepassingen. Zoals topjohnwu uitlegt, creëert MagiskHide "een geïsoleerde 'veilige omgeving' voor het detectieproces, en het gaat via de API van Google om een
Onlangs hebben gebruikers echter gemerkt dat hun door de bootloader ontgrendelde apparaten de SafetyNet Basic Integrity-controle niet doorstaan, ook al hebben ze Magisk gebruikt om de opstartimage te patchen. Volgens topjohnwu komt dit doordat Google mogelijk sleutelattesten op hardwareniveau heeft geïmplementeerd om te verifiëren dat er niet met de opstartimage is geknoeid. Concreet betekent dit dat Google Play-services een ongewijzigd sleutelarchiefcertificaat naar SafetyNet-servers [stuurt], de legitimiteit ervan verifieert en certificaatextensiegegevens om te weten of uw apparaat geverifieerd heeft dat opstarten is ingeschakeld (bootloaderstatus)." Dit betekent dat dit mogelijk niet langer het geval is mogelijk om te verbergen dat de bootloader is ontgrendeld, waardoor applicaties als Google Pay en Pokémon Go niet werken normaal gesproken.
Zoals topjohnwu opmerkte, komt deze verandering in de manier waarop SafetyNet de ontgrendelingsstatus van de bootloader controleert, via een server-side update van de SafetyNet API in Google Play Services. Niet elke gebruiker slaagt echter niet voor deze bijgewerkte SafetyNet-controles, dus de nieuwe sleutelattest op hardwareniveau wordt mogelijk nog niet breed afgedwongen.
We hebben topjohnwu keer op keer technische hindernissen zien overwinnen. Google rolt regelmatig nieuwe controles uit in SafetyNet die topjohnwu vervolgens in Magisk ontdekt en omzeilt. Elke nieuwe versie van Android brengt wijzigingen in de partitiestructuur of het opstartimage met zich mee, waardoor topjohnwu de wijzigingen moet bestuderen en vervolgens een nieuwe patchmethode moet implementeren. Maar zelfs topjohnwu kan deze keer moeite hebben om een bypass te vinden.
Dat komt omdat de oplossing deze keer zou bestaan uit het hacken van de Trusted Execution Environment (TEE)-firmware van apparaten om de privésleutel op te halen. Dit is echter ongelooflijk moeilijk om te doen, omdat hiervoor een kwetsbaarheid in de firmware moet worden gevonden die is ontworpen om ongelooflijk veilig te zijn. Veel bedrijven bieden zelfs betalingen aan in de honderdduizenden dollars als een dergelijke kwetsbaarheid zou worden gevonden. Google betaalt bijvoorbeeld $250.000 voor kwetsbaarheden bij het uitvoeren van code op afstand in de Trusted Execution Environment van de Pixel, en tot $ 1.000.000 voor kwetsbaarheden in de Titaan M beveiligingschip. Zelfs als een privésleutel op de een of andere manier zou lekken, is het onwaarschijnlijk dat deze sindsdien veel nut zal hebben Google kan de sleutel op afstand intrekken het kan dus niet worden gebruikt om de integriteit van apparaten te verifiëren.
Zodra sleutelattestering op hardwareniveau breed wordt afgedwongen voor SafetyNet, zullen de meeste apparaten met ontgrendelde bootloaders met Android 8.0 Oreo of hoger de Basic Integrity-controle van SafetyNet niet doorstaan. Dit komt omdat voor alle apparaten die zijn gelanceerd met Android 8.0 Oreo of hoger een hardware-sleutelarchief in een TEE moet zijn geïmplementeerd. Bepaalde apparaten hebben tegenwoordig zelfs speciale hardwarebeveiligingsmodules (HSM's) die de exploitatie nog moeilijker maken door de TEE weg te plaatsen van de hoofdprocessor; de Titan M in de Pixel 4 en De nieuwe beveiligingschip van Samsung in de Galaxy S20 zijn daar voorbeelden van.
Topjohnwu legt ook uit dat andere mogelijke oplossingen onmogelijk of zeer uitdagend zijn. Het gebruik van het Xposed Framework om de SafetyNet Attestation API in Google Play Services te wijzigen zal waarschijnlijk niet werken, omdat "goede SafetyNet-controles de resultaten op een externe server zullen verifiëren, niet op [de] apparaat dat kan worden gemanipuleerd door raamwerken voor code-injectie." Bovendien zijn Google Play-services zeer onduidelijk, waardoor het maken van zo'n Xposed-module in de eerste instantie ongelooflijk uitdagend is. plaats. Het vervalsen van een SafetyNet-testresultaat is ook niet mogelijk, omdat de SafetyNet-reacties "afkomstig zijn van Google-servers en zijn ondertekend met de privésleutel van Google."
Google beschikt al enkele jaren over de mogelijkheid om SafetyNet-controles te verscherpen met behulp van door hardware ondersteunde sleutelattesten. Het feit dat ze dit drie jaar lang niet hebben gedaan, heeft ervoor gezorgd dat gebruikers van root- en Magisk-modules kunnen genieten zonder dat dit ten koste gaat van de mogelijkheid om bankapps te gebruiken. Het lijkt er echter op dat het vermogen van Magisk om de ontgrendelingsstatus van de bootloader effectief te verbergen binnenkort ten einde loopt. Het is een verandering die we al jaren verwachtten, maar we vinden het jammer dat deze eindelijk van kracht wordt. We hopen dat Google de SafetyNet Attestation API bijwerkt om te laten zien of de statuscontrole op hardware is gebaseerd attest, omdat app-ontwikkelaars hierdoor kunnen beslissen of ze alle gebruikers willen blokkeren die de bootlader.
Met dank aan Daniel Micay (@DanielMicay) voor zijn inbreng in deze kwestie!