# Zainstaluj certyfikat Burp

{% hint style="success" %}
Ucz się i ćwicz Hacking AWS:<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">\
Ucz się i ćwicz Hacking GCP: <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>Wsparcie dla HackTricks</summary>

* Sprawdź [**plany subskrypcyjne**](https://github.com/sponsors/carlospolop)!
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegram**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Dziel się trikami hackingowymi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów 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/" %}

## Na maszynie wirtualnej

Przede wszystkim musisz pobrać certyfikat Der z Burp. Możesz to zrobić w _**Proxy**_ --> _**Options**_ --> _**Import / Export CA certificate**_

![](<../../.gitbook/assets/image (367).png>)

**Eksportuj certyfikat w formacie Der** i **przekształć** go do formy, którą **Android** będzie w stanie **zrozumieć.** Zauważ, że **aby skonfigurować certyfikat burp na maszynie Android w AVD** musisz **uruchomić** tę maszynę **z** opcją **`-writable-system`**.\
Na przykład możesz uruchomić ją w ten sposób:

{% 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 %}

Następnie, aby **skonfigurować certyfikat burp**:

{% 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 %}

Gdy **maszyna zakończy ponowne uruchamianie**, certyfikat burp będzie używany!

## Używanie Magisc

Jeśli **zrootowałeś swoje urządzenie za pomocą Magisc** (może emulator), i **nie możesz wykonać** poprzednich **kroków** w celu zainstalowania certyfikatu Burp, ponieważ **system plików jest tylko do odczytu** i nie możesz go zamontować jako zapisywalny, istnieje inny sposób.

Wyjaśnione w [**tym filmie**](https://www.youtube.com/watch?v=qQicUW0svB8) musisz:

1. **Zainstalować certyfikat CA**: Po prostu **przeciągnij i upuść** certyfikat DER Burp **zmieniając rozszerzenie** na `.crt` w telefonie, aby był przechowywany w folderze Pobrane, a następnie przejdź do `Zainstaluj certyfikat` -> `Certyfikat CA`

<figure><img src="../../.gitbook/assets/image (53).png" alt="" width="164"><figcaption></figcaption></figure>

* Sprawdź, czy certyfikat został poprawnie zapisany, przechodząc do `Zaufane poświadczenia` -> `UŻYTKOWNIK`

<figure><img src="../../.gitbook/assets/image (54).png" alt="" width="334"><figcaption></figcaption></figure>

2. **Uczynić go zaufanym przez system**: Pobierz moduł Magisc [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (plik .zip), **przeciągnij i upuść go** w telefonie, przejdź do aplikacji **Magics** w telefonie do sekcji **`Moduły`**, kliknij **`Zainstaluj z pamięci`**, wybierz moduł `.zip` i po zainstalowaniu **zrestartuj** telefon:

<figure><img src="../../.gitbook/assets/image (55).png" alt="" width="345"><figcaption></figcaption></figure>

* Po ponownym uruchomieniu przejdź do `Zaufane poświadczenia` -> `SYSTEM` i sprawdź, czy certyfikat Postswigger jest tam

<figure><img src="../../.gitbook/assets/image (56).png" alt="" width="314"><figcaption></figcaption></figure>

## Po Androidzie 14

W najnowszej wersji Androida 14 zaobserwowano znaczną zmianę w obsłudze certyfikatów urzędów certyfikacji (CA) zaufanych przez system. Wcześniej certyfikaty te znajdowały się w **`/system/etc/security/cacerts/`**, dostępne i modyfikowalne przez użytkowników z uprawnieniami roota, co pozwalało na natychmiastowe zastosowanie w całym systemie. Jednak w Androidzie 14 lokalizacja przechowywania została przeniesiona do **`/apex/com.android.conscrypt/cacerts`**, katalogu w ścieżce **`/apex`**, który jest z natury niemodyfikowalny.

Próby ponownego zamontowania **ścieżki APEX cacerts** jako zapisywalnej kończą się niepowodzeniem, ponieważ system nie pozwala na takie operacje. Nawet próby odmontowania lub nałożenia na katalog tymczasowego systemu plików (tmpfs) nie omijają niemodyfikowalności; aplikacje nadal uzyskują dostęp do oryginalnych danych certyfikatu, niezależnie od zmian na poziomie systemu plików. Ta odporność wynika z faktu, że montaż **`/apex`** jest skonfigurowany z propagacją PRIVATE, co zapewnia, że wszelkie modyfikacje w katalogu **`/apex`** nie wpływają na inne procesy.

Inicjalizacja Androida obejmuje proces `init`, który, uruchamiając system operacyjny, również inicjuje proces Zygote. Proces ten jest odpowiedzialny za uruchamianie procesów aplikacji z nową przestrzenią montowania, która obejmuje prywatny montaż **`/apex`**, izolując tym samym zmiany w tym katalogu od innych procesów.

Niemniej jednak istnieje obejście dla tych, którzy potrzebują zmodyfikować zaufane przez system certyfikaty CA w katalogu **`/apex`**. Polega to na ręcznym ponownym zamontowaniu **`/apex`**, aby usunąć propagację PRIVATE, co czyni go zapisywalnym. Proces ten obejmuje skopiowanie zawartości **`/apex/com.android.conscrypt`** do innej lokalizacji, odmontowanie katalogu **`/apex/com.android.conscrypt`**, aby wyeliminować ograniczenie tylko do odczytu, a następnie przywrócenie zawartości do ich pierwotnej lokalizacji w **`/apex`**. To podejście wymaga szybkiego działania, aby uniknąć awarii systemu. Aby zapewnić systemowe zastosowanie tych zmian, zaleca się ponowne uruchomienie `system_server`, co skutecznie restartuje wszystkie aplikacje i przywraca system do spójnego stanu.
```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. **Ustawienie zapisywalnego katalogu**: Początkowo, zapisywalny katalog jest tworzony przez zamontowanie `tmpfs` nad istniejącym katalogiem certyfikatów systemowych, który nie jest APEX. Osiąga się to za pomocą następującego polecenia:
```bash
mount -t tmpfs tmpfs /system/etc/security/cacerts
```
2. **Przygotowanie certyfikatów CA**: Po skonfigurowaniu zapisywalnego katalogu, certyfikaty CA, które zamierza się użyć, powinny zostać skopiowane do tego katalogu. Może to obejmować skopiowanie domyślnych certyfikatów z `/apex/com.android.conscrypt/cacerts/`. Ważne jest, aby odpowiednio dostosować uprawnienia i etykiety SELinux tych certyfikatów.  
3. **Zamontowanie dla Zygote**: Wykorzystując `nsenter`, wchodzi się do przestrzeni nazw montowania Zygote. Zygote, będący procesem odpowiedzialnym za uruchamianie aplikacji Android, wymaga tego kroku, aby zapewnić, że wszystkie aplikacje uruchamiane odtąd będą korzystać z nowo skonfigurowanych certyfikatów CA. Używana komenda to:
```bash
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
```
To zapewnia, że każda nowa aplikacja uruchomiona będzie przestrzegać zaktualizowanego ustawienia certyfikatów CA.

4. **Zastosowanie zmian w działających aplikacjach**: Aby zastosować zmiany w już działających aplikacjach, ponownie używa się `nsenter`, aby wejść do przestrzeni nazw każdej aplikacji indywidualnie i wykonać podobne powiązanie montażu. Niezbędne polecenie to:
```bash
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
```
5. **Alternatywne podejście - Miękki restart**: Alternatywna metoda polega na wykonaniu montażu wiązanego na procesie `init` (PID 1), a następnie na miękkim restarcie systemu operacyjnego za pomocą poleceń `stop && start`. To podejście propagowałoby zmiany we wszystkich przestrzeniach nazw, unikając potrzeby indywidualnego adresowania każdej działającej aplikacji. Jednak ta metoda jest zazwyczaj mniej preferowana z powodu niedogodności związanych z restartowaniem.

## References

* [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 %}