Frage:
Magisk wird das Sicherheitsnetz im Folgenden nicht erfüllen. Warum?
beeshyams
2020-03-12 13:25:04 UTC
view on stackexchange narkive permalink

Vor kurzem hat Google Sicherheitsänderungen vorgenommen, die sicherstellen, dass das bei der Installation von Magisk nicht überprüft wird.

Dies wurde von John Wu (Magisk-Entwickler), , getwittert hier und hier. Einige Auszüge:

Nachdem wir jahrelang mit Magisk herumgespielt haben, scheint es, dass Google ENDLICH beschlossen hat, SafetyNet auf etwas Nützliches zu "reparieren", und das heißt, die Schlüsselbescheinigung zu verwenden Überprüfen Sie den Gerätestatus (nach 3 Jahren seit Einführung auf der Android-Plattform!)

Seien wir ehrlich. Spaß ist vorbei Jungs.

(Hervorhebung hinzugefügt)

Bearbeiten: Von Github

MagiskHide standardmäßig deaktivieren

Da SafetyNet CTS nicht erreicht werden kann, erfüllt das standardmäßige Aktivieren von MagiskHide keinen Zweck mehr.

Weitere Informationen zu den neuesten SafetyNet-Änderungen finden Sie unter: https://twitter.com/topjohnwu/status/1237656703929180160 https://twitter.com/topjohnwu/status/ 1237830555523149824

Die Funktionen von MagiskHide bleiben im Magisk-Projekt erhalten, da Änderungen im Benutzerbereich (einschließlich der grundlegenden Integritätsprüfung von SafetyNet) weiterhin äußerst effektiv ausgeblendet werden können.

Zukünftige Verbesserungen von MagiskHide mag kommen, aber da der heilige Gral genommen wurde, hat jede Form der Verbesserung jetzt eine sehr niedrige Priorität.

Es scheint mir, dass Google dies hätte tun können / sollten Dies wurde früher implementiert, aber nicht implementiert, und die CTS-Prüfung wurde ab durchgeführt innerhalb von Magisk war nicht umfassend.

Bitte entmystifizieren Sie dies in einfachen Worten (soweit möglich) für Leute, die die Innereien von Android nicht verstehen (wie ich).

Wenn ich es von den Tweets richtig bekomme, wird der Status des entsperrten Bootloaders jetzt durch den Code bestimmt, der im TEE ausgeführt wird, einem Sicherheitsteil, der in den meisten ARM-CPUs verfügbar ist und gegen Manipulationen geschützt ist.Auch der darin ausgeführte Code kann nicht geändert werden.Dieser Code überprüft irgendwie den Bootloader-Status und bereitet die an Google gesendeten signierten Daten vor.Der Google-Server entscheidet dann, ob Ihre Geräte die Prüfung bestehen oder nicht.
@Robert Ja, aber ich versuche mehr darüber zu verstehen, warum jetzt Vs früher, als anscheinend ein Mechanismus vorhanden war.Außerdem wurde die frühere CTS-Prüfung auch von einem Server durchgeführt, von dem ich dachte, dass es sich um Google handelt.Wie gesagt, für Dummies vereinfachen!
Nach meinem Verständnis besteht das Hauptproblem darin, dass die Bootloader-Prüfung in das TEE verschoben wurde und nur dort ausgeführt werden kann (bevor sie außerhalb von TEE ausgeführt wurde?).TEE ist wie ein separates Betriebssystem, wir haben kein Root-Betriebssystem und es wird nur signierter Code ausgeführt.Daher können Sie die Prüfung nicht ändern oder manipulieren.Sie können nur entscheiden, es nicht auszuführen.
Irgendwie ist das noch nicht wahr.Bin auf Android 10, 5. März Sicherheitsupdate, Magisk und EdXposed installiert.Und SafetyNet geht immer noch vorbei.
@OtnielYoreiza Ja, es wurde berichtet, dass ältere Android-Versionen in einigen Fällen noch nicht betroffen sind.Ich bin in Ihrem Fall wenig überrascht.Haben Sie versucht, eine App zu installieren, die nicht funktioniert, wenn das Sicherheitsnetz defekt ist - zur doppelten Überprüfung (Magisk-Überprüfung ist manchmal fehlerhaft)
Zwei antworten:
#1
+3
beeshyams
2020-06-29 15:08:29 UTC
view on stackexchange narkive permalink

John Wu hat heute Updates veröffentlicht, in denen die Gründe erläutert werden.

Früher war die SafetyNet-API nicht vollständig / korrekt implementiert, wie sie eigentlich sein sollte:

blockquote>

Nach dem, was wir bisher gesehen haben, scheint die Schlüsselbescheinigung nicht zu sein noch vollständig durchgesetzt werden, da Geräte mit inkompatiblen, möglicherweise fehlerhaften (?) Keymaster-Implementierungen (z. B. einige OnePlus-Geräte), die zu Attest-Schlüssel-Cmd-Fehlern führen, SafetyNet trotzdem bestehen.

blockquote>

Der Bootloader meldet den Gerätestatus über Kernel-cmdlines, und init spiegelt sie in den Eigenschaften wider, und anscheinend wurde SafetyNet verwendet diese Werte. All diese Dinge befinden sich im Benutzerbereich, sodass Magisk sie einfach bearbeiten kann.

Jetzt mit der Funktionsvorschau: SafetyNet Attestation API EvaluationType. Es gibt zwei Arten der Auswertung: BASIC und HARDWARE_BACKED für eine vollständige Auswertung mit Fernvalidierung (im Gegensatz zu lokal):

HARDWARE_BACKED - Wenn wir die verfügbaren hardwareunterstützten Sicherheitsfunktionen des Remote-Geräts (z. B. hardwareunterstützte Schlüsselbescheinigung) verwenden, um unsere Bewertung zu beeinflussen.

Wir ' Derzeit werden die Zulassungskriterien für Geräte evaluiert und angepasst, bei denen wir auf hardwaregestützte Sicherheitsfunktionen angewiesen sind.

Kann dieses neue System gehackt werden?

Sieht sehr unwahrscheinlich aus

IMO ist es theoretisch möglich, die Steuerung fl zu ändern Der Code von SafetyNet zwingt ihn dazu, immer die BASIC-Auswertung zu verwenden, indem ein Hooking-Framework wie Xposed verwendet wird. Diese Art der Code-Injection ist jedoch grundsätzlich nicht zu verbergen (Speicherplatzanalyse).

Um dieses Ding zu hacken, müssen Sie entweder eine Sicherheitslücke in der TEE-Firmware finden (die gepatcht wird) ASAP einmal gefunden) oder Hardware (weniger wahrscheinlich), um die Kryptographie zu brechen.

TEE zu brechen wird nicht einfach sein, weshalb viele Sicherheitsforscher arbeiten aktiv daran.

(Hervorhebung in allen Anführungszeichen hinzugefügt)

Fazit: SafetyNet mit Magisk ist Geschichte (at zumindest in naher Zukunft) ....

Wie überprüfe ich, ob Google Hardware-Attestierung für mein Gerät implementiert hat?

Bearbeiten Magisk Canary wurde auf aktualisiert Zeigen Sie den Evaluierungsstatus an. Sobald die API implementiert ist, werden weitere Details angezeigt (Fehler bei SafetyNet). Oder befolgen Sie die Anweisungen in diesem XDA-Beitrag, um die Bescheinigungsmethode mit logcat zu überprüfen

enter image description here

Weitere Informationen finden Sie unter Die Hardwarebescheinigung von SafetyNet macht es wirklich schwierig, Root in Magisk zu verstecken

Wenn ich ein Gerät mit entsperrtem Bootloader habe, das aber noch nicht gerootet ist (was bedeutet, dass die Boot-Partition auf Lager ist), besteht mein Gerät die Prüfung der HARDWARE_BACKED-Bescheinigung trotzdem nicht?Es wäre großartig, wenn Sie Ihre Antwort so bearbeiten könnten, dass sie dies einschließt.
@Gokul NC Natürlich nicht!Es sei denn, Ihr Gerät ist nicht CTS-gelöscht. Dies ist nur dann der Fall, wenn Sie ein sehr billiges Gerät haben
Okay.Ich habe noch einen Zweifel;Entschuldigung für meine Unwissenheit.Angenommen, mein Gerät hat die SafetyNet-Prüfung "HARDWARE_BACKED" nicht bestanden.Jetzt versucht meine Bankanwendung, die API "SafetyNet Attestation" mit einer vorhandenen Methode aufzurufen.Was passiert, wenn ich einen Xposed-Hook schreibe, um die Methode meiner Bank-App abzufangen, die für den Aufruf der Attestation Check API verantwortlich ist, und den Codepfad der Methode so ändere, dass die App den Aufruf der SafetyNet Attestation API selbst umgeht?
Unmöglich für Xposed.TEE führt seinen eigenen Code ** völlig isoliert ** aus (siehe den Link von TEE).Eine andere Möglichkeit, Hardware zu ändern, die Xposed in fast keiner Weise kann oder nicht.Aus diesem Grund sagt Topjohnwu: * Um dieses Ding zu hacken, müssen Sie entweder eine Sicherheitslücke in der TEE-Firmware (die so schnell wie möglich gepatcht wird) oder in der Hardware (weniger wahrscheinlich) finden, um die Kryptografie zu beschädigen.Dasselbe wird in dem XDA-Artikel erwähnt, der am Ende der Antwort verlinkt ist
#2
+2
auspicious99
2020-05-31 19:06:27 UTC
view on stackexchange narkive permalink

Es scheint, dass Google diese Überprüfung möglicherweise nicht erzwungen hat, obwohl sie für kurze Zeit (einige Tage?) implementiert wurde. Zuerst klang der Magisk-Entwickler John Wu ziemlich pessimistisch und ging sogar so weit zu sagen, dass der Spaß vorbei war.

Einige Tage nach den Tweets von John Wu, auf die in der verwiesen wurde Frage jedoch, am 14. März hat John Wu erneut getwittert, und diesmal sagte er

Also geht CTS anscheinend einfach wieder aus dem Nichts? Vielleicht testet Google immer noch Dinge?

Ich bin sowieso drüber hinweg. Google ist offenbar bereit, die Schlüsselbescheinigung zur Erkennung zu verwenden. Da MagiskHide immer noch vorhanden ist, können die Benutzer es weiterhin wie gewohnt verwenden.

In meinem eigenen Test Ende Mai 2020, bei dem MagiskHide nicht aktiviert war, schlug SafetyNet fehl, aber MagiskHide war aktiviert und zielte darauf ab Test-App, SafetyNet bestanden, was bedeutet, dass MagishHide SafetyNet immer noch besiegen konnte. Der Test wurde auf einem Pixel 3 mit Android 10 ausgeführt.

Google kann also möglicherweise Magisk erkennen, da die Bootloader-Prüfung in das TEE verschoben wurde, aber das haben sie irgendwie eingestellt. aus Gründen, die nur Google bekannt sind.

Updates finden Sie unter [Antwort hier] (https://android.stackexchange.com/a/226340/131553)
Vielen Dank, ich habe heute auch John Wus Tweet gesehen, der auf https://groups.google.com/forum/#!topic/safetynet-api-clients/lpDXBNeV7Fg verweist


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...