Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-28 07:31:10 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/mobile-pentesting/android-app-pentesting/install-burp-certificate.md

12 KiB
Raw Blame History

Instalar Certificado Burp

Aprenda hacking AWS do zero ao avançado com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

{% 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

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" %}

C:\Users\<UserName>\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" %}

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 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
  1. Torná-lo confiável pelo sistema: Baixe o módulo Magisc 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.

# 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:
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 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.
  2. 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 é:
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.

  1. 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 é:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. 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

{% 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: