Installer le certificat Burp

Reading time: 8 minutes

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 transformons-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 l'exécuter 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 burp, faites :

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 machine a terminé de redémarrer, le certificat Burp sera en cours d'utilisation !

Utiliser Magisc

Si vous avez rooté votre appareil avec Magisc (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.

Expliqué dans cette vidéo, vous devez :

1. Installer un certificat CA : Il suffit de faire glisser et déposer le certificat Burp DER en changeant l'extension en .crt sur le mobile afin qu'il soit stocké dans le dossier Téléchargements et aller à Installer un certificat -> Certificat CA

• Vérifiez que le certificat a été correctement stocké en allant à Informations d'identification de confiance -> UTILISATEUR

2. Le rendre de confiance pour le système : Téléchargez le module Magisc MagiskTrustUserCerts (un fichier .zip), faites-le glisser et déposez-le dans le téléphone, allez dans l'application Magics sur le téléphone dans la section Modules, cliquez sur Installer depuis le stockage, sélectionnez le module .zip et une fois installé, redémarrez le téléphone :

• Après le redémarrage, allez à Informations d'identification de confiance -> SYSTÈME et vérifiez que le certificat Postswigger est là

Post Android 14

Dans la dernière version d'Android 14, un changement significatif a été observé dans la gestion des certificats d'autorité de certification (CA) de confiance par le système. Auparavant, ces certificats étaient logés dans /system/etc/security/cacerts/, accessibles et modifiables par les utilisateurs ayant des privilèges root, ce qui permettait une application immédiate à travers le système. Cependant, avec Android 14, l'emplacement de stockage a été déplacé vers /apex/com.android.conscrypt/cacerts, un répertoire au sein du 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 l'immutabilité ; les applications continuent d'accéder aux données de certificat originales, quelles que soient les modifications au niveau du système de fichiers. Cette résilience est due au montage /apex étant configuré avec une propagation PRIVÉE, garantissant que toute modification dans le répertoire /apex n'affecte pas d'autres processus.

L'initialisation d'Android implique le processus init, qui, lors du démarrage du système d'exploitation, initie également le processus Zygote. Ce processus est responsable du lancement des processus d'application avec un nouvel espace de montage qui inclut un montage /apex privé, isolant ainsi les modifications apportées à ce répertoire des autres processus.

Néanmoins, une solution de contournement existe pour ceux qui ont besoin de modifier les certificats CA de confiance pour le système dans le répertoire /apex. Cela implique de remonter manuellement /apex pour supprimer la propagation PRIVÉE, le rendant ainsi modifiable. Le processus comprend la copie du contenu de /apex/com.android.conscrypt vers un autre emplacement, le démontage du répertoire /apex/com.android.conscrypt pour éliminer la contrainte de lecture seule, puis la restauration du contenu à son emplacement d'origine dans /apex. Cette approche nécessite une action rapide pour éviter les plantages du système. Pour garantir l'application systémique de ces modifications, 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. Configuration d'un répertoire écrivable : Initialement, un répertoire écrivable est établi en montant un tmpfs sur le répertoire de certificats système non-APEX existant. Cela est réalisé avec la commande suivante :

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

2. Préparation des certificats CA : Après la configuration du répertoire écrivable, les certificats CA que l'on souhaite 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.
3. Montage lié pour Zygote : En utilisant nsenter, on entre dans l'espace de noms 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 initiées par la suite utilisent les certificats CA nouvellement configurés. La commande utilisée est :

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /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.

4. Application des modifications aux applications en cours d'exécution : 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 montage de liaison 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

5. Approche alternative - Redémarrage doux : Une méthode alternative consiste à effectuer le montage de liaison sur le processus init (PID 1) suivi d'un redémarrage doux du système d'exploitation avec les commandes stop && start. Cette approche propagerait les changements à travers tous les espaces de noms, évitant ainsi la nécessité de s'adresser individuellement à chaque application en cours d'exécution. Cependant, cette méthode est généralement moins préférée en raison de l'inconvénient du redémarrage.

Références

• https://httptoolkit.com/blog/android-14-install-system-ca-certificate/