Zainstaluj certyfikat Burp

Reading time: 9 minutes

Proxy systemowe przez ADB

Skonfiguruj globalny proxy HTTP, aby wszystkie aplikacje kierowały ruch przez swó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ć certyfikat Der z Burp. Możesz to zrobić w Proxy --> Options --> Import / Export CA certificate

Export the certificate in Der format i przekształćmy go do formatu, który Android będzie w stanie rozpoznać. 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:

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

Gdy maszyna zakończy ponowne uruchamianie certyfikat Burp będzie przez nią używany!

Using Magisc

Jeśli rootowałeś urządzenie za pomocą Magisc (np. emulator), i nie możesz wykonać poprzednich kroków aby zainstalować certyfikat Burp ponieważ filesystem jest tylko do odczytu i nie możesz go zamontować jako zapisywalny, istnieje inny sposób.

Wyjaśnione w this video trzeba:

1. Zainstalować certyfikat CA: Po prostu przeciągnij i upuść DER Burp certificate zmieniając rozszerzenie na .crt na urządzeniu mobilnym, tak aby został zapisany w folderze Downloads i przejdź do Install a certificate -> CA certificate

• Sprawdź, czy certyfikat został poprawnie zapisany, przechodząc do Trusted credentials -> USER

2. Uczyń go zaufanym w systemie: Pobierz moduł Magisc MagiskTrustUserCerts (plik .zip), przeciągnij i upuść go na telefon, otwórz Magics app na telefonie, przejdź do sekcji Modules, kliknij Install from storage, wybierz moduł .zip i po instalacji zrestartuj telefon:

• Po restarcie, przejdź do Trusted credentials -> SYSTEM i sprawdź, czy Postswigger cert tam jest

Learn how to create a Magisc module

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

Po Android 14

W najnowszym wydaniu Android 14 zaobserwowano znaczącą zmianę w obsłudze system-trusted Certificate Authority (CA) certificates. Wcześniej certyfikaty te były przechowywane w /system/etc/security/cacerts/, dostępne i modyfikowalne przez użytkowników z uprawnieniami root, co pozwalało na natychmiastowe zastosowanie 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 natury jest niemutowalny.

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 obejdą niemutowalności; aplikacje nadal będą dostępowały oryginalnych danych certyfikatów niezależnie od zmian na poziomie filesystemu. Ta odporność wynika z tego, że montowanie /apex jest skonfigurowane z PRIVATE propagation, zapewniając, że jakiekolwiek modyfikacje wewnątrz katalogu /apex nie wpływają na inne procesy.

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

Niemniej jednak istnieje obejście dla tych, którzy muszą zmodyfikować system-trusted CA certificates w katalogu /apex. Polega ono na ręcznym ponownym zamontowaniu /apex w celu usunięcia PRIVATE propagation, dzięki czemu staje się zapisywalny. Proces obejmuje skopiowanie zawartości /apex/com.android.conscrypt w inne miejsce, odmontowanie katalogu /apex/com.android.conscrypt aby usunąć ograniczenie tylko do odczytu, a następnie przywrócenie zawartości na jej oryginalne miejsce w /apex. Podejście to wymaga szybkiego działania, aby uniknąć awarii systemu. Aby zapewnić zastosowanie tych 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 przez NSEnter

1. Utworzenie zapisywalnego katalogu: Początkowo tworzy się zapisywalny katalog, montując tmpfs nad istniejącym katalogiem certyfikatów systemowych non-APEX. Robi się to za pomocą następującego polecenia:

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 obejmować skopiowanie domyślnych certyfikatów z /apex/com.android.conscrypt/cacerts/. Konieczne jest odpowiednie ustawienie uprawnień i etykiet SELinux dla tych certyfikatów.
3. Montowanie bind dla Zygote: Za pomocą nsenter wchodzi się do mount namespace Zygote. Zygote, będący procesem odpowiedzialnym za uruchamianie aplikacji Android, wymaga tego kroku, aby zapewnić, że wszystkie uruchamiane dalej aplikacje będą korzystać z nowo skonfigurowanych certyfikatów CA. Używane polecenie to:

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 będzie korzystać ze zaktualizowanego zestawu certyfikatów CA.

4. Applying Changes to Running Apps: Aby zastosować zmiany w już działających aplikacjach, ponownie używa się nsenter, aby wejść do namespace każdej aplikacji osobno 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

5. Alternative Approach - Soft Reboot: Alternatywna metoda polega na wykonaniu bind mount na procesie init (PID 1), a następnie użyciu soft reboot systemu operacyjnego za pomocą poleceń stop && start. Podejście to spowoduje propagację zmian we wszystkich namespaces, dzięki czemu nie trzeba indywidualnie obsługiwać każdej uruchomionej app. Jednak metoda ta jest zazwyczaj mniej preferowana ze względu na niedogodności związane z rebootowaniem.

Referencje

• Android 14: Install a system CA certificate on a rooted device
• Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa