Instalar Certificado do Burp

Reading time: 9 minutes

Proxy em todo o sistema via ADB

Configure um proxy HTTP global para que todos os apps direcionem o tráfego através do seu interceptor (Burp/mitmproxy):

# Set proxy (device/emulator must reach your host IP)
adb shell settings put global http_proxy 192.168.1.2:8080

# Clear proxy
adb shell settings put global http_proxy :0

Dica: In Burp, bind your listener to 0.0.0.0 so devices on the LAN can connect (Proxy -> Options -> Proxy Listeners).

Em uma Máquina Virtual

Antes de tudo você precisa baixar o certificado Der do Burp. Você pode fazer isso em Proxy --> Options --> Import / Export CA certificate

Exporte o certificado em formato Der e vamos transformá-lo para uma forma que Android vai conseguir entender. Note que para configurar o certificado do burp na máquina Android em AVD você precisa executar essa máquina com a opção -writable-system.
Por exemplo você pode executá-la assim:

C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system

Então, para configurar o certificado do Burp, faça:

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

Assim que a máquina terminar de reiniciar o certificado do burp estará em uso por ela!

Using Magisc

Se você rootou seu dispositivo com Magisc (talvez um emulator), e você não consegue seguir os passos anteriores para instalar o certificado Burp porque o sistema de arquivos está somente leitura e você não consegue remountá-lo como gravável, existe outra forma.

Explicado em this video você precisa:

1. Instalar um CA certificate: Basta arrastar&soltar o certificado DER Burp alterando a extensão para .crt no celular para que ele seja armazenado na pasta Downloads e ir para Install a certificate -> CA certificate

• Verifique que o certificado foi corretamente armazenado indo em Trusted credentials -> USER

2. Torná-lo confiável pelo System: Faça o download do módulo Magisc MagiskTrustUserCerts (um arquivo .zip), arraste&solte no telefone, abra o app Magics no telefone na seção Modules, clique em Install from storage, selecione o módulo .zip e, uma vez instalado, reboot o telefone:

• Após o reboot, vá em Trusted credentials -> SYSTEM e verifique se o certificado Postswigger está lá

Learn how to create a Magisc module

Confira https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437

Post Android 14

No lançamento mais recente do Android 14, foi observada uma mudança significativa no tratamento dos certificados de Certificate Authority (CA) confiáveis pelo sistema. Antes, esses certificados ficavam em /system/etc/security/cacerts/, acessíveis e modificáveis por usuários com privilégios root, o que permitia aplicação imediata em todo o sistema. Contudo, 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 remountar o APEX cacerts path como gravável falham, 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; as aplicações continuam acessando os dados originais dos certificados independentemente das alterações no nível do sistema de arquivos. Essa resiliência se deve ao fato de o mount de /apex estar configurado com PRIVATE propagation, 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 aplicações com um novo namespace de mount que inclui um mount privado de /apex, isolando assim alterações nesse diretório dos demais processos.

No entanto, existe uma solução alternativa para quem precisa modificar os certificados CA confiáveis pelo sistema dentro do diretório /apex. Isso envolve remountar manualmente /apex para remover a PRIVATE propagation, tornando-o gravável. O processo inclui copiar o conteúdo de /apex/com.android.conscrypt para outro local, desmontar o diretório /apex/com.android.conscrypt para eliminar a restrição de somente leitura e então restaurar o conteúdo para sua localização original dentro de /apex. Essa abordagem requer ação rápida para evitar crashes do sistema. Para garantir a aplicação das mudanças em todo o sistema, recomenda-se reiniciar o system_server, o que efetivamente reinicia todas as aplicações e coloca o sistema em um 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

1. Configurando um Diretório Gravável: Inicialmente, um diretório gravável é criado montando um tmpfs sobre o diretório de certificados do sistema non-APEX existente. Isso é feito com o seguinte comando:

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

2. Preparando certificados CA: Após a configuração do 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 os rótulos SELinux desses certificados adequadamente.

3. Bind Mount para o Zygote: Utilizando nsenter, entra-se no namespace de montagem do Zygote. O Zygote, sendo o processo responsável por iniciar aplicações Android, requer este passo para garantir que todas as aplicações iniciadas a partir de agora utilizem os certificados CA recém-configurados. O comando usado é:

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

Isto garante que todo novo app iniciado irá aderir à configuração atualizada de certificados CA.

4. Aplicando Alterações em Apps em Execução: Para aplicar as alterações às aplicações já em execução, nsenter é novamente usado para entrar no namespace de cada app individualmente e realizar um bind mount semelhante. O comando necessário é:

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 de uma reinicialização suave do sistema operacional com os comandos stop && start. Essa abordagem propaga as alterações por todos os namespaces, evitando a necessidade de tratar individualmente cada aplicativo em execução. No entanto, esse método normalmente é menos preferido devido ao inconveniente de reiniciar.

Referências

• Android 14: Install a system CA certificate on a rooted device
• Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa