Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-02 09:29:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/mobile-pentesting/android-app-pentesting/install-burp-certificate.md

12 KiB
Raw Blame History

Installer le certificat Burp

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

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 un format 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 suit :

{% code overflow="wrap" %}

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 Burp, faites :

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

Une fois que la machine a redémarré, le certificat Burp sera utilisé par celle-ci !

Utilisation de 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ée dans cette vidéo, vous devez :

  1. Installer un certificat CA : Glissez-déposez simplement 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 allez dans Installer un certificat -> Certificat CA
  • Vérifiez que le certificat a été correctement stocké en allant dans Certificats de confiance -> UTILISATEUR
  1. Le rendre Système de confiance : Téléchargez le module Magisc MagiskTrustUserCerts (un fichier .zip), glissez-déposez-le sur 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 dans Certificats de confiance -> SYSTÈME et vérifiez que le certificat Postswigger est là

Post Android 14

Changements :

  • Jusqu'à présent, les certificats CA de confiance du système se trouvaient dans /system/etc/security/cacerts/. Sur un émulateur AOSP standard, ceux-ci pouvaient être modifiés directement avec un accès root avec une configuration minimale, prenant immédiatement effet partout.
  • Dans Android 14, les certificats CA de confiance du système se trouveront généralement dans /apex/com.android.conscrypt/cacerts, et tout /apex est immuable.
  • Ce chemin APEX cacerts ne peut pas être remonté en réécriture - les remontages échouent simplement. En fait, même si vous démontez entièrement le chemin depuis un shell root, les applications peuvent toujours lire vos certificats sans problème.
  • La technique alternative de montage d'un répertoire tmpfs par-dessus ne fonctionne pas non plus - même si cela signifie que ls /apex/com.android.conscrypt/cacerts pourrait ne rien retourner (ou tout ce que vous voulez), les applications verront toujours les mêmes données originales.
  • Parce que le montage /apex est explicitement monté avec une propagation PRIVÉE, de sorte que tous les changements de montages à l'intérieur du chemin /apex ne sont jamais partagés entre les processus.

Cela est fait par le processus init qui démarre le système d'exploitation, qui lance ensuite le processus Zygote (avec un nouvel espace de montage copié du parent, incluant donc son propre montage /apex privé), qui à son tour démarre chaque processus d'application chaque fois qu'une application est lancée sur l'appareil (qui à leur tour copient ce même montage /apex privé).

Remontage récursif des points de montage

  • Vous pouvez remonter /apex manuellement, en supprimant la propagation PRIVÉE et en le rendant modifiable (ironiquement, il semble que la suppression complète de la propagation privée se propage partout)
  • Vous copiez l'intégralité du contenu de /apex/com.android.conscrypt ailleurs
  • Ensuite, vous démontez entièrement /apex/com.android.conscrypt - en supprimant le montage en lecture seule qui fournit immuablement ce module
  • Ensuite, vous recopiez le contenu, de sorte qu'il vive directement dans le montage /apex, où il peut être modifié (vous devez faire cela rapidement, car apparemment vous pouvez voir des plantages autrement)
  • Cela devrait prendre effet immédiatement, mais ils recommandent de tuer system_server (redémarrer toutes les applications) pour que tout revienne à 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"

Montage en liant via NSEnter

  • Tout d'abord, nous devons configurer un répertoire accessible en écriture quelque part. Pour une compatibilité facile avec l'approche existante, je fais cela avec un montage tmpfs sur le répertoire des certificats système non-APEX (toujours présent) :
mount -t tmpfs tmpfs /system/etc/security/cacerts
  • Ensuite, vous placez les certificats CA qui vous intéressent dans ce répertoire (par exemple, vous pourriez vouloir copier tous les certificats par défaut du répertoire existant /apex/com.android.conscrypt/cacerts/) et définir les permissions et les étiquettes SELinux de manière appropriée.
  • Ensuite, utilisez nsenter pour entrer dans l'espace de noms de montage de Zygote, et montez ce répertoire en liant avec le répertoire APEX :
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- \
/bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

Le processus Zygote génère chaque application, en copiant son espace de noms de montage pour le faire, ce qui garantit que toutes les applications nouvellement lancées (tout ce qui est démarré à partir de maintenant) utiliseront cela.

  • Ensuite, utilisez nsenter pour entrer dans l'espace de noms de montage de chaque application déjà en cours d'exécution, et faites de même :
nsenter --mount=/proc/$APP_PID/ns/mnt -- \
/bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

Alternativement, si cela ne vous dérange pas l'expérience utilisateur maladroite, vous devriez être capable de faire le montage en liant sur init lui-même (PID 1) puis exécuter stop && start pour redémarrer doucement le système d'exploitation, en recréant tous les espaces de noms et en propageant vos modifications partout (mais personnellement, je me soucie du redémarrage maladroit, donc j'ignore complètement cette voie).

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :