Instalar el Certificado de Burp

tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

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铆:

bash
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:

bash
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:

  1. 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
  1. Hacerlo de confianza del sistema: Descarga el m贸dulo de Magisc MagiskTrustUserCerts (un archivo .zip), arr谩stralo y su茅ltalo 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.

No obstante, 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.

bash
# 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. 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:
bash
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. Preparando Certificados CA: Despu茅s de configurar el directorio escribible, los certificados CA que se pretende utilizar deben ser copiados a 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.
  2. Montaje Bind para Zygote: Utilizando nsenter, se ingresa al 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:
bash
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.

  1. 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 entrar en el espacio de nombres de cada aplicaci贸n individualmente y realizar un montaje de enlace similar. El comando necesario es:
bash
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. 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.

Referencias

tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks