Install Burp Certificate
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
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í:
Luego, para configurar el certificado de burp haz:
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), arrastra y suelta 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.
Sin embargo, 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.
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:
Preparando Certificados CA: Después de configurar el directorio escribible, los certificados CA que se pretende utilizar deben ser copiados en 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
, uno entra en el 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:
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 ingresar al espacio de nombres de cada aplicación individualmente y realizar un montaje de enlace similar. El comando necesario es:
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
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Last updated