Die gefürchtete Hardware-Zertifizierung von SafetyNet wird eingeführt, wodurch es für Magisk viel schwieriger wird, root zu verbergen

Bereits im März bemerkten einige Benutzer mit installiertem Magisk, dass ihre Geräte die SafetyNet-Zertifizierung nicht bestanden. Diese Nachricht beunruhigte die Community von XDA, da viele wichtige Bank- / Finanz-Apps und beliebte Spiele wie Pokémon Go und Fate / Grand Order sich weigerten, auf gerooteten Geräten zu laufen. Für einige Zeit schien es, als ob die verschärften Einschränkungen in SafetyNet zurückgezogen wurden, nur um in den letzten Wochen für eine Handvoll Benutzer wieder eingeführt zu werden. Google hat jedoch Anfang Mai stillschweigend bestätigt, dass sie eine hardwarebasierte Bescheinigung für SafetyNet-Antworten erhalten haben, weshalb Magisk den Bootloader-Entsperrstatus im März nicht verbergen konnte. Wenn diese Änderung weit verbreitet ist, bedeutet dies, dass Benutzer zwischen dem Zugriff auf root / benutzerdefinierte ROMs / Kernel / usw. wählen müssen. oder ihre bevorzugten Banking-Apps und Spiele. Einer der größten Appelle von Android für Power-User könnte bald weg sein.

Um diese Reihe von Ereignissen zusammenzufassen, sollten wir zuerst über SafetyNet selbst sprechen. SafetyNet ist eine Reihe von APIs in Google Play Services. Die SafetyNet Attestation API ist eine dieser APIs und kann von Anwendungen von Drittanbietern aufgerufen werden, um zu überprüfen, ob die Softwareumgebung des Geräts in irgendeiner Weise manipuliert wurde. Die API prüft auf verschiedene Dinge wie Anzeichen von Superuser-Binärdateien, den Entsperrstatus des Bootloaders und vieles mehr. Wenn Sie ein Gerät mit Magisk root, es “ eine isolierte ’sichere Umgebung‘ für den Erkennungsprozess, und es geht durch Googles API ein legit SafetyNet Ergebnis zu erstellen, die nicht den tatsächlichen Status des Geräts widerspiegelt,“pro XDA Senior anerkannter Entwickler topjohnwu. Auf diese Weise kann der Benutzer sein Telefon rooten und gleichzeitig sicherstellen, dass die API für alle Überprüfungen zum Entsperren des Bootloaders immer „false“ zurückgibt. Diese Methode zur Umgehung der Bootloader-Entsperrerkennung von SafetyNet hat für Magisk in den letzten Jahren funktioniert, aber das liegt nur daran, dass Google die Integrität des Boot-Images mithilfe der Hardwarebescheinigung nicht überprüft hat. Im März schien es, als würde Google endlich anfangen, Hardware-Atteste in SafetyNet einzusetzen, um das Boot-Image zu überprüfen, aber wir haben nie eine offizielle Erklärung von Google erhalten, die die Änderung bestätigt, und nur wenige Benutzer waren betroffen. Wie von XDA Senior Member Displax festgestellt, bestätigte Google jedoch am 5. Mai 2020, dass die Antworten der SafetyNet Attestation API einiger Geräte jetzt hardwarebasierte Überprüfungen enthalten.

In der Google-Gruppe für „SafetyNet API-Clients“ hat Google eine neue Funktion für die Attestierungs-API detailliert beschrieben: evaluationType. Die JSON Web Signature (JWS) -Antwort einiger Geräte enthält ein Feld mit dem Namen „evaluationType“, das Entwicklern einen Einblick in die Arten von Signalen / Messungen gibt, die zu jeder einzelnen SafetyNet Attestation API-Antwort beigetragen haben.“ Eines der unterstützten Token in diesem Feld ist „HARDWARE_BACKED“, das angibt, dass die API die verfügbaren hardwarebasierten Sicherheitsfunktionen des Remote-Geräts (z. B. hardwarebasierte Schlüsselbestätigung) verwendet, um die Bewertung zu beeinflussen.“ Google sagt, dass sie „derzeit die Zulassungskriterien für Geräte bewerten und anpassen, bei denen wir uns auf hardwarebasierte Sicherheitsfunktionen verlassen werden.“ Dies bedeutet, dass Google Play Services auf einigen Geräten jetzt eine hardwarebasierte Bescheinigung verwendet, um festzustellen, dass die Software des Geräts nicht manipuliert wurde. Google hat diese Änderung außerhalb der Ankündigung in der Google-Gruppe nicht offiziell dokumentiert, sodass einige Entwickler, die SafetyNet verwenden, diese Änderung möglicherweise nicht kennen (und daher in JWS noch nicht nach dem Feld „HARDWARE_BACKED“ suchen).) Für die Apps, die nach diesem Feld suchen, gibt es jetzt keine Möglichkeit, den Root-Zugriff vor ihnen zu verbergen, vorausgesetzt, Ihr Gerät ist Teil des Tests, den Google ausführt.

SafetyNet Attestation API-Antwort mit evaluationType, die „BASIC“ zurückgibt.“ Kredit: XDA Senior Mitglied Displax
 SafetyNet-Antwort BASIC und HARDWARE_BACKED
SafetyNet Attestation API-Antwort mit evaluationType, die „BASIC“ und „HARDWARE_BACKED“ zurückgibt.“ Credits: XDA Senior Member Displax

Laut topjohnwu bedeutet eine hardwarebasierte Bescheinigung, dass Google Play Services jetzt ein unverändertes Keystore-Zertifikat an SafetyNet-Server, seine Legitimität und Zertifikaterweiterungsdaten sendet, um zu erfahren, ob Ihr Gerät bootfähig ist (Bootloader-Status).“ Da die privaten Schlüssel, von denen die Keystore-Zertifikate abgeleitet sind, von der isolierten sicheren Umgebung des Telefons unterstützt werden, würde das Abrufen die Sicherheit der vertrauenswürdigen Ausführungsumgebung (TEE) oder des dedizierten Hardware-Sicherheitsmoduls (HSM) des Telefons beeinträchtigen. Wenn man irgendwie in der Lage wäre, einen privaten Schlüssel zu verlieren, würden die Schlüssel schnell widerrufen, sobald Google es herausgefunden hätte. Google bietet Hunderttausende von Dollar in Belohnungen für kritische Sicherheitslücken, die die HARDWARE in Pixel-Handys betreffen, was nur zeigt, dass es unglaublich unwahrscheinlich ist, dass dies ein potenzieller Weg ist, um die Bootloader-Entsperrerkennung sowieso zu umgehen.

Eine weitere Möglichkeit, wie Magisk den Entsperrstatus des Bootloaders weiterhin fälschen könnte, besteht darin, den clientseitigen Code von SafetyNet so zu ändern, dass immer die GRUNDLEGENDE Auswertung verwendet wird. Wie topjohnwu jedoch feststellt, müsste dazu benutzerdefinierter Code über ein Hooking-Framework wie das Xposed-Framework in Google Play-Dienste eingefügt werden. Dies ist nicht nur schwierig, da die Google Play-Dienste stark verschleiert sind, sondern es ist auch unmöglich, sie zu verbergen, da „einige Speicherplatzanalysen die Codemanipulation sehr leicht aufdecken.“ Darüber hinaus würde dies auch nur funktionieren, wenn die Server von Google weiterhin GRUNDLEGENDE Auswertungen akzeptieren und HARDWARE_BACKED-Auswertungen auf Geräten, die sie unterstützen, nicht erzwungen werden. (SafetyNet-Antworten “ von Google-Servern und sind laut topjohnwu mit dem privaten Schlüssel von Google signiert“, sodass die tatsächlichen Antworten nicht gefälscht werden können.)

Seit Android 7 Nougat hat Google verlangt, dass alle Geräte über eine isolierte sichere Umgebung verfügen, was bedeutet, dass diese Änderung der Art und Weise, wie SafetyNet das Entsperren des Bootloaders überprüft, die meisten Geräte betrifft, die es gibt. Da ältere Geräte ohne eine isolierte sichere Umgebung offensichtlich keine hardwarebasierte Zertifizierung durchführen können, kann Magisk den Root-Zugriff auf diesen Geräten weiterhin verbergen. Aber wenn diese Änderung weit verbreitet ist, müssen alle anderen eine harte Wahl zwischen Root-Zugriff und Banking-Apps treffen.

Leider gibt es wahrscheinlich viele Apps, die SafetyNet-Checks verwenden, wenn dies nicht erforderlich ist. Ein von topjohnwu zitiertes Beispiel ist die offizielle McDonald’s-App, die sich scheinbar weigert, auf einem Bootloader-entsperrten Gerät zu laufen. Auf Twitter ruft topjohnwu Apps auf, die die API überbeanspruchen, um eine feindliche Umgebung für Power-User zu schaffen. XDA anerkannter Entwickler Quinny899 schließt sich mit einer Anekdote darüber, wie sein Team mit SafetyNet betrachtet den Gerätesicherheitsstatus zu überprüfen. Sie beschlossen schließlich, es nicht zu tun, da die App seines Teams alle sensiblen Daten verschlüsselt, mit denen es arbeitet. SafetyNet, argumentiert er, sollte nicht anstelle von angemessenen Sicherheits- und Datenverarbeitungspraktiken verwendet werden, insbesondere wenn die Möglichkeit von Superuser-Exploits in Betracht gezogen wird.

Ich befürworte @AndroidDev, die hardwarebasierte SafetyNet-Auswertung auf „echte“ sicherheitsrelevante Apps zu beschränken. Entwickler sollten einen Bewerbungsprozess durchlaufen, um diese Stufe des API-Zugriffs zu qualifizieren. Es ist lächerlich für McDonalds, sich zu weigern, auf einem Bootloader-entsperrten Gerät zu laufen.

– John Wu (@topjohnwu) Juni 29, 2020

Weitere Informationen darüber, wie sich die neue SafetyNet-Änderung auf Magisk auswirkt, finden Sie in den hervorragenden FAQ von topjohnwu auf Twitter. Wenn Sie nur überprüfen möchten, ob Ihr Gerät Teil des neuen SafetyNet-Tests von Google ist, können Sie dieser Anleitung von XDA Senior Member Displax folgen oder die neueste Magisk Manager-Version herunterladen.

Magisk-Manager wurde aktualisiert, um das Feld evaluationType in SafetyNet-Prüfungen widerzuspiegeln, damit die Benutzer die letzten Tage des Ruhms zählen können 😅 pic.twitter.com/x61tGjM7IK

– John Wu (@topjohnwu) Juni 30, 2020

Dieser Artikel wurde am 30. Juni 2020 um 10:46 Uhr EST aktualisiert, um zu korrigieren, dass Google nur Belohnungen für die in Pixel-Telefonen gefundenen Sicherheitslücken auszahlt. Darüber hinaus wurden Details zur neuesten Magisk Manager-Version hinzugefügt, die jetzt das Feld evaluationType im integrierten SafetyNet Checker anzeigt.

Lesen Sie dies als nächstes


  • Google gründet Android Ready SE Alliance, um die Einführung digitaler Autoschlüssel und Führerscheine voranzutreiben


  • Fairphone 2 von 2015 erhält jetzt offizielles Update auf Android 9 Pie


  • Motorolas Moto G50 hat einen günstigen 5G-Chip und einen niedrigen Preis


  • ASUS veröffentlicht neue Updates für das ROG Phone 5, ROG Phone 3 und ROG Phone II mit Sicherheitspatches und Fehlerbehebungen


«

+