Instalar el certificado de Burp

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Revisa el catálogo completo de HackTricks Training para las rutas de evaluación (ARTA/GRTA/AzRTA) y Linux Hacking Expert (LHE).

Apoya a HackTricks

Proxy a nivel del sistema mediante ADB

Configura un proxy HTTP global para que todas las apps enruten el tráfico a través de tu interceptor (Burp/mitmproxy):

# Set proxy (device/emulator must reach your host IP)
adb shell settings put global http_proxy 192.168.1.2:8080

# Clear proxy
adb shell settings put global http_proxy :0

Consejo: En Burp, bind your listener a 0.0.0.0 para que los dispositivos en la LAN puedan conectarse (Proxy -> Options -> Proxy Listeners).

En una Máquina Virtual

Primero necesitas descargar el certificado Der desde Burp. Puedes hacerlo en Proxy –> Options –> Import / Export CA certificate

Exporta el certificado en formato Der y transformémoslo a una forma que Android vaya a poder entender. Ten en cuenta que para configurar el burp certificate en la máquina Android en AVD necesitas run esta máquina with la opción -writable-system.
Por ejemplo puedes runarla así:

C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system

Entonces, para configurar el certificado de burps, haz lo siguiente:

openssl x509 -inform DER -in burp_cacert.der -out burp_cacert.pem
CERTHASHNAME="`openssl x509 -inform PEM -subject_hash_old -in burp_cacert.pem | head -1`.0"
mv burp_cacert.pem $CERTHASHNAME #Correct name
adb root && sleep 2 && adb remount #Allow to write on /syste
adb push $CERTHASHNAME /sdcard/ #Upload certificate
adb shell mv /sdcard/$CERTHASHNAME /system/etc/security/cacerts/ #Move to correct location
adb shell chmod 644 /system/etc/security/cacerts/$CERTHASHNAME #Assign privileges
adb reboot #Now, reboot the machine

Una vez que la máquina termine de reiniciarse, ¡el certificado de Burp estará en uso!

Usando Magisk

Si has rooteado tu dispositivo con Magisk (quizá un emulador), y no puedes seguir los pasos anteriores para instalar el certificado de Burp porque el filesystem está en modo solo lectura y no puedes volver a montarlo en modo escritura, hay otra forma.

Explicado en este video necesitas:

  1. Instalar un CA certificate: Simplemente arrastra y suelta el certificado DER de Burp cambiando la extensión a .crt en el móvil para que se guarde en la carpeta Downloads y ve a Install a certificate -> CA certificate
  • Comprueba que el certificado se almacenó correctamente yendo a Trusted credentials -> USER
  1. Haz que sea System trusted: Descarga el Magisk module MagiskTrustUserCerts (un archivo .zip), arrástralo y suéltalo en el teléfono, abre la app Magisk en el teléfono y ve a la sección Modules, haz clic en Install from storage, selecciona el módulo .zip y una vez instalado reinicia el teléfono:
  • Tras el reinicio, ve a Trusted credentials -> SYSTEM y comprueba que el certificado Postswigger esté allí

Alternative: AlwaysTrustUserCerts (Android 7-16 Beta)

Si estás en Android 14+ (o en dispositivos más antiguos que recibieron actualizaciones Conscrypt Mainline y ahora usan /apex/com.android.conscrypt/cacerts), el Magisk module AlwaysTrustUserCerts automatiza el bind-mounting requerido para la confianza a nivel sistema. Replica las CAs de usuario en la confianza del sistema e inyecta mounts en los namespaces de Zygote/app para que las apps vean los certificados sin el trabajo manual de nsenter.

  1. Instala la Burp CA primero como certificado de usuario.
  2. Instala el módulo y reinicia.
  3. Si el módulo ofrece una opción, prefiere --rbind al montar /system/etc/security/cacerts dentro de /apex/com.android.conscrypt/cacerts para asegurar que los mounts anidados (de otros módulos) sean visibles.

Aprende a crear un módulo Magisk

Consulta https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437

Después de Android 14

En la última versión de Android 14 se ha observado un cambio significativo en el manejo de los certificados de Certificate Authority (CA) con confianza del sistema.

Nota: Algunos dispositivos con Android 12/13 que recibieron actualizaciones Conscrypt Mainline ya usan /apex/com.android.conscrypt/cacerts. Si ese directorio existe en tu dispositivo, debes usar la misma técnica de inyección APEX descrita más abajo.

Anteriormente, estos certificados se almacenaban en /system/etc/security/cacerts/, accesibles y modificables por usuarios con privilegios root, lo que permitía su aplicación inmediata en todo el sistema. Sin embargo, con Android 14, la ubicación de almacenamiento se movió a /apex/com.android.conscrypt/cacerts, un directorio dentro de la ruta /apex, que por su naturaleza es inmutable.

Los intentos de volver a montar la ruta APEX cacerts como escribible fracasan, ya que el sistema no permite tales operaciones. Incluso intentar desmontar u overlay el directorio con un sistema de archivos temporal (tmpfs) no elude la inmutabilidad; las aplicaciones siguen accediendo a los datos originales de los certificados sin importar los cambios a nivel de sistema de archivos. Esta resistencia se debe a que el montaje de /apex está configurado con propagación PRIVATE, lo que asegura que cualquier modificación dentro del directorio /apex no afecte a otros procesos.

La inicialización de Android involucra el proceso init, que al arrancar el sistema operativo también inicia el proceso Zygote. Este proceso se encarga de lanzar los procesos de las aplicaciones con un nuevo namespace de montaje que incluye un montaje privado de /apex, aislando así los cambios en este directorio del resto de procesos.

No obstante, existe una solución para quienes necesiten modificar los certificados CA de confianza del sistema dentro del directorio /apex. Esto implica remontar manualmente /apex para eliminar la propagación PRIVATE, haciendo que sea escribible. El proceso incluye copiar el contenido de /apex/com.android.conscrypt a otra ubicación, desmontar el directorio /apex/com.android.conscrypt para eliminar la restricción de solo lectura y luego restaurar el contenido a su ubicación original dentro de /apex. Este enfoque requiere actuar con rapidez para evitar fallos del sistema. Para garantizar que los cambios se apliquen en todo el sistema, se recomienda reiniciar system_server, lo que efectivamente reinicia todas las aplicaciones y deja el sistema en un estado consistente.

# Create a separate temp directory, to hold the current certificates
# Otherwise, when we add the mount we can't read the current certs anymore.
mkdir -p -m 700 /data/local/tmp/tmp-ca-copy

# Copy out the existing certificates
cp /apex/com.android.conscrypt/cacerts/* /data/local/tmp/tmp-ca-copy/

# Create the in-memory mount on top of the system certs folder
mount -t tmpfs tmpfs /system/etc/security/cacerts

# Copy the existing certs back into the tmpfs, so we keep trusting them
mv /data/local/tmp/tmp-ca-copy/* /system/etc/security/cacerts/

# Copy our new cert in, so we trust that too
mv $CERTIFICATE_PATH /system/etc/security/cacerts/

# Update the perms & selinux context labels
chown root:root /system/etc/security/cacerts/*
chmod 644 /system/etc/security/cacerts/*
chcon u:object_r:system_file:s0 /system/etc/security/cacerts/*

# Deal with the APEX overrides, which need injecting into each namespace:

# First we get the Zygote process(es), which launch each app
ZYGOTE_PID=$(pidof zygote || true)
ZYGOTE64_PID=$(pidof zygote64 || true)
# N.b. some devices appear to have both!

# Apps inherit the Zygote's mounts at startup, so we inject here to ensure
# all newly started apps will see these certs straight away:
for Z_PID in "$ZYGOTE_PID" "$ZYGOTE64_PID"; do
if [ -n "$Z_PID" ]; then
nsenter --mount=/proc/$Z_PID/ns/mnt -- \
/bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
fi
done

# Then we inject the mount into all already running apps, so they
# too see these CA certs immediately:

# Get the PID of every process whose parent is one of the Zygotes:
APP_PIDS=$(
echo "$ZYGOTE_PID $ZYGOTE64_PID" | \
xargs -n1 ps -o 'PID' -P | \
grep -v PID
)

# Inject into the mount namespace of each of those apps:
for PID in $APP_PIDS; do
nsenter --mount=/proc/$PID/ns/mnt -- \
/bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts &
done
wait # Launched in parallel - wait for completion here

echo "System certificate injected"

Bind-mounting a través de NSEnter

  1. Configuración de un directorio escribible: Inicialmente, se crea un directorio escribible montando un tmpfs sobre el directorio de certificados del sistema existente non-APEX. Esto se consigue con el siguiente comando:
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. Preparación de certificados CA: Tras configurar el directorio con permisos de escritura, los certificados CA que se quieran usar deben copiarse en ese directorio. Esto puede implicar copiar los certificados por defecto desde /apex/com.android.conscrypt/cacerts/. Es esencial ajustar los permisos y las etiquetas SELinux de estos certificados en consecuencia.
  2. Montaje bind para Zygote: Empleando nsenter, se entra en el namespace de montaje de Zygote. Zygote, siendo el proceso responsable de lanzar las aplicaciones Android, requiere este paso para asegurar que todas las aplicaciones iniciadas a partir de entonces utilicen los certificados CA recién configurados. El comando utilizado es:

Consejo: Si /system/etc/security/cacerts contiene montajes anidados (común con los módulos Magisk), use --rbind en lugar de --bind para que esos montajes se propaguen a los espacios de nombres de aplicaciones.

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
# If /system/etc/security/cacerts includes nested mounts, prefer --rbind
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --rbind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. Aplicar los cambios a aplicaciones en ejecución: Para aplicar los cambios a aplicaciones que ya están en ejecución, nsenter se utiliza de nuevo para entrar en el namespace de cada aplicación de forma individual y realizar un bind mount similar. El comando necesario es:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. Alternative Approach - Soft Reboot: Un método alternativo implica realizar el bind mount en el proceso init (PID 1), seguido de un soft reboot del sistema operativo con los comandos stop && start. Este enfoque propagará los cambios a través de todos los namespaces, evitando la necesidad de dirigirse individualmente a cada app en ejecución. Sin embargo, este método generalmente es menos preferido debido a la inconveniencia de reiniciar.

Referencias

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Revisa el catálogo completo de HackTricks Training para las rutas de evaluación (ARTA/GRTA/AzRTA) y Linux Hacking Expert (LHE).

Apoya a HackTricks