Español - Ht
HackTricks Training Twitter Linkedin Sponsor

Install Burp Certificate

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

En una Máquina Virtual

En primer lugar, necesitas descargar el certificado Der desde Burp. Puedes hacer esto en Proxy --> Options --> Import / Export CA certificate

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 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 haya terminado de reiniciarse, ¡el certificado de Burp estará en uso por ella!

Usando Magisc

Si rooteaste 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 volverlo a montar como escribible, hay otra forma.

Explicado en este video necesitas:

  1. Instalar un certificado de 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 de Descargas y ve a Instalar un certificado -> Certificado de CA

  • Verifica que el certificado se haya guardado 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 aplicación de Magisc 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 de cacerts de APEX 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 evitan 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 de /apex está configurado con propagación PRIVADA, asegurando que cualquier modificación dentro del directorio de /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 montaje que incluye un montaje privado de /apex, aislando así los cambios en este directorio de otros procesos.

Sin embargo, existe un método alternativo para aquellos que necesitan modificar los certificados de CA de confianza del sistema dentro del directorio de /apex. Esto implica volver a montar manualmente /apex para eliminar la propagación PRIVADA, 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 el contenido a su ubicación original dentro de /apex. Este enfoque requiere una acción rápida para evitar bloqueos del sistema. Para garantizar 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 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"

Montaje de enlace a través de NSEnter

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

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

  1. Preparando Certificados de CA: Después de configurar el directorio escribible, los certificados de CA que se pretenden utilizar deben ser copiados en este directorio. Esto podría 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.

  2. Montaje de Enlace 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 en adelante utilicen los certificados de 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 adhiera a la configuración actualizada de certificados de CA.

  1. Aplicar Cambios a las Aplicaciones en Ejecución: Para aplicar los cambios a las aplicaciones que ya están en ejecución, se utiliza nuevamente nsenter para ingresar individualmente al espacio de nombres de cada aplicación 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

  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 generalmente es menos preferido debido a la incomodidad de reiniciar.

Referencias

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

AnteriorGoogle CTF 2018 - Shall We Play a Game?SiguienteIntent Injection

Última actualización