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 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, 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

Exporta el certificado en formato Der 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

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!

Using Magisc

Si rooteaste tu dispositivo con Magisc (quizá un emulador), y no puedes seguir los pasos anteriores para instalar el Burp cert porque el filesystem es de solo lectura y no puedes remontarlo como escribible, hay otra forma.

Explicado en este video necesitas:

1. Install a CA certificate: Simplemente arrastrar&soltar el DER Burp certificate cambiando la extensión a .crt en el móvil para que se almacene 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. Make it System trusted: Descarga el módulo Magisc MagiskTrustUserCerts (un archivo .zip), arrástralo&solta en el teléfono, entra en la app Magics del teléfono en la sección Modules, haz clic en Install from storage, selecciona el módulo .zip y una vez instalado reincia el teléfono:

• Después del reinicio, ve a Trusted credentials -> SYSTEM y verifica que el Postswigger cert esté ahí

Learn how to create a Magisc module

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

Post Android 14

En la más reciente versión Android 14, se ha observado un cambio significativo en el manejo de los certificados de autoridad (CA) de confianza del 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 APEX cacerts path como escribible fallan, ya que el sistema no permite tales operaciones. Incluso los intentos de desmontar o sobreponer el directorio con un sistema de archivos temporal (tmpfs) no evitan la inmutabilidad; las aplicaciones siguen accediendo a los datos de certificado originales sin importar los cambios a nivel de sistema de archivos. Esta resistencia se debe a que el montaje de /apex está configurado con PRIVATE propagation, 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 iniciar el sistema operativo también lanza el proceso Zygote. Este proceso es responsable de lanzar los procesos de las aplicaciones con un nuevo mount namespace que incluye un montaje privado de /apex, aislando así los cambios en este directorio del resto de los procesos.

No obstante, existe una solución para quienes necesitan modificar los certificados CA de confianza del sistema dentro del directorio /apex. Esto implica remontar manualmente /apex para eliminar la PRIVATE propagation, 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 asegurar que los cambios se apliquen en todo el sistema, se recomienda reiniciar el system_server, lo que efectivamente reinicia todas las aplicaciones y lleva el 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

1. Configuración de un directorio escribible: Inicialmente, se crea 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

2. Preparing CA Certificates: Tras configurar el directorio escribible, los certificados CA que se pretendan usar deben copiarse en este directorio. Esto puede implicar copiar los certificados predeterminados desde /apex/com.android.conscrypt/cacerts/. Es esencial ajustar los permisos y las etiquetas SELinux de estos certificados en consecuencia.
3. Bind Mounting for Zygote: Utilizando nsenter, se accede al namespace de montaje de Zygote. Zygote, al ser el proceso responsable de lanzar las aplicaciones Android, requiere este paso para garantizar que todas las aplicaciones iniciadas a partir de entonces 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 garantiza que cada nueva app iniciada cumplirá con la configuración actualizada de certificados CA.

4. Aplicar cambios a las apps en ejecución: Para aplicar los cambios a las aplicaciones que ya están en ejecución, se vuelve a usar nsenter 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. Enfoque alternativo - Reinicio suave: Un método alternativo consiste en realizar el bind mount en el proceso init (PID 1) seguido de un reinicio suave 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

• 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