Zainstaluj certyfikat Burp

Tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się i ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Przeglądaj pełny katalog HackTricks Training dla ścieżek assessment (ARTA/GRTA/AzRTA) oraz Linux Hacking Expert (LHE).

Wsparcie HackTricks

Proxy systemowy przez ADB

Skonfiguruj globalny proxy HTTP, aby wszystkie aplikacje kierowały ruch przez twój interceptor (Burp/mitmproxy):

# Set proxy (device/emulator must reach your host IP)
adb shell settings put global http_proxy 192.168.1.2:8080

# Clear proxy
adb shell settings put global http_proxy :0

Tip: In Burp, bind your listener to 0.0.0.0 so devices on the LAN can connect (Proxy -> Options -> Proxy Listeners).

Na maszynie wirtualnej

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

Export the certificate in Der format and lets transform it to a form that Android is going to be able to understand. Note that in order to configure the burp certificate on the Android machine in AVD you need to run this machine with the -writable-system option.
For example you can run it like:

C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system

Następnie, aby skonfigurować certyfikat burps, wykonaj:

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

Po zakończeniu ponownego uruchamiania maszyny certyfikat Burp będzie przez nią używany!

Używanie Magisk

Jeśli zrootowałeś urządzenie za pomocą Magisk (np. emulator) i nie możesz wykonać poprzednich kroków instalacji certyfikatu Burp, ponieważ system plików jest tylko do odczytu i nie możesz go zamontować do zapisu, istnieje inny sposób.

Wyjaśnione w this video musisz:

  1. Zainstaluj certyfikat CA: Po prostu przeciągnij i upuść DER certyfikat Burp, zmieniając rozszerzenie na .crt na urządzeniu mobilnym, tak aby został zapisany w folderze Pobrane i przejdź do Install a certificate -> CA certificate
  • Sprawdź, czy certyfikat został poprawnie zapisany, przechodząc do Trusted credentials -> USER
  1. Uczyń go zaufanym przez system: Pobierz moduł Magisk MagiskTrustUserCerts (plik .zip), przeciągnij i upuść go na telefon, otwórz aplikację Magisk na telefonie w sekcji Modules, kliknij Install from storage, wybierz moduł .zip i po instalacji uruchom ponownie telefon:
  • Po ponownym uruchomieniu przejdź do Trusted credentials -> SYSTEM i sprawdź, czy certyfikat Postswigger jest tam obecny

Alternatywa: AlwaysTrustUserCerts (Android 7-16 Beta)

Jeśli jesteś na Android 14+ (lub na starszych urządzeniach, które otrzymały aktualizacje Conscrypt Mainline i teraz używają /apex/com.android.conscrypt/cacerts), moduł Magisk AlwaysTrustUserCerts automatyzuje bind-mounting wymagany dla zaufania systemowego. Mirroruje certyfikaty CA użytkownika do zaufania systemowego i wstrzykuje mounty do przestrzeni nazw Zygote/app, dzięki czemu aplikacje widzą certyfikaty bez ręcznej pracy z nsenter.

  1. Najpierw zainstaluj Burp CA jako certyfikat użytkownika.
  2. Zainstaluj moduł i uruchom ponownie.
  3. Jeśli moduł oferuje wybór, preferuj --rbind przy montowaniu /system/etc/security/cacerts do /apex/com.android.conscrypt/cacerts, aby zapewnić widoczność zagnieżdżonych mountów (z innych modułów).

Dowiedz się, jak stworzyć moduł Magisk

Sprawdź https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437

Po Androidzie 14

W najnowszym wydaniu Android 14 zaobserwowano istotną zmianę w sposobie obsługi certyfikatów urzędów certyfikacji (CA) zaufanych przez system.

Uwaga: Niektóre urządzenia z Android 12/13, które otrzymały aktualizacje Conscrypt Mainline, już używają /apex/com.android.conscrypt/cacerts. Jeśli ten katalog istnieje na Twoim urządzeniu, musisz użyć tej samej techniki wstrzykiwania APEX opisanej poniżej.

Wcześniej te certyfikaty były przechowywane w /system/etc/security/cacerts/, dostępnym i modyfikowalnym dla użytkowników z uprawnieniami root, co pozwalało na natychmiastowe zastosowanie zmian w całym systemie. Jednak w Android 14 lokalizacja przechowywania została przeniesiona do /apex/com.android.conscrypt/cacerts, katalogu w ścieżce /apex, który z założenia jest niemutowalny.

Próby ponownego zamontowania ścieżki APEX cacerts jako zapisywalnej kończą się niepowodzeniem, ponieważ system tego nie pozwala. Nawet próby odmontowania lub nakładania katalogu przy użyciu tymczasowego systemu plików (tmpfs) nie obchodzą niemutowalności; aplikacje nadal odczytują oryginalne dane certyfikatów niezależnie od zmian na poziomie systemu plików. Ta odporność wynika z faktu, że mount /apex jest skonfigurowany z propagacją PRIVATE, co zapewnia, że jakiekolwiek modyfikacje wewnątrz katalogu /apex nie wpływają na inne procesy.

Inicjalizacja Androida obejmuje proces init, który przy uruchamianiu systemu uruchamia również proces Zygote. Proces ten odpowiada za uruchamianie procesów aplikacji z nową przestrzenią nazw montowania, która zawiera prywatny mount /apex, izolując zmiany w tym katalogu od innych procesów.

Istnieje jednak obejście dla osób, które muszą modyfikować certyfikaty CA zaufane przez system w katalogu /apex. Polega ono na ręcznym ponownym zamontowaniu /apex w celu usunięcia propagacji PRIVATE, co umożliwia zapis. Proces 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 pierwotnej lokalizacji w /apex. Ta metoda wymaga szybkiego działania, aby uniknąć awarii systemu. Aby zapewnić zastosowanie zmian w całym systemie, zaleca się ponowne uruchomienie system_server, co efektywnie restartuje wszystkie aplikacje i przywraca system do spójnego stanu.

# 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. Utworzenie zapisywalnego katalogu: Najpierw tworzy się zapisywalny katalog, montując tmpfs nad istniejącym nie-APEX katalogiem certyfikatów systemowych. Osiąga się to za pomocą następującego polecenia:
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. Preparing CA Certificates: Po skonfigurowaniu zapisywalnego katalogu, 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/. Konieczne jest odpowiednie dostosowanie uprawnień oraz etykiet SELinux tych certyfikatów.
  2. Bind Mounting for Zygote: Korzystając z nsenter, wchodzi się do mount namespace procesu Zygote. Zygote, jako proces odpowiedzialny za uruchamianie aplikacji Android, 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:

Tip: If /system/etc/security/cacerts contains nested mounts (common with Magisk modules), use --rbind instead of --bind so those mounts propagate into app namespaces.

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
# If /system/etc/security/cacerts includes nested mounts, prefer --rbind
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --rbind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

To zapewnia, że każda nowo uruchomiona aplikacja będzie korzystać z zaktualizowanej konfiguracji certyfikatów CA.

  1. Zastosowanie zmian w działających aplikacjach: Aby zastosować zmiany w już działających aplikacjach, nsenter jest ponownie używany, aby wejść do przestrzeni nazw każdej aplikacji indywidualnie i wykonać podobny bind mount. Niezbędne polecenie to:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. Alternatywne podejście - Soft Reboot: Alternatywną metodą jest wykonanie bind mount na procesie init (PID 1), a następnie soft reboot systemu operacyjnego za pomocą poleceń stop && start. Podejście to spowoduje propagację zmian do wszystkich namespaces, unikając konieczności indywidualnego obsługiwania każdej uruchomionej app. Jednak ta metoda jest zwykle mniej preferowana ze względu na niedogodność związaną z rebootowaniem.

Referencje

Tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się i ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Przeglądaj pełny katalog HackTricks Training dla ścieżek assessment (ARTA/GRTA/AzRTA) oraz Linux Hacking Expert (LHE).

Wsparcie HackTricks