Install Burp Certificate

Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!

• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.

• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos di github.

Websec | Uw Cybersecurity Specialist

Su una Macchina Virtuale

Prima di tutto devi scaricare il certificato Der da Burp. Puoi farlo in Proxy --> Options --> Importa / Esporta certificato CA

Esporta il certificato in formato Der e trasformalo in una forma che Android sarà in grado di comprendere. Nota che per configurare il certificato burp sulla macchina Android in AVD devi eseguire questa macchina con l'opzione -writable-system. Ad esempio, puoi eseguirlo 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 burp fare:

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!

Utilizzando Magisc

Se hai rootato il tuo dispositivo con Magisc (forse un emulatore), e non puoi seguire i passaggi precedenti per installare il certificato Burp perché il filesystem è in sola lettura e non puoi rimontarlo in scrittura, c'è un altro modo.

Spiegato in questo video devi:

1. Installare un certificato CA: Basta trascinare e rilasciare il certificato Burp DER cambiando l'estensione in .crt nel mobile in modo che sia memorizzato nella cartella Download e andare su Installa un certificato -> Certificato CA

• Controlla che il certificato sia stato memorizzato correttamente andando su Credenziali attendibili -> UTENTE

1. Rendere fidato di sistema: Scarica il modulo Magisc MagiskTrustUserCerts (un file .zip), trascinalo e rilascialo nel telefono, vai all'app Magics nel telefono nella sezione Moduli, clicca su Installa da memoria, seleziona il modulo .zip e una volta installato riavvia il telefono:

• Dopo il riavvio, vai su Credenziali attendibili -> SISTEMA e controlla che il certificato Postswigger sia presente

Post Android 14

Nell'ultima versione di Android 14, è stato osservato un cambiamento significativo nella gestione dei certificati dell'Autorità di Certificazione (CA) fidati di sistema. In precedenza, questi certificati erano ospitati in /system/etc/security/cacerts/, accessibili e modificabili dagli utenti con privilegi di root, il che consentiva un'applicazione immediata in tutto il 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 incontrano un fallimento, poiché il sistema non consente tali operazioni. Anche i tentativi di smontare o sovrapporre la directory con un file system temporaneo (tmpfs) non eludono l'immutabilità; le applicazioni continuano ad accedere ai dati del certificato originale indipendentemente dalle modifiche a livello di file system. Questa resilienza è dovuta al fatto che il mount /apex è configurato con propagazione PRIVATA, 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 dell'avvio dei processi delle applicazioni con un nuovo namespace di mount che include un mount /apex privato, isolando così le modifiche a questa directory da altri processi.

Tuttavia, esiste una soluzione per coloro che necessitano di modificare i certificati CA fidati di sistema all'interno della directory /apex. Questo comporta il rimontaggio manuale di /apex per rimuovere la propagazione PRIVATA, rendendolo quindi scrivibile. Il processo include la copia dei contenuti 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 un'azione rapida per evitare crash di sistema. Per garantire l'applicazione di queste modifiche a livello di sistema, si consiglia di riavviare il system_server, che riavvia effettivamente tutte le applicazioni e riporta il sistema a uno stato coerente.

# 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. Impostare una Directory Scrivibile: Inizialmente, viene stabilita una directory scrivibile montando un tmpfs sulla directory dei certificati di sistema non-APEX esistente. Questo viene realizzato con il seguente comando:

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

1. Preparazione dei certificati CA: Dopo aver impostato la directory scrivibile, i certificati CA che si intendono utilizzare devono essere copiati in questa directory. Questo potrebbe comportare la copia dei certificati predefiniti da /apex/com.android.conscrypt/cacerts/. È essenziale regolare le autorizzazioni e le etichette SELinux di questi certificati di conseguenza.

2. Montaggio Bind per Zygote: Utilizzando nsenter, si entra nello spazio dei nomi di montaggio 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

Questo garantisce che ogni nuova app avviata aderisca alla 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 utilizzato per entrare nel namespace di ciascuna app individualmente e eseguire un montaggio bind simile. Il comando necessario è:

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

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

Riferimenti

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

Websec | Uw Cybersecurity Specialist

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.