Install Burp Certificate

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)

Apoya a HackTricks

Revisa los planes de suscripción!
Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.

Websec | Uw Cybersecurity Specialist

En una Máquina Virtual

Primero que nada, necesitas descargar el certificado Der de Burp. Puedes hacer esto en Proxy --> Options --> Importar / Exportar certificado CA

Exporta el certificado en formato Der y vamos a transformarlo a una forma que Android va a poder entender. Ten en cuenta que para configurar el certificado de burp en la máquina Android en AVD necesitas ejecutar esta máquina con la opción -writable-system. Por ejemplo, puedes ejecutarlo así:

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

Luego, para configurar el certificado de burp haz:

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 por ella!

Usando Magisc

Si has rooteado tu dispositivo con Magisc (quizás un emulador), y no puedes seguir los pasos anteriores para instalar el certificado de Burp porque el sistema de archivos es de solo lectura y no puedes volver a montarlo como escribible, hay otra forma.

Explicado en este video necesitas:

Instalar un certificado CA: Simplemente arrastra y suelta el certificado DER de Burp cambiando la extensión a .crt en el móvil para que se almacene en la carpeta de Descargas y ve a Instalar un certificado -> Certificado CA

Verifica que el certificado se haya almacenado correctamente yendo a Credenciales de confianza -> USUARIO

Hacerlo de confianza del sistema: Descarga el módulo de Magisc MagiskTrustUserCerts (un archivo .zip), arrastra y suelta en el teléfono, ve a la app de Magics en el teléfono a la sección Módulos, haz clic en Instalar desde almacenamiento, selecciona el módulo .zip y una vez instalado reinicia el teléfono:

Después de reiniciar, ve a Credenciales de confianza -> SISTEMA y verifica que el certificado de Postswigger esté allí

Post Android 14

En la última versión de Android 14, se ha observado un cambio significativo en el manejo de los certificados de Autoridad de Certificación (CA) de confianza del sistema. Anteriormente, estos certificados se encontraban en /system/etc/security/cacerts/, accesibles y modificables por usuarios con privilegios de root, lo que permitía su aplicación inmediata en todo el sistema. Sin embargo, con Android 14, la ubicación de almacenamiento se ha trasladado a /apex/com.android.conscrypt/cacerts, un directorio dentro de la ruta /apex, que es inmutable por naturaleza.

Los intentos de volver a montar la ruta APEX cacerts como escribible fracasan, ya que el sistema no permite tales operaciones. Incluso los intentos de desmontar o superponer el directorio con un sistema de archivos temporal (tmpfs) no eluden la inmutabilidad; las aplicaciones continúan accediendo a los datos del certificado original independientemente de los cambios a nivel de sistema de archivos. Esta resistencia se debe a que el montaje de /apex está configurado con propagación PRIVADA, asegurando que cualquier modificación dentro del directorio /apex no afecte a otros procesos.

La inicialización de Android implica el proceso init, que, al iniciar el sistema operativo, también inicia el proceso Zygote. Este proceso es responsable de lanzar procesos de aplicación con un nuevo espacio de nombres de montaje que incluye un montaje privado de /apex, aislando así los cambios en este directorio de otros procesos.

Sin embargo, existe una solución para aquellos que necesitan modificar los certificados CA de confianza del sistema dentro del directorio /apex. Esto implica volver a montar manualmente /apex para eliminar la propagación PRIVADA, haciéndolo 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 acción rápida para evitar fallos del sistema. Para asegurar la aplicación de estos cambios en todo el sistema, se recomienda reiniciar el system_server, lo que reinicia efectivamente todas las aplicaciones y lleva al sistema a 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 through NSEnter

Configurando un Directorio Escribible: Inicialmente, se establece un directorio escribible montando un tmpfs sobre el directorio de certificados del sistema no-APEX existente. Esto se logra con el siguiente comando:

mount -t tmpfs tmpfs /system/etc/security/cacerts

Preparando Certificados CA: Después de configurar el directorio escribible, los certificados CA que se pretende utilizar deben ser copiados en este directorio. Esto puede implicar copiar los certificados predeterminados de /apex/com.android.conscrypt/cacerts/. Es esencial ajustar los permisos y las etiquetas SELinux de estos certificados en consecuencia.
Montaje Bind para Zygote: Utilizando nsenter, uno entra en el espacio de nombres de montaje de Zygote. Zygote, siendo el proceso responsable de lanzar aplicaciones de Android, requiere este paso para asegurar que todas las aplicaciones iniciadas a partir de ahora utilicen los certificados CA recién configurados. El comando utilizado es:

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

Esto asegura que cada nueva aplicación iniciada se adherirá a la configuración actualizada de certificados CA.

Aplicando Cambios a Aplicaciones en Ejecución: Para aplicar los cambios a las aplicaciones que ya están en ejecución, se utiliza nuevamente nsenter para ingresar al espacio de nombres de cada aplicación individualmente y realizar un montaje de enlace similar. El comando necesario es:

nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

Enfoque Alternativo - Reinicio Suave: Un método alternativo implica realizar el montaje de enlace en el proceso init (PID 1) seguido de un reinicio suave del sistema operativo con los comandos stop && start. Este enfoque propagaría los cambios a través de todos los espacios de nombres, evitando la necesidad de abordar individualmente cada aplicación en ejecución. Sin embargo, este método es generalmente menos preferido debido a la inconveniencia de reiniciar.