Der Entwickler von Magisk hat herausgefunden, dass Google möglicherweise damit begonnen hat, Hardwareprüfungen durchzuführen, um festzustellen, ob ein Gerät vom Bootloader entsperrt wurde.
XDA-anerkannter Entwickler topjohnwuDas „Magisk“-Projekt ist in der Android-Community im Wesentlichen zum Synonym für „root“ geworden. Einer der Hauptgründe dafür, dass es so beliebt ist, besteht darin, dass es die Tatsache verbergen kann, dass der Benutzer sein Gerät geändert hat. Allerdings greift Google möglicherweise hart gegen die Fähigkeit von Magisk vor, den Bootloader-Entsperrstatus vor Anwendungen zu verbergen.
Um Ihr Telefon zu rooten, müssen Sie normalerweise den Bootloader entsperren, der Ihnen das Flashen geänderter Boot-Images ermöglicht. Dies ist erforderlich, da Magisk das Boot-Image ändert, um den Bootloader-Status und/oder die Überprüfung des Verified Boot-Status zu fälschen. Die SafetyNet Attestation API von Google, die Teil der Google Play Services ist, wird verwendet, um einer App mitzuteilen, ob sie auf einem manipulierten Gerät ausgeführt wird. Wenn die SafetyNet-API erkennt, dass der Bootloader entsperrt wurde, gibt sie einen Fehlerstatus für die „Basic Integrity“-Prüfung zurück. Geräte, die diese Prüfung nicht bestehen, können dann von Apps gesperrt werden, die die SafetyNet-API verwenden, um die Geräteintegrität zu ermitteln; Zu diesen Apps gehören typischerweise Banking-Apps, Zahlungs-Apps (wie Google Pay) und viele Online-Spiele (wie Pokémon Go). Da die SafetyNet-API bisher jedoch nur Softwareprüfungen verwendet hat, um festzustellen, ob das Gerät manipuliert wurde, kann Magisk dies einfach fälschen Bootloader und/oder Verified Boot-Status, da er auf einer niedrigeren Ebene und mit höheren Berechtigungen als Google Play Services und andere Benutzerbereiche installiert wird Anwendungen. Wie topjohnwu erklärt, „[erstellt] MagiskHide „eine isolierte ‚sichere Umgebung‘ für den Erkennungsprozess und durchläuft die API von Google, um eine zu erstellen.“
legitim SafetyNet-Ergebnis, das nicht den tatsächlichen Status des Geräts widerspiegelt.“Kürzlich haben Benutzer jedoch festgestellt, dass ihre vom Bootloader entsperrten Geräte die grundlegende Integritätsprüfung von SafetyNet nicht bestehen, obwohl sie Magisk zum Patchen des Boot-Images verwendet haben. Laut topjohnwu liegt dies daran, dass Google möglicherweise eine Schlüsselbescheinigung auf Hardwareebene implementiert hat, um zu überprüfen, ob das Boot-Image nicht manipuliert wurde. Konkret bedeutet dies, dass Google Play Services „ein unverändertes Keystore-Zertifikat an SafetyNet-Server [sendet], seine Legitimität überprüft und überprüft Zertifikatserweiterungsdaten, um zu erfahren, ob Ihr Gerät überprüft hat, ob der Start aktiviert ist (Bootloader-Status).“ Dies bedeutet, dass dies möglicherweise nicht mehr der Fall ist Es ist möglich, die Tatsache zu verbergen, dass der Bootloader entsperrt wurde, was dazu führt, dass Anwendungen wie Google Pay und Pokémon Go nicht funktionieren normalerweise.
Wie topjohnwu feststellte, erfolgt diese Änderung an der Art und Weise, wie SafetyNet den Entsperrstatus des Bootloaders überprüft, durch ein serverseitiges Update der SafetyNet-API, die in den Google Play-Diensten enthalten ist. Allerdings besteht nicht jeder Benutzer diese aktualisierten SafetyNet-Prüfungen nicht, sodass die neue Schlüsselbescheinigung auf Hardwareebene möglicherweise noch nicht allgemein durchgesetzt wird.
Wir haben gesehen, wie topjohnwu immer wieder technische Hürden überwunden hat. Google führt in SafetyNet regelmäßig neue Überprüfungen ein, die topjohnwu dann in Magisk erkennt und umgeht. Jede neue Android-Version bringt Änderungen an der Partitionsstruktur oder dem Boot-Image mit sich, sodass topjohnwu die Änderungen untersuchen und dann eine neue Patch-Methode implementieren muss. Allerdings könnte selbst TopJohnwu dieses Mal Schwierigkeiten haben, eine Umgehungsstraße zu finden.
Dies liegt daran, dass die Problemumgehung dieses Mal darin bestehen würde, die Trusted Execution Environment (TEE)-Firmware von Geräten zu hacken, um den privaten Schlüssel abzurufen. Dies ist jedoch äußerst schwierig, da dazu eine Schwachstelle in der Firmware gefunden werden muss, die äußerst sicher sein soll. Tatsächlich bieten viele Unternehmen Zahlungen in Höhe von Hunderttausenden Dollar an, wenn eine solche Schwachstelle gefunden wird. Google zahlt beispielsweise 250.000 US-Dollar für Schwachstellen bei der Remotecodeausführung in der Trusted Execution Environment des Pixels bis zu 1.000.000 $ für Schwachstellen in der Titan M Sicherheitschip. Selbst wenn ein privater Schlüssel irgendwie durchgesickert wäre, wäre es unwahrscheinlich, dass er seitdem von großem Nutzen wäre Google kann den Schlüssel aus der Ferne widerrufen Daher kann es nicht zur Überprüfung der Integrität von Geräten verwendet werden.
Sobald die Schlüsselbescheinigung auf Hardwareebene für SafetyNet weithin durchgesetzt wird, werden die meisten Geräte mit entsperrten Bootloadern, auf denen Android 8.0 Oreo oder höher ausgeführt wird, die grundlegende Integritätsprüfung von SafetyNet nicht bestehen. Dies liegt daran, dass auf allen Geräten, die mit Android 8.0 Oreo oder höher gestartet wurden, ein Hardware-Keystore in einem TEE implementiert sein muss. Bestimmte Geräte verfügen heutzutage sogar über dedizierte Hardware-Sicherheitsmodule (HSMs), die die Ausnutzung noch schwieriger machen, indem sie den TEE vom Hauptprozessor entfernen; der Titan M im Pixel 4 und Samsungs neuer Sicherheitschip im Galaxy S20 sind Beispiele dafür.
Topjohnwu erklärt auch dass andere mögliche Problemumgehungen entweder unmöglich oder sehr anspruchsvoll sind. Die Verwendung des Xposed Framework zum Ändern der SafetyNet Attestation API in Google Play Services wird wahrscheinlich nicht funktionieren, da „richtige SafetyNet-Prüfungen die Ergebnisse auf einem Remote-Server überprüfen, nicht auf [dem] Gerät, das durch Code-Injection-Frameworks manipuliert werden kann.“ Darüber hinaus sind die Google Play-Dienste stark verschleiert, was die Erstellung eines solchen Xposed-Moduls zunächst einmal unglaublich schwierig macht Ort. Das Fälschen eines SafetyNet-Testergebnisses ist ebenfalls nicht möglich, da die SafetyNet-Antworten „von Google-Servern stammen und mit dem privaten Schlüssel von Google signiert sind“.
Google verfügt bereits seit mehreren Jahren über die Möglichkeit, SafetyNet-Prüfungen mithilfe einer hardwaregestützten Schlüsselbescheinigung zu härten. Die Tatsache, dass sie dies drei Jahre lang unterlassen haben, ermöglicht es Benutzern, Root- und Magisk-Module zu nutzen, ohne auf die Möglichkeit zu verzichten, Banking-Apps zu nutzen. Es scheint jedoch, dass die Fähigkeit von Magisk, den Entsperrstatus des Bootloaders effektiv zu verbergen, bald zu Ende geht. Es ist eine Änderung, mit der wir seit Jahren gerechnet haben, aber wir sind traurig, dass sie nun endlich in Kraft tritt. Wir hoffen, dass Google die SafetyNet Attestation API aktualisiert, um zurückzugeben, ob die Statusprüfung hardwarebasiert erfolgte Bescheinigung, da dies es App-Entwicklern ermöglichen würde, zu entscheiden, ob sie alle Benutzer blockieren möchten, die die App entsperrt haben Bootloader.
Danke an Daniel Micay (@DanielMicay) für seinen Beitrag zu diesem Thema!