# Instalar Certificado Burp
Aprenda hacking AWS do zero ao avançado com htARTE (HackTricks AWS Red Team Expert)! Outras formas de apoiar o HackTricks: * Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com) * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
{% embed url="https://websec.nl/" %} ## Em uma Máquina Virtual Primeiramente, você precisa baixar o certificado Der do Burp. Você pode fazer isso em _**Proxy**_ --> _**Opções**_ --> _**Importar/Exportar certificado CA**_ ![](<../../.gitbook/assets/image (367).png>) **Exporte o certificado no formato Der** e vamos **transformá-lo** em um formato que o **Android** será capaz de **entender.** Note que **para configurar o certificado burp na máquina Android no AVD** você precisa **executar** esta máquina **com** a opção **`-writable-system`**.\ Por exemplo, você pode executá-lo assim: {% code overflow="wrap" %} ```bash C:\Users\\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system ``` {% endcode %} Em seguida, para **configurar o certificado do burp**, faça o seguinte: {% code overflow="wrap" %} ```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 ``` {% endcode %} Uma vez que a **máquina terminar de reiniciar**, o certificado do Burp estará em uso por ela! ## Usando Magisc Se você **rootou seu dispositivo com Magisc** (talvez um emulador), e você **não consegue seguir** os **passos anteriores** para instalar o certificado do Burp porque o **sistema de arquivos é somente leitura** e você não pode remontá-lo como gravável, há outra maneira. Explicado neste [**vídeo**](https://www.youtube.com/watch?v=qQicUW0svB8) você precisa: 1. **Instalar um certificado CA**: Apenas **arraste e solte** o certificado DER do Burp **alterando a extensão** para `.crt` no celular para que seja armazenado na pasta Downloads e vá para `Instalar um certificado` -> `Certificado CA`
* Verifique se o certificado foi armazenado corretamente indo para `Credenciais confiáveis` -> `USUÁRIO`
2. **Torná-lo confiável pelo sistema**: Baixe o módulo Magisc [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (um arquivo .zip), **arraste e solte** no telefone, vá para o aplicativo **Magics** no telefone para a seção **`Módulos`**, clique em **`Instalar do armazenamento`**, selecione o módulo `.zip` e uma vez instalado **reinicie** o telefone:
* Após reiniciar, vá para `Credenciais confiáveis` -> `SISTEMA` e verifique se o certificado do Postswigger está lá
## Pós Android 14 No lançamento mais recente do Android 14, observou-se uma mudança significativa no tratamento de certificados de Autoridade de Certificação (CA) confiáveis pelo sistema. Anteriormente, esses certificados estavam localizados em **`/system/etc/security/cacerts/`**, acessíveis e modificáveis por usuários com privilégios de root, o que permitia a aplicação imediata em todo o sistema. No entanto, com o Android 14, o local de armazenamento foi movido para **`/apex/com.android.conscrypt/cacerts`**, um diretório dentro do caminho **`/apex`**, que é imutável por natureza. Tentativas de remontar o caminho **APEX cacerts** como gravável são frustradas, pois o sistema não permite tais operações. Mesmo tentativas de desmontar ou sobrepor o diretório com um sistema de arquivos temporário (tmpfs) não contornam a imutabilidade; aplicativos continuam acessando os dados de certificado originais, independentemente de alterações no nível do sistema de arquivos. Essa resiliência se deve à montagem **`/apex`** ser configurada com propagação PRIVADA, garantindo que quaisquer modificações dentro do diretório **`/apex`** não afetem outros processos. A inicialização do Android envolve o processo `init`, que, ao iniciar o sistema operacional, também inicia o processo Zygote. Esse processo é responsável por lançar processos de aplicativos com um novo namespace de montagem que inclui uma montagem privada **`/apex`**, isolando assim as alterações neste diretório de outros processos. No entanto, existe uma solução alternativa para aqueles que precisam modificar os certificados CA confiáveis pelo sistema dentro do diretório **`/apex`**. Isso envolve remontar manualmente o **`/apex`** para remover a propagação PRIVADA, tornando-o gravável. O processo inclui copiar o conteúdo de **`/apex/com.android.conscrypt`** para outra localização, desmontar o diretório **`/apex/com.android.conscrypt`** para eliminar a restrição de somente leitura e, em seguida, restaurar o conteúdo para sua localização original dentro de **`/apex`**. Esta abordagem requer ação rápida para evitar falhas no sistema. Para garantir a aplicação dessas alterações em todo o sistema, é recomendável reiniciar o `system_server`, o que efetivamente reinicia todos os aplicativos e coloca o sistema em um 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" ``` ### Montagem de ligação através do NSEnter 1. **Configurar um Diretório Gravável**: Inicialmente, um diretório gravável é estabelecido montando um `tmpfs` sobre o diretório existente de certificados do sistema não-APEX. Isso é alcançado com o seguinte comando: ```bash mount -t tmpfs tmpfs /system/etc/security/cacerts ``` 2. **Preparando Certificados CA**: Após configurar o diretório gravável, os certificados CA que se pretende usar devem ser copiados para este diretório. Isso pode envolver copiar os certificados padrão de `/apex/com.android.conscrypt/cacerts/`. É essencial ajustar as permissões e rótulos SELinux desses certificados adequadamente. 3. **Montagem de Bind para Zygote**: Utilizando `nsenter`, entra-se no namespace de montagem do Zygote. O Zygote, sendo o processo responsável por iniciar aplicativos Android, requer este passo para garantir que todos os aplicativos iniciados daqui em diante utilizem os certificados CA recém-configurados. O comando usado é: ```bash nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts ``` Isso garante que todo novo aplicativo iniciado seguirá a configuração atualizada de certificados CA. 4. **Aplicando Alterações aos Aplicativos em Execução**: Para aplicar as alterações aos aplicativos que já estão em execução, `nsenter` é novamente usado para entrar individualmente no namespace de cada aplicativo e realizar uma montagem de bind semelhante. O comando necessário é: ```bash nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts ``` 5. **Abordagem Alternativa - Reinicialização Suave**: Um método alternativo envolve realizar o bind mount no processo `init` (PID 1) seguido por uma reinicialização suave do sistema operacional com os comandos `stop && start`. Esta abordagem propagaria as alterações em todos os namespaces, evitando a necessidade de abordar individualmente cada aplicativo em execução. No entanto, este método geralmente é menos preferido devido ao inconveniente de reinicialização. ## Referências * [https://httptoolkit.com/blog/android-14-install-system-ca-certificate/](https://httptoolkit.com/blog/android-14-install-system-ca-certificate/)
{% embed url="https://websec.nl/" %}
Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras maneiras de apoiar o HackTricks: * Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.