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
- Check the subscription plans!
- Join the 馃挰 Discord group or the telegram group or follow us on Twitter 馃惁 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
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 aInstalar 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), 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 enInstalar 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.
# 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 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. - 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:
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 entrar en el 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 comandosstop && 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
- Check the subscription plans!
- Join the 馃挰 Discord group or the telegram group or follow us on Twitter 馃惁 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.