11 KiB
Installazione del Certificato Burp
Impara l'hacking di AWS da zero a esperto con htARTE (Esperto Red Team AWS di HackTricks)!
Altri modi per supportare HackTricks:
- Se desideri vedere la tua azienda pubblicizzata su HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!
- Ottieni il merchandising ufficiale PEASS & HackTricks
- Scopri La Famiglia PEASS, la nostra collezione di NFT esclusivi
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @carlospolopm.
- Condividi i tuoi trucchi di hacking inviando PR a HackTricks e HackTricks Cloud github repos.
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 trasformalo 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 come:
{% code overflow="wrap" %}
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system
{% endcode %}
Quindi, per configurare il certificato di Burp, eseguire:
{% code overflow="wrap" %}
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
{% endcode %}
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 di Burp perché il filesystem è in sola lettura e non puoi rimontarlo in scrittura, c'è un altro modo.
Spiegato in questo video devi:
- Installare un certificato CA: Basta trascinare e rilasciare il certificato Burp DER cambiando l'estensione in
.crtsul cellulare in modo che sia memorizzato nella cartella Download e vai suInstalla un certificato->Certificato CA
- Verifica che il certificato sia stato memorizzato correttamente andando su
Credenziali attendibili->UTENTE
- Renderlo attendibile dal sistema: Scarica il modulo Magisc MagiskTrustUserCerts (un file .zip), trascinalo e rilascialo nel telefono, vai all'app Magics sul telefono nella sezione
Moduli, clicca suInstalla da archivio, seleziona il modulo.zipe una volta installato riavvia il telefono:
- Dopo il riavvio, vai su
Credenziali attendibili->SISTEMAe controlla che il certificato di Postswigger sia presente
Dopo Android 14
Nell'ultima versione di Android 14, si è osservato un cambiamento significativo nella gestione dei certificati di Autorità di Certificazione (CA) attendibili dal 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 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 come scrivibile 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, all'avvio del 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 /apex privato, isolando così le modifiche a questa directory da altri processi.
Tuttavia, esiste un workaround per coloro che hanno bisogno di modificare i certificati CA attendibili 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 di queste modifiche su tutto il sistema, si consiglia di riavviare il system_server, che riavvia efficacemente tutte le applicazioni e porta 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 tramite NSEnter
- Impostazione di una directory scrivibile: Inizialmente, viene stabilita una directory scrivibile montando un
tmpfssulla directory esistente delle certificazioni di sistema non APEX. Questo viene realizzato con il seguente comando:
mount -t tmpfs tmpfs /system/etc/security/cacerts
- Preparazione dei certificati CA: Dopo aver configurato la directory scrivibile, i certificati CA che si intendono utilizzare dovrebbero essere copiati in questa directory. Ciò 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. - 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 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 assicura che ogni nuova app avviata rispetterà la configurazione aggiornata dei certificati CA.
- Applicare le Modifiche alle App in Esecuzione: Per applicare le modifiche alle applicazioni già in esecuzione,
nsenterviene 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
- 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 comandistop && 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.