Installare il certificato di Burp

Reading time: 9 minutes

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

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

Esporta il certificato nel formato Der e trasformiamolo in una forma che Android possa capire. Nota che per configurare il certificato di Burp sulla macchina Android in AVD è necessario eseguire questa macchina con l'opzione -writable-system.
Per 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, 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 finito di riavviarsi il certificato Burp sarà in uso!

Usare Magisc

Se hai effettuato il root del dispositivo con Magisc (magari un emulator), e non puoi seguire i precedenti passaggi per installare il certificato Burp perché il file system è di sola lettura e non puoi rimontarlo in scrittura, c'è un'altra via.

Spiegato in questo video devi:

1. Installa un certificato CA: Basta trascina e rilascia il certificato DER Burp cambiando l'estensione in .crt sul dispositivo in modo che venga memorizzato nella cartella Downloads e vai su Install a certificate -> CA certificate

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

2. Rendilo attendibile a livello di sistema: Scarica il modulo Magisc MagiskTrustUserCerts (un file .zip), trascina e rilascia il file nel telefono, vai alla Magics app 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

Scopri come creare un modulo Magisc

Vedi 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 è stata osservata una modifica significativa nella gestione dei certificati delle Certificate Authority (CA) attendibili dal sistema. In precedenza, questi certificati risiedevano in /system/etc/security/cacerts/, accessibili e modificabili dagli utenti con privilegi di root, il che ne permetteva l'applicazione immediata a livello di sistema. Tuttavia, con Android 14, la posizione di archiviazione è stata spostata in /apex/com.android.conscrypt/cacerts, una directory all'interno del percorso /apex, che è immutabile per natura.

I tentativi di rimontare il percorso APEX cacerts come scrivibile falliscono, poiché il sistema non consente 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 PRIVATE propagation, garantendo che qualsiasi modifica all'interno della directory /apex non influisca sugli 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 delle applicazioni 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 alternativa per chi ha bisogno di modificare i certificati CA attendibili a livello di sistema nella directory /apex. Questa prevede il rimontaggio manuale di /apex per rimuovere la PRIVATE propagation, 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 azione rapida per evitare crash di sistema. Per assicurare l'applicazione delle modifiche a livello di sistema, si raccomanda di riavviare system_server, che effettivamente riavvia tutte le applicazioni e riporta 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 through 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

2. Preparazione dei certificati CA: Dopo aver impostato la directory scrivibile, i certificati CA che si intende utilizzare devono essere copiati in questa directory. Questo può comportare la copia dei certificati di default da /apex/com.android.conscrypt/cacerts/. È essenziale regolare di conseguenza i permessi e le etichette SELinux di questi certificati.
3. Montaggio bind per Zygote: Utilizzando nsenter, si entra nel namespace di mount di Zygote. Zygote, essendo il processo responsabile dell'avvio delle applicazioni Android, richiede questo passaggio per assicurare che tutte le applicazioni avviate d'ora in poi utilizzino i certificati CA appena configurati. Il comando usato è:

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

Questo garantisce che ogni nuova app avviata aderirà alla configurazione aggiornata dei certificati CA.

4. 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 e eseguire un bind mount simile. Il comando necessario è:

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

5. Alternative Approach - Soft Reboot: Un metodo alternativo consiste nell'eseguire 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 attraverso tutti i namespaces, evitando la necessità di indirizzare singolarmente ogni app in esecuzione. Tuttavia, questo metodo è generalmente meno preferito a causa dell'inconveniente del reboot.

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