Installa il certificato di Burp

Tip

Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara e pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Sfoglia il catalogo completo di HackTricks Training per i percorsi di assessment (ARTA/GRTA/AzRTA) e Linux Hacking Expert (LHE).

Supporta HackTricks

Proxy a livello di sistema tramite ADB

Configura un proxy HTTP globale in modo che tutte le app instradino il traffico attraverso il tuo 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

Tip: In Burp, imposta il listener su 0.0.0.0 in modo che i dispositivi sulla LAN possano connettersi (Proxy -> Options -> Proxy Listeners).

Su una macchina virtuale

Prima di tutto devi scaricare il certificato Der da Burp. Puoi farlo in Proxy –> Options –> Import / Export CA certificate

Esporta il certificato in formato Der e trasformalo in una forma che Android sarà in grado di comprendere. Nota che per configurare il certificato di Burp sulla macchina Android in AVD è necessario avviare la macchina con l’opzione -writable-system.
Ad esempio puoi eseguirla così:

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

Quindi, per configurare il certificato di 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

Una volta che la macchina ha terminato il riavvio, il certificato Burp sarà in uso!

Usare Magisk

Se hai rootato il dispositivo con Magisk (magari un emulator), e non puoi seguire i passaggi precedenti per installare il certificato Burp perché il filesystem è in sola lettura e non puoi rimontarlo scrivibile, c’è un altro modo.

Spiegato in this video devi:

  1. Install a CA certificate: Basta fare drag&drop il certificato DER di Burp cambiando l’estensione in .crt nel mobile in modo che sia salvato nella cartella Downloads e andare su Install a certificate -> CA certificate
  • Verifica che il certificato sia stato memorizzato correttamente andando su Trusted credentials -> USER
  1. Make it System trusted: Scarica il Magisk module MagiskTrustUserCerts (un file .zip), drag&dropalo nel telefono, vai nell’app Magisk nel telefono alla sezione Modules, clicca su Install from storage, seleziona il modulo .zip e una volta installato riavvia il telefono:
  • Dopo il riavvio, vai su Trusted credentials -> SYSTEM e verifica che il Postswigger cert sia presente

Alternativa: AlwaysTrustUserCerts (Android 7-16 Beta)

Se sei su Android 14+ (o su dispositivi più vecchi che hanno ricevuto aggiornamenti Conscrypt Mainline e ora usano /apex/com.android.conscrypt/cacerts), il Magisk module AlwaysTrustUserCerts automatizza il bind-mounting necessario per la fiducia di sistema. Replica le CA utente nella fiducia di sistema e inietta mount negli namespace di Zygote/app così le app vedono i certificati senza lavoro manuale con nsenter.

  1. Installa prima la Burp CA come certificato user.
  2. Installa il modulo e riavvia.
  3. Se il modulo offre una scelta, preferisci --rbind quando monti /system/etc/security/cacerts dentro /apex/com.android.conscrypt/cacerts per assicurare che i mount annidati (da altri moduli) siano visibili.

Impara a creare un modulo Magisk

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

Dopo Android 14

Nell’ultima release Android 14 si è osservata una significativa modifica nella gestione dei Certificate Authority (CA) trusted di sistema.

Nota: Alcuni dispositivi Android 12/13 che hanno ricevuto aggiornamenti Conscrypt Mainline già usano /apex/com.android.conscrypt/cacerts. Se quella directory esiste sul tuo dispositivo, devi usare la stessa tecnica di injection APEX descritta sotto.

In precedenza questi certificati risiedevano in /system/etc/security/cacerts/, accessibili e modificabili da utenti con privilegi root, permettendo l’applicazione immediata a livello di sistema. Tuttavia, con Android 14 la posizione di storage è stata spostata in /apex/com.android.conscrypt/cacerts, una directory all’interno del percorso /apex, che per natura è immutabile.

I tentativi di rimontare il percorso APEX cacerts come scrivibile falliscono, poiché il sistema non permette tali operazioni. Anche i tentativi di smontare o sovrapporre la directory con un filesystem temporaneo (tmpfs) non aggirano l’immutabilità; le applicazioni continuano ad accedere ai dati originali dei certificati indipendentemente dalle modifiche a livello di filesystem. Questa resistenza è dovuta al fatto che il mount di /apex è configurato con propagazione PRIVATE, assicurando che qualsiasi modifica all’interno della directory /apex non influisca sugli altri processi.

L’inizializzazione di Android coinvolge il processo init che, avviando il sistema operativo, avvia anche il processo Zygote. Questo processo è responsabile del lancio dei processi applicativi con un nuovo mount namespace che include un mount privato di /apex, isolando così le modifiche a questa directory dagli altri processi.

Tuttavia, esiste una soluzione per chi ha bisogno di modificare le CA trusted di sistema all’interno della directory /apex. Questa prevede il rimontaggio manuale di /apex per rimuovere la propagazione PRIVATE, rendendolo così scrivibile. Il processo include copiare il contenuto di /apex/com.android.conscrypt in un’altra posizione, smontare la directory /apex/com.android.conscrypt per eliminare il vincolo di sola lettura, e poi ripristinare i contenuti nella loro posizione originale dentro /apex. Questo approccio richiede azioni rapide per evitare crash di sistema. Per assicurare l’applicazione a livello di sistema di queste modifiche, si raccomanda di riavviare il system_server, il che riavvia efficacemente tutte le applicazioni e riporta il sistema a uno stato 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 tramite NSEnter

  1. Impostazione di una directory scrivibile: Inizialmente, viene creata una directory scrivibile montando un tmpfs sopra l’esistente directory dei certificati di sistema non-APEX. Questo viene ottenuto con il seguente comando:
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. Preparing CA Certificates: Dopo la configurazione della directory scrivibile, i CA certificates che si intende utilizzare devono essere copiati in questa directory. Questo potrebbe comportare la copia dei certificati predefiniti da /apex/com.android.conscrypt/cacerts/. È essenziale regolare di conseguenza i permessi e le etichette SELinux di questi certificati.
  2. Bind Mounting for Zygote: Utilizzando nsenter, si entra nel mount namespace dello Zygote. Zygote, essendo il processo responsabile dell’avvio delle applicazioni Android, richiede questo passaggio per garantire che tutte le applicazioni avviate d’ora in poi utilizzino i CA certificates appena configurati. Il comando utilizzato è:

Suggerimento: Se /system/etc/security/cacerts contiene montaggi nidificati (comune con Magisk modules), usare --rbind invece di --bind in modo che tali montaggi si propaghino nei namespace delle app.

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

Questo garantisce che ogni nuova app avviata rispetterà la configurazione aggiornata dei certificati CA.

  1. Applicare le modifiche alle app in esecuzione: Per applicare le modifiche alle applicazioni già in esecuzione, nsenter viene nuovamente usato per entrare nel namespace di ciascuna app individualmente ed effettuare un bind mount analogo. Il comando necessario è:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. Alternative Approach - Soft Reboot: Un metodo alternativo consiste nell’effettuare il bind mount sul processo init (PID 1) seguito da un soft reboot del sistema operativo con i comandi stop && start. Questo approccio propagherebbe le modifiche in tutti i namespaces, evitando la necessità di intervenire singolarmente su ogni app in esecuzione. Tuttavia, questo metodo è generalmente meno preferito a causa dell’inconveniente del riavvio.

Riferimenti

Tip

Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara e pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Sfoglia il catalogo completo di HackTricks Training per i percorsi di assessment (ARTA/GRTA/AzRTA) e Linux Hacking Expert (LHE).

Supporta HackTricks