Italian - Ht
HackTricks Training Twitter Linkedin Sponsor

Install Burp Certificate

Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

Su una Macchina Virtuale

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

Esporta il certificato in formato Der e trasformiamolo in una forma che Android sarà in grado di comprendere. Nota che per configurare il certificato burp sulla macchina Android in AVD è necessario 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, eseguire:

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 di Burp sarà in uso da essa!

Utilizzando Magisc

Se hai eseguito il root del tuo dispositivo con Magisc (forse un emulatore), e non riesci a seguire i passaggi precedenti per installare il certificato Burp perché il filesystem è in sola lettura e non puoi montarlo 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 cellulare in modo che sia memorizzato nella cartella Download e vai su Installa un certificato -> Certificato CA

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

  1. Renderlo attendibile dal 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 archivio, seleziona il modulo .zip e una volta installato riavvia il telefono:

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

Dopo Android 14

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

Tuttavia, esiste un workaround per coloro che hanno bisogno di modificare i certificati CA fidati dal sistema all'interno della directory /apex. Questo comporta il rimontaggio manuale di /apex per rimuovere la propagazione PRIVATA, rendendolo così 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 in sola lettura, e quindi 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 su tutto il sistema di queste modifiche, si consiglia di riavviare il system_server, che riavvia efficacemente tutte le applicazioni e porta 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. Configurazione di una directory scrivibile: Inizialmente, viene stabilita una directory scrivibile montando un tmpfs sopra la directory esistente dei certificati di sistema non APEX. Ciò viene realizzato con il seguente comando:

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

  1. Preparazione dei certificati CA: Dopo aver configurato la directory scrivibile, i certificati CA che si intende utilizzare dovrebbero essere copiati in questa directory. Ciò potrebbe comportare la copia dei certificati predefiniti da /apex/com.android.conscrypt/cacerts/. È essenziale regolare i permessi e le etichette SELinux di questi certificati di conseguenza.

  2. Bind Mounting per Zygote: Utilizzando nsenter, si entra nel namespace di mount di Zygote. Zygote, essendo il processo responsabile del lancio delle applicazioni Android, richiede questo passaggio per garantire che tutte le applicazioni avviate in seguito utilizzino i nuovi certificati CA 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 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 utilizzato per entrare singolarmente nel namespace di ciascuna app 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

  1. Approccio Alternativo - Riavvio Soft: Un metodo alternativo prevede di 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 affrontare singolarmente ogni app in esecuzione. Tuttavia, questo metodo è generalmente meno preferito a causa dell'inconveniente del riavvio.

Riferimenti

Impara l'hacking su AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

PreviousGoogle CTF 2018 - Shall We Play a Game?NextIntent Injection

Last updated