Instalar certificado de Burp

Reading time: 9 minutes

Proxy a nivel del sistema vía ADB

Configura un proxy HTTP global para que todas las aplicaciones 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, vincula tu 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

Export the certificate in Der format y vamos a transformarlo a una forma que Android pueda 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 ejecutarla 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:

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 la misma!

Usando Magisc

Si rooteaste tu dispositivo con Magisc (tal vez 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 remontarlo como escribible, hay otra manera.

Explicado en este video necesitas:

1. Instala 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 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

2. Hazlo System trusted: Descarga el módulo Magisc MagiskTrustUserCerts (un .zip), arrástralo y suéltalo en el teléfono, abre la app Magics en el teléfono en la sección Modules, haz clic en Install from storage, selecciona el módulo .zip y, una vez instalado, reinicia el teléfono:

• Después del reinicio, ve a Trusted credentials -> SYSTEM y comprueba que el certificado Postswigger esté allí

Aprende cómo crear un módulo Magisc

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) confiables por el sistema. Anteriormente, estos certificados residían 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 ha movido a /apex/com.android.conscrypt/cacerts, un directorio dentro de la ruta /apex, que es inmutable por naturaleza.

Los intentos de remontar la ruta APEX de cacerts como escribible fracasan, ya que el sistema no permite esas operaciones. Incluso los intentos de desmontar o superponer el directorio con un sistema de archivos temporal (tmpfs) no eluden la inmutabilidad; las aplicaciones siguen accediendo a los datos de certificados originales independientemente de los cambios a nivel de sistema de archivos. Esta resistencia se debe a que el montaje /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 es responsable 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 de otros procesos.

Sin embargo, existe una solución para quienes necesitan modificar los certificados CA confiables por el sistema dentro del directorio /apex. Esto implica remontar manualmente /apex para eliminar la propagación PRIVATE, haciéndolo así 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 los contenidos a su ubicación original dentro de /apex. Este método requiere acción rápida para evitar que el sistema se bloquee. Para asegurar que los cambios se apliquen en todo el sistema, se recomienda reiniciar el 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 through NSEnter

1. Configuración de un directorio escribible: Inicialmente, se crea un directorio escribible montando un tmpfs sobre el directorio de certificados del sistema non-APEX existente. Esto se logra con el siguiente comando:

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

2. Preparación de certificados CA: Tras configurar el directorio escribible, los certificados CA que se quieran usar deben copiarse a este directorio. Esto puede implicar copiar los certificados por defecto desde /apex/com.android.conscrypt/cacerts/. Es esencial ajustar los permisos y las etiquetas de SELinux de estos certificados en consecuencia.
3. Bind Mounting para Zygote: Utilizando nsenter, se entra en el espacio de nombres de montaje de Zygote. Zygote, al ser el proceso responsable de lanzar 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 usado 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 app iniciada respetará la configuración actualizada de los certificados CA.

4. Aplicando cambios a las apps en ejecución: Para aplicar los cambios a las apps ya en ejecución, nsenter se usa nuevamente para entrar en el namespace de cada app individualmente 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

5. Alternative Approach - Soft Reboot: Un método alternativo consiste en 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 molestia de reiniciar.

Referencias

• Android 14: Install a system CA certificate on a rooted device
• Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa