Installare il certificato Burp

Reading time: 9 minutes

Proxy 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

Suggerimento: in Burp, associa il tuo listener a 0.0.0.0 in modo che i dispositivi nella LAN possano connettersi (Proxy -> Options -> Proxy Listeners).

Su una macchina virtuale

Per prima cosa devi scaricare il certificato Der da Burp. Puoi farlo in Proxy --> Options --> Import / Export CA certificate

Esporta il certificato in formato Der e trasformiamolo in una forma che Android sarà in grado di interpretare. Nota che per configurare il certificato Burp sulla macchina Android in AVD devi eseguire questa 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

Poi, per configurare burps certificate, esegui:

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 completato il riavvio, il certificato di burp sarà in uso!

Using Magisc

Se hai effettuato il root del tuo dispositivo con Magisc (forse un emulatore), e non puoi seguire i precedenti passaggi per installare il certificato Burp perché il filesystem è di sola lettura e non puoi rimontarlo in scrittura, esiste un altro metodo.

Spiegato in this video devi:

1. Installa un certificato CA: Basta fare drag&drop del certificato DER di Burp cambiando l'estensione in .crt nel telefono in modo che sia memorizzato nella cartella Downloads e vai a Install a certificate -> CA certificate

• Verifica che il certificato sia stato memorizzato correttamente andando su Trusted credentials -> USER

2. Rendilo trusted di sistema: Scarica il modulo Magisc MagiskTrustUserCerts (un file .zip), drag&drop it nel telefono, vai all'app Magics sul telefono nella 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 certificato Postswigger sia presente

Learn how to create a Magisc module

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 di Android 14 è stato osservato un cambiamento significativo nella gestione dei certificati delle Certificate Authority (CA) trusted di sistema. In precedenza, questi certificati risiedevano in /system/etc/security/cacerts/, accessibili e modificabili dagli utenti con privilegi root, il che permetteva l'applicazione immediata a livello di sistema. Tuttavia, con Android 14, la posizione di memorizzazione è 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 cacerts di APEX come scrivibile falliscono, poiché il sistema non permette tali operazioni. Anche i tentativi di smontare o sovrapporre la directory con un file system temporaneo (tmpfs) non aggirano l'immutabilità; le applicazioni continuano ad accedere ai dati originali dei certificati indipendentemente dalle modifiche a livello di file system. Questa resilienza è dovuta al fatto che il mount di /apex è configurato con propagation PRIVATE, garantendo che eventuali modifiche all'interno della directory /apex non influenzino altri processi.

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

Tuttavia, esiste una soluzione alternativa per chi ha bisogno di modificare i certificati CA trusted di sistema all'interno della directory /apex. Questo comporta il rimontaggio manuale di /apex per rimuovere la propagation PRIVATE, rendendolo così scrivibile. Il processo include la copia del contenuto di /apex/com.android.conscrypt in un'altra posizione, lo smontaggio della directory /apex/com.android.conscrypt per eliminare il vincolo di sola lettura, e poi il ripristino dei contenuti nella loro posizione originale all'interno di /apex. Questo approccio richiede azioni rapide per evitare crash del sistema. Per garantire l'applicazione a livello di sistema di queste modifiche, è consigliato riavviare il system_server, che effettivamente riavvia tutte le applicazioni e porta il sistema in 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 attraverso NSEnter

1. Creazione di una directory scrivibile: Inizialmente, viene creata una directory scrivibile montando un tmpfs sopra la directory dei certificati di sistema esistente non-APEX. Questo viene ottenuto con il seguente comando:

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

2. Preparazione dei certificati CA: Dopo aver configurato la directory scrivibile, i certificati CA che si intende utilizzare devono essere copiati in questa directory. Ciò può implicare la copia dei certificati di default da /apex/com.android.conscrypt/cacerts/. È essenziale adeguare i permessi e le etichette SELinux di questi certificati di conseguenza.
3. Bind mount per Zygote: Utilizzando nsenter, si entra nel mount namespace di 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 certificati CA appena configurati. Il comando utilizzato è:

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

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

4. Applicare le modifiche alle app in esecuzione: Per applicare le modifiche alle applicazioni già in esecuzione, si utilizza nuovamente nsenter per entrare nel namespace di ciascuna app individualmente ed eseguire 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

5. Approccio alternativo - Riavvio soft: Un metodo alternativo consiste nell'eseguire il bind mount sul processo init (PID 1) seguito da un riavvio soft del sistema operativo con i comandi stop && start. Questo approccio propagherebbe le modifiche attraverso tutti i namespace, evitando la necessità di intervenire singolarmente su ogni app in esecuzione. Tuttavia, questo metodo è generalmente meno preferito a causa dell'inconveniente del riavvio.

Riferimenti

• Android 14: Install a system CA certificate on a rooted device
• Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa