Installer le certificat Burp

Tip

Apprenez et pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez et pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Parcourez le catalogue complet de HackTricks Training pour les parcours d’évaluation (ARTA/GRTA/AzRTA) et Linux Hacking Expert (LHE).

Support HackTricks

Proxy global via ADB

Configurez un proxy HTTP global afin que toutes les applications acheminent le trafic via votre outil d’interception (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

Tip: In Burp, liez votre listener à 0.0.0.0 afin que les appareils du LAN puissent se connecter (Proxy -> Options -> Proxy Listeners).

Sur une machine virtuelle

Tout d’abord, vous devez télécharger le certificat Der depuis Burp. Vous pouvez le faire dans Proxy –> Options –> Importer / Exporter le certificat CA

Exportez le certificat au format Der et transformez-le en une forme que Android pourra comprendre. Notez que pour configurer le certificat Burp sur la machine Android dans AVD vous devez exécuter cette machine avec l’option -writable-system.
Par exemple vous pouvez le lancer comme :

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

Ensuite, pour configurer le certificat de burps:

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

Une fois que la la machine a fini de redémarrer le certificat Burp sera utilisé par celle-ci !

Utiliser Magisk

Si vous avez rooté votre appareil avec Magisk (peut-être un émulateur), et que vous ne pouvez pas suivre les étapes précédentes pour installer le certificat Burp parce que le système de fichiers est en lecture seule et que vous ne pouvez pas le remonter en écriture, il existe une autre méthode.

Comme expliqué dans this video vous devez :

  1. Installer un certificat CA : Il suffit de glisser-déposer le certificat DER Burp en changeant l’extension en .crt sur le mobile pour qu’il soit stocké dans le dossier Downloads et d’aller dans Install a certificate -> CA certificate
  • Vérifiez que le certificat a été correctement enregistré en allant dans Trusted credentials -> USER
  1. Rendre le certificat approuvé par le système : Téléchargez le module Magisk MagiskTrustUserCerts (un fichier .zip), glissez-déposez-le dans le téléphone, ouvrez l’application Magisk sur le téléphone, allez dans la section Modules, cliquez sur Install from storage, sélectionnez le module .zip et une fois installé redémarrez le téléphone :
  • Après le redémarrage, allez dans Trusted credentials -> SYSTEM et vérifiez que le certificat Postswigger est présent

Alternative : AlwaysTrustUserCerts (Android 7-16 Beta)

Si vous êtes sur Android 14+ (ou sur des appareils plus anciens ayant reçu des mises à jour Conscrypt Mainline et utilisant désormais /apex/com.android.conscrypt/cacerts), le module Magisk AlwaysTrustUserCerts automatise le bind-mount requis pour la confiance système. Il duplique les CA utilisateur dans la confiance système et injecte des montages dans les namespaces Zygote/app afin que les applications voient les certificats sans travail manuel avec nsenter.

  1. Installez d’abord la CA Burp en tant que certificat user.
  2. Installez le module et redémarrez.
  3. Si le module propose un choix, préférez --rbind lors du montage de /system/etc/security/cacerts dans /apex/com.android.conscrypt/cacerts afin de garantir que les montages imbriqués (provenant d’autres modules) soient visibles.

Apprenez à créer un module Magisk

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

Après Android 14

Dans la dernière version Android 14, un changement significatif a été observé dans la gestion des certificats d’autorité de certification (CA) approuvés par le système.

Remarque : Certains appareils Android 12/13 ayant reçu les mises à jour Conscrypt Mainline utilisent déjà /apex/com.android.conscrypt/cacerts. Si ce répertoire existe sur votre appareil, vous devez utiliser la même technique d’injection APEX décrite ci-dessous.

Auparavant, ces certificats étaient stockés dans /system/etc/security/cacerts/, accessibles et modifiables par des utilisateurs disposant de privilèges root, ce qui permettait leur application immédiate à l’échelle du système. Cependant, avec Android 14, l’emplacement de stockage a été déplacé vers /apex/com.android.conscrypt/cacerts, un répertoire dans le chemin /apex, qui est immuable par nature.

Les tentatives de remonter le chemin APEX cacerts en écriture échouent, car le système n’autorise pas de telles opérations. Même les tentatives de démonter ou de superposer le répertoire avec un système de fichiers temporaire (tmpfs) ne contournent pas cette immutabilité : les applications continuent d’accéder aux données de certificat d’origine quels que soient les changements au niveau du système de fichiers. Cette résilience est due au montage de /apex étant configuré avec une propagation PRIVATE, garantissant que toute modification à l’intérieur du répertoire /apex n’affecte pas les autres processus.

L’initialisation d’Android implique le processus init qui, au démarrage du système d’exploitation, lance également le processus Zygote. Ce dernier est responsable du lancement des processus applicatifs avec un nouveau namespace de montage qui inclut un montage privé /apex, isolant ainsi les modifications de ce répertoire des autres processus.

Néanmoins, une solution de contournement existe pour ceux qui doivent modifier les certificats CA approuvés par le système dans le répertoire /apex. Cela implique de remonter manuellement /apex pour supprimer la propagation PRIVATE, rendant ainsi le répertoire modifiable. Le processus consiste à copier le contenu de /apex/com.android.conscrypt vers un autre emplacement, démonter le répertoire /apex/com.android.conscrypt pour éliminer la contrainte lecture-seule, puis restaurer le contenu à son emplacement d’origine dans /apex. Cette méthode nécessite une exécution rapide pour éviter les plantages du système. Pour garantir l’application système de ces changements, il est recommandé de redémarrer le system_server, ce qui redémarre effectivement toutes les applications et ramène le système à un état cohérent.

# 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. Création d’un répertoire inscriptible: Initialement, un répertoire inscriptible est créé en montant un tmpfs sur le répertoire système de certificats existant non-APEX. Ceci est réalisé avec la commande suivante:
mount -t tmpfs tmpfs /system/etc/security/cacerts

  1. Préparation des certificats CA : Après avoir configuré le répertoire accessible en écriture, les certificats CA que vous souhaitez utiliser doivent être copiés dans ce répertoire. Cela peut impliquer de copier les certificats par défaut depuis /apex/com.android.conscrypt/cacerts/. Il est essentiel d’ajuster les permissions et les étiquettes SELinux de ces certificats en conséquence.

  2. Montage par bind pour Zygote : En utilisant nsenter, on entre dans le namespace de montage de Zygote. Zygote, étant le processus responsable du lancement des applications Android, nécessite cette étape pour s’assurer que toutes les applications lancées par la suite utilisent les certificats CA nouvellement configurés. La commande utilisée est :

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

Cela garantit que chaque nouvelle application démarrée respectera la configuration mise à jour des certificats CA.

  1. Applying Changes to Running Apps : Pour appliquer les modifications aux applications déjà en cours d’exécution, nsenter est à nouveau utilisé pour entrer dans l’espace de noms de chaque application individuellement et effectuer un bind mount similaire. La commande nécessaire est :
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. Approche alternative - Soft Reboot : Une méthode alternative consiste à effectuer le bind mount sur le processus init (PID 1), suivie d’un soft reboot du système d’exploitation avec les commandes stop && start. Cette approche propagerait les changements à travers tous les namespaces, évitant la nécessité d’adresser individuellement chaque app en cours d’exécution. Cependant, cette méthode est généralement moins privilégiée en raison de l’inconvénient du redémarrage.

Références

Tip

Apprenez et pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez et pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Parcourez le catalogue complet de HackTricks Training pour les parcours d’évaluation (ARTA/GRTA/AzRTA) et Linux Hacking Expert (LHE).

Support HackTricks