Instalar certificado do Burp

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Navegue pelo catálogo completo do HackTricks Training para as trilhas de assessment (ARTA/GRTA/AzRTA) e Linux Hacking Expert (LHE).

Support HackTricks

Proxy em todo o sistema via ADB

Configure um proxy HTTP global para que todos os aplicativos encaminhem 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: No Burp, vincule seu listener a 0.0.0.0 para que dispositivos na LAN possam conectar-se (Proxy -> Options -> Proxy Listeners).

Em uma Máquina Virtual

Primeiro 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 um formato que Android vai conseguir entender. Observe que para configurar o burp certificate na máquina Android no 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 burps, 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 Burp estará em uso!

Usando Magisk

Se você fez root no seu dispositivo com Magisk (talvez um emulador), e você não consegue seguir os passos anteriores para instalar o cert Burp porque o sistema de arquivos está read-only e você não consegue remontá-lo como gravável, há outra maneira.

Explicado em this video você precisa:

  1. Instalar um certificado CA: Basta arrastar&soltar o certificado Burp em DER alterando a extensão para .crt no celular para que seja salvo na pasta Downloads e vá em Install a certificate -> CA certificate
  • Verifique que o certificado foi corretamente armazenado indo em Trusted credentials -> USER
  1. Tornar confiável pelo System: Baixe o módulo Magisk MagiskTrustUserCerts (um arquivo .zip), arraste&solte-o no telefone, abra o aplicativo Magisk 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 que o certificado Postswigger está lá

Alternative: AlwaysTrustUserCerts (Android 7-16 Beta)

Se você está no Android 14+ (ou em dispositivos mais antigos que receberam atualizações Conscrypt Mainline e agora usam /apex/com.android.conscrypt/cacerts), o módulo Magisk AlwaysTrustUserCerts automatiza o bind-mounting necessário para confiança do sistema. Ele espelha CAs de usuário na confiança do sistema e injeta mounts nos namespaces do Zygote/app para que os apps vejam os certs sem trabalho manual com nsenter.

  1. Instale a CA Burp primeiro como um certificado de usuário.
  2. Instale o módulo e reinicie.
  3. Se o módulo oferecer uma opção, prefira --rbind ao montar /system/etc/security/cacerts em /apex/com.android.conscrypt/cacerts para garantir mounts aninhados (de outros módulos) sejam visíveis.

Learn how to create a Magisk module

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

Post Android 14

No mais recente release do Android 14, observou-se uma mudança significativa no tratamento de certificados de Autoridade Certificadora (CA) confiáveis pelo sistema.

Note: Some Android 12/13 devices that received Conscrypt Mainline updates already use /apex/com.android.conscrypt/cacerts. If that directory exists on your device, you must use the same APEX injection technique described below.

Anteriormente, esses certificados estavam armazenados 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. Entretanto, 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 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; aplicações continuam a acessar os dados originais dos certificados independentemente das mudanças no nível do sistema de arquivos. Essa resiliência se deve ao 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ção com um novo mount namespace que inclui um mount privado /apex, isolando assim alterações nesse diretório de outros processos.

No entanto, existe um workaround para quem precisa modificar os certificados CA confiáveis pelo sistema dentro do diretório /apex. Isso envolve remontar manualmente /apex para remover a PRIVATE propagation, tornando-o assim 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, é recomendado reiniciar o system_server, o que efetivamente reinicia todas as aplicações e traz o sistema a 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
  1. Preparando Certificados CA: Após configurar o diretório gravável, os certificados CA que se pretende usar devem ser copiados para esse 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.
  2. Bind Mounting for Zygote: Utilizando nsenter, entra-se no mount namespace do Zygote. O Zygote, sendo o processo responsável por lançar aplicações Android, requer este passo para garantir que todas as aplicações iniciadas a partir daqui utilizem os certificados CA recém-configurados. O comando usado é:

Tip: If /system/etc/security/cacerts contains nested mounts (common with Magisk modules), use --rbind instead of --bind so those mounts propagate into app namespaces.

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
# If /system/etc/security/cacerts includes nested mounts, prefer --rbind
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --rbind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

Isso garante que todo novo app iniciado seguirá a configuração atualizada de certificados CA.

  1. Aplicando mudanças em apps em execução: Para aplicar as mudanças em aplicações já em execução, usa-se novamente nsenter para entrar no namespace de cada app individualmente e realizar um bind mount similar. O comando necessário é:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. Abordagem alternativa - Reinício suave: Um método alternativo envolve realizar o bind mount no processo init (PID 1), seguido por um reinício suave do sistema operacional com os comandos stop && start. Essa abordagem propagaria as alterações por todos os namespaces, evitando a necessidade de tratar individualmente cada app em execução. Entretanto, esse método é geralmente menos preferido devido ao inconveniente de reiniciar.

Referências

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Navegue pelo catálogo completo do HackTricks Training para as trilhas de assessment (ARTA/GRTA/AzRTA) e Linux Hacking Expert (LHE).

Support HackTricks