Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 07:01:09 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/mobile-pentesting/android-app-pentesting/install-burp-certificate.md

11 KiB
Raw Blame History

Zainstaluj certyfikat Burp

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Na maszynie wirtualnej

Po pierwsze, musisz pobrać certyfikat Der z Burp. Możesz to zrobić w Proxy --> Opcje --> Importuj / Eksportuj certyfikat CA

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" %}

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" %}

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 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
  • Sprawdź, czy certyfikat został poprawnie zapisany, przechodząc do Zaufane poświadczenia -> UŻYTKOWNIK
  1. Zrób 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 na 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 znaczną zmianę w obsłudze systemowych certyfikatów certyfikujących (CA). 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 wraz z Androidem 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 mają dostęp do oryginalnych danych certyfikatu 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 odpowiada za uruchamianie procesów aplikacji z nową 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ć systemowe certyfikaty certyfikujące 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 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.

# 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 powiązane poprzez NSEnter

  1. Konfigurowanie 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:
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. 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.
  2. 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:
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.

  1. 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 montażowe. Wymagane 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 - 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 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