# Instalacja certyfikatu Burp
Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)! Inne sposoby wsparcia HackTricks: * Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)! * Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com) * Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family) * **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.** * **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) **i** [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) **repozytoriów GitHub.**
## Na maszynie wirtualnej Po pierwsze, 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 w formę, 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ą tak: {% code overflow="wrap" %} ```bash C:\Users\\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**, wykonaj następujące kroki: {% 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 %} Po zakończeniu **ponownego uruchamiania urządzenia** certyfikat Burp będzie używany przez nie! ## Używanie Magisc Jeśli **zrootowałeś swoje urządzenie za pomocą Magisc** (może to być 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żna go zamontować jako zapisywalny, istnieje inny sposób. Jak wyjaśniono w [**tym filmie**](https://www.youtube.com/watch?v=qQicUW0svB8), musisz: 1. **Zainstalować certyfikat CA**: Po prostu **przeciągnij i upuść** certyfikat Burp w formacie DER, **zmieniając rozszerzenie** na `.crt` na urządzeniu mobilnym, aby był przechowywany w folderze Pobrane, a następnie przejdź do `Zainstaluj certyfikat` -> `Certyfikat CA`
* Sprawdź, czy certyfikat został poprawnie zapisany, przechodząc do `Zaufane poświadczenia` -> `UŻYTKOWNIK`
2. **Uczyń go zaufanym przez system**: Pobierz moduł Magisc [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (plik .zip), **przeciągnij i upuść go** na telefonie, przejdź do aplikacji **Magics** na telefonie, do sekcji **`Moduły`**, kliknij **`Zainstaluj z pamięci`**, wybierz moduł `.zip` i po zainstalowaniu **ponownie uruchom** telefon:
* Po ponownym uruchomieniu przejdź do `Zaufane poświadczenia` -> `SYSTEM` i sprawdź, czy certyfikat Postswigger jest tam
## Po Androidzie 14 W najnowszej wersji Androida 14 zaobserwowano znaczącą zmianę w obsłudze certyfikatów autoryzujących (CA) zaufanych przez system. Wcześniej te certyfikaty były przechowywane w **`/system/etc/security/cacerts/`**, dostępne i modyfikowalne przez użytkowników posiadających uprawnienia root, co umożliwiało natychmiastowe zastosowanie ich w całym systemie. Jednak w przypadku Androida 14 lokalizacja przechowywania została przeniesiona do **`/apex/com.android.conscrypt/cacerts`**, katalogu w ścieżce **`/apex`**, który jest niezmienialny z natury. Próby ponownego zamontowania ścieżki **APEX cacerts** jako zapisywalnej kończą się niepowodzeniem, ponieważ system nie zezwala na takie operacje. Nawet próby odmontowania lub nałożenia na katalog tymczasowego systemu plików (tmpfs) nie omijają niezmienności; aplikacje nadal mają dostęp do oryginalnych danych certyfikatów bez względu na zmiany na poziomie systemu plików. Ta odporność wynika z konfiguracji montowania **`/apex`** z propagacją PRIVATE, zapewniającą, że wszelkie modyfikacje w katalogu **`/apex`** nie wpływają na inne procesy. Inicjalizacja Androida polega na uruchomieniu procesu `init`, który przy uruchamianiu systemu operacyjnego inicjuje również proces Zygote. Proces ten jest odpowiedzialny za uruchamianie procesów aplikacji w nowej przestrzeni nazw montowania, która obejmuje prywatne montowanie **`/apex`**, izolując tym samym zmiany w tym katalogu od innych procesów. Mimo to istnieje obejście dla tych, którzy muszą modyfikować certyfikaty CA zaufane przez system w katalogu **`/apex`**. Polega to na ręcznym ponownym zamontowaniu **`/apex`**, aby usunąć propagację PRIVATE i umożliwić zapisywanie. Proces ten obejmuje skopiowanie zawartości **`/apex/com.android.conscrypt`** do innego miejsca, odmontowanie katalogu **`/apex/com.android.conscrypt`** w celu usunięcia ograniczenia tylko do odczytu, a następnie przywrócenie zawartości do jej pierwotnego miejsca w **`/apex`**. Ten sposób wymaga szybkiego działania, aby uniknąć awarii systemu. Aby zapewnić zastosowanie tych zmian w całym systemie, zaleca się ponowne uruchomienie `system_server`, co skutkuje ponownym uruchomieniem wszystkich aplikacji i przywróceniem systemu 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" ``` ### Montowanie katalogu za pomocą NSEnter 1. **Konfiguracja zapisywalnego katalogu**: Na początku, ustanawiany jest zapisywalny katalog poprzez zamontowanie `tmpfs` nad istniejącym katalogiem certyfikatów systemowych nie-APEX. Można to osiągnąć za pomocą następującej komendy: ```bash mount -t tmpfs tmpfs /system/etc/security/cacerts ``` 2. **Przygotowanie certyfikatów CA**: Po skonfigurowaniu katalogu z możliwością zapisu, należy skopiować do niego zamierzone certyfikaty CA. Może to wymagać skopiowania domyślnych certyfikatów z `/apex/com.android.conscrypt/cacerts/`. Ważne jest odpowiednie dostosowanie uprawnień i etykiet SELinux tych certyfikatów. 3. **Bind Mounting dla Zygote**: Korzystając z `nsenter`, wchodzimy do przestrzeni nazw montowania Zygote. Zygote, będący procesem odpowiedzialnym za uruchamianie aplikacji Androida, wymaga tego kroku, aby zapewnić, że wszystkie aplikacje uruchomione od tego momentu będą korzystać z nowo skonfigurowanych certyfikatów CA. Używane polecenie 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 uruchomiona aplikacja będzie przestrzegać zaktualizowanego ustawienia certyfikatów CA. 4. **Zastosowanie zmian do działających aplikacji**: Aby zastosować zmiany do już uruchomionych aplikacji, ponownie używamy `nsenter`, aby wejść do przestrzeni nazw każdej aplikacji indywidualnie i wykonać podobne zamontowanie. Wymagane 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ękkie ponowne uruchomienie**: Alternatywna metoda polega na wykonaniu bind mount na procesie `init` (PID 1), a następnie na miękkim ponownym uruchomieniu systemu operacyjnego za pomocą poleceń `stop && start`. To podejście propaguje zmiany we wszystkich przestrzeniach nazw, eliminując konieczność indywidualnego adresowania każdej uruchomionej aplikacji. Jednak ta metoda jest zazwyczaj mniej preferowana ze względu na niedogodność ponownego uruchamiania systemu. ## Referencje * [https://httptoolkit.com/blog/android-14-install-system-ca-certificate/](https://httptoolkit.com/blog/android-14-install-system-ca-certificate/)
Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)! Inne sposoby wsparcia HackTricks: * Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)! * Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com) * Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family) * **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.** * **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.