hacktricks/mobile-pentesting/android-app-pentesting/install-burp-certificate.md

182 lines
12 KiB
Markdown

# Installa Certificato Burp
{% hint style="success" %}
Impara e pratica AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Impara e pratica GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Supporta HackTricks</summary>
* Controlla i [**piani di abbonamento**](https://github.com/sponsors/carlospolop)!
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Condividi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.
</details>
{% endhint %}
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
## Su una Macchina Virtuale
Prima di tutto devi scaricare il certificato Der da Burp. Puoi farlo in _**Proxy**_ --> _**Options**_ --> _**Importa / Esporta certificato CA**_
![](<../../.gitbook/assets/image (367).png>)
**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ì:
{% code overflow="wrap" %}
```bash
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 fare**:
{% code overflow="wrap" %}
```bash
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 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**](https://www.youtube.com/watch?v=qQicUW0svB8) 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`
<figure><img src="../../.gitbook/assets/image (53).png" alt="" width="164"><figcaption></figcaption></figure>
* Controlla che il certificato sia stato memorizzato correttamente andando su `Credenziali attendibili` -> `UTENTE`
<figure><img src="../../.gitbook/assets/image (54).png" alt="" width="334"><figcaption></figcaption></figure>
2. **Rendere fidato di sistema**: Scarica il modulo Magisc [MagiskTrustUserCerts](https://github.com/NVISOsecurity/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:
<figure><img src="../../.gitbook/assets/image (55).png" alt="" width="345"><figcaption></figcaption></figure>
* Dopo il riavvio, vai su `Credenziali attendibili` -> `SISTEMA` e controlla che il certificato Postswigger sia presente
<figure><img src="../../.gitbook/assets/image (56).png" alt="" width="314"><figcaption></figcaption></figure>
## 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.
```bash
# 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:
```bash
mount -t tmpfs tmpfs /system/etc/security/cacerts
```
2. **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.
3. **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 è:
```bash
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.
4. **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 è:
```bash
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
```
5. **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/](https://httptoolkit.com/blog/android-14-install-system-ca-certificate/)
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Support HackTricks</summary>
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
{% endhint %}