Install Burp Certificate

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie dla HackTricks

Sprawdź plany subskrypcyjne!
Dołącz do 💬 grupy Discord lub grupy telegram lub śledź nas na Twitterze 🐦 @hacktricks_live.
Dziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów github.

Websec | Uw Cybersecurity Specialist

Na maszynie wirtualnej

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

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:

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 burp:

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 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 musisz:

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

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

Uczynić go zaufanym przez system: Pobierz moduł Magisc 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:

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 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.

# 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

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:

mount -t tmpfs tmpfs /system/etc/security/cacerts

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.
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:

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.

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:

nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

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.