mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-29 22:43:11 +00:00
158 lines
11 KiB
Markdown
158 lines
11 KiB
Markdown
# Zainstaluj certyfikat Burp
|
|
|
|
<details>
|
|
|
|
<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Inne sposoby wsparcia HackTricks:
|
|
|
|
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](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.
|
|
|
|
</details>
|
|
|
|
## Na maszynie wirtualnej
|
|
|
|
Po pierwsze, musisz pobrać certyfikat Der z Burp. Możesz to zrobić w _**Proxy**_ --> _**Opcje**_ --> _**Importuj/Eksportuj certyfikat CA**_
|
|
|
|
.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 ją uruchomić tak:
|
|
|
|
{% 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**, wykonaj:
|
|
|
|
{% 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 uruchomienia urządzenia** certyfikat Burp będzie używany przez nie!
|
|
|
|
## Korzystanie z Magisc
|
|
|
|
Jeśli **zrootowałeś swoje urządzenie za pomocą Magisc** (być może emulatora) i **nie możesz wykonać** poprzednich **kroków** do zainstalowania certyfikatu Burp, ponieważ **system plików jest tylko do odczytu** i nie możesz go ponownie zamontować jako zapisywalny, istnieje inny sposób.
|
|
|
|
Wyjaśniono to w [**tym filmie**](https://www.youtube.com/watch?v=qQicUW0svB8) musisz:
|
|
|
|
1. **Zainstaluj certyfikat CA**: Po prostu **przeciągnij i upuść** certyfikat Burp w formacie DER, **zmieniając rozszerzenie** na `.crt` w telefonie komórkowym, aby był przechowywany w folderze Pobrane i przejdź do `Zainstaluj certyfikat` -> `Certyfikat CA`
|
|
|
|
<figure><img src="../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).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 (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt="" width="334"><figcaption></figcaption></figure>
|
|
|
|
2. **Zrób 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 na **`Zainstaluj z pamięci`**, wybierz moduł `.zip` i po zainstalowaniu **ponownie uruchom** telefon:
|
|
|
|
<figure><img src="../../.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).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 (3) (1) (1) (1) (1) (1) (1) (1).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 certyfikują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 z uprawnieniami roota, co pozwalało na natychmiastowe zastosowanie ich 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 niemutowalny.
|
|
|
|
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ą niemutowalności; aplikacje nadal uzyskują 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 procesie `init`, który po uruchomieniu systemu operacyjnego inicjuje również proces Zygote. Proces ten jest odpowiedzialny za uruchamianie procesów aplikacji w nowej przestrzeni montowania, która obejmuje prywatne montowanie **`/apex`**, izolując zmiany w tym katalogu od innych procesów.
|
|
|
|
Mimo to istnieje sposób obejścia dla osób potrzebujących modyfikować certyfikaty CA zaufane przez system w katalogu **`/apex`**. Polega to na ręcznym ponownym zamontowaniu **`/apex`**, aby usunąć propagację PRIVATE, co czyni go zapisywalnym. Proces 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 ich pierwotnego miejsca w **`/apex`**. Ten sposób postępowania wymaga szybkiej reakcji, 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"
|
|
```
|
|
### Montowanie katalogu poprzez NSEnter
|
|
|
|
1. **Konfiguracja katalogu z możliwością zapisu**: W pierwszej kolejności, ustanawiany jest katalog z możliwością zapisu poprzez zamontowanie `tmpfs` nad istniejącym katalogiem certyfikatów systemowych non-APEX. Można to osiągnąć za pomocą poniższej komendy:
|
|
```bash
|
|
mount -t tmpfs tmpfs /system/etc/security/cacerts
|
|
```
|
|
2. **Przygotowanie certyfikatów CA**: Po skonfigurowaniu katalogu z możliwością zapisu, certyfikaty CA, które zamierza się użyć, powinny zostać skopiowane do tego katalogu. Może to wymagać skopiowania domyślnych certyfikatów z `/apex/com.android.conscrypt/cacerts/`. Istotne jest odpowiednie dostosowanie uprawnień i etykiet SELinux tych certyfikatów.
|
|
3. **Bind Mounting dla Zygote**: Korzystając z `nsenter`, wchodzi się do przestrzeni nazw montowania Zygote. Zygote, będąc procesem odpowiedzialnym za uruchamianie aplikacji na Androidzie, 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 aplikacja rozpoczęta będzie przestrzegać zaktualizowanej konfiguracji certyfikatów CA.
|
|
|
|
4. **Zastosowanie zmian do działających aplikacji**: Aby zastosować zmiany do już działających aplikacji, ponownie używany jest `nsenter`, aby wejść do przestrzeni nazw każdej aplikacji indywidualnie i wykonać podobne podłączenie. 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`. Ten sposób spowoduje propagację zmian we wszystkich przestrzeniach nazw, eliminując konieczność indywidualnego adresowania każdej działającej aplikacji. Jednakże, ta metoda jest zazwyczaj mniej preferowana ze względu na niedogodność ponownego uruchamiania.
|
|
|
|
## Referencje
|
|
|
|
* [https://httptoolkit.com/blog/android-14-install-system-ca-certificate/](https://httptoolkit.com/blog/android-14-install-system-ca-certificate/)
|