12 KiB
Instalacja certyfikatu Burp
Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!
Inne sposoby wsparcia HackTricks:
- Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź PLAN SUBSKRYPCJI!
- Zdobądź oficjalne gadżety PEASS & HackTricks
- Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
- Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @carlospolopm.
- Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów GitHub.
Na maszynie wirtualnej
Po pierwsze, 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 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 uruchomić ją 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 następujące kroki:
{% 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 uruchamiania urządzenia certyfikat Burp będzie używany przez nie!
Używanie Magisc
Jeśli zrootowałeś swoje urządzenie za pomocą Magisc (może to być 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żna go zamontować jako zapisywalny, istnieje inny sposób.
Jak wyjaśniono w tym filmie, musisz:
- Zainstalować certyfikat CA: Po prostu przeciągnij i upuść certyfikat Burp w formacie DER, zmieniając rozszerzenie na
.crt
na urządzeniu mobilnym, aby był przechowywany w folderze Pobrane, a następnie przejdź doZainstaluj certyfikat
->Certyfikat CA
- Sprawdź, czy certyfikat został poprawnie zapisany, przechodząc do
Zaufane poświadczenia
->UŻYTKOWNIK
- Uczyń go zaufanym przez system: Pobierz moduł Magisc MagiskTrustUserCerts (plik .zip), przeciągnij i upuść go na telefonie, przejdź do aplikacji Magics na telefonie, do sekcji
Moduły
, kliknijZainstaluj 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 znaczącą zmianę w obsłudze certyfikatów autoryzują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 posiadających uprawnienia root, co umożliwiało natychmiastowe zastosowanie ich w całym systemie. Jednak w przypadku Androida 14 lokalizacja przechowywania została przeniesiona do /apex/com.android.conscrypt/cacerts
, katalogu w ścieżce /apex
, który jest niezmienialny z natury.
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ą niezmienności; aplikacje nadal mają 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 uruchomieniu procesu init
, który przy uruchamianiu systemu operacyjnego inicjuje również proces Zygote. Proces ten jest odpowiedzialny za uruchamianie procesów aplikacji w nowej przestrzeni nazw montowania, która obejmuje prywatne montowanie /apex
, izolując tym samym zmiany w tym katalogu od innych procesów.
Mimo to istnieje obejście dla tych, którzy muszą modyfikować certyfikaty CA zaufane przez system w katalogu /apex
. Polega to na ręcznym ponownym zamontowaniu /apex
, aby usunąć propagację PRIVATE i umożliwić zapisywanie. 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 jej pierwotnego miejsca w /apex
. Ten sposób wymaga szybkiego działania, aby uniknąć awarii systemu. Aby zapewnić zastosowanie tych zmian w całym systemie, zaleca się ponowne uruchomienie system_server
, co skutkuje ponownym uruchomieniem wszystkich aplikacji i przywróceniem systemu 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 katalogu za pomocą NSEnter
- Konfiguracja zapisywalnego katalogu: Na początku, ustanawiany jest zapisywalny katalog poprzez zamontowanie
tmpfs
nad istniejącym katalogiem certyfikatów systemowych nie-APEX. Można to osiągnąć za pomocą następującej komendy:
mount -t tmpfs tmpfs /system/etc/security/cacerts
-
Przygotowanie certyfikatów CA: Po skonfigurowaniu katalogu z możliwością zapisu, należy skopiować do niego zamierzone certyfikaty CA. Może to wymagać skopiowania domyślnych certyfikatów z
/apex/com.android.conscrypt/cacerts/
. Ważne jest odpowiednie dostosowanie uprawnień i etykiet SELinux tych certyfikatów. -
Bind Mounting dla Zygote: Korzystając z
nsenter
, wchodzimy do przestrzeni nazw montowania Zygote. Zygote, będący procesem odpowiedzialnym za uruchamianie aplikacji Androida, 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 uruchomiona aplikacja będzie przestrzegać zaktualizowanego ustawienia certyfikatów CA.
- Zastosowanie zmian do działających aplikacji: Aby zastosować zmiany do już uruchomionych aplikacji, ponownie używamy
nsenter
, aby wejść do przestrzeni nazw każdej aplikacji indywidualnie i wykonać podobne zamontowanie. Wymagane 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ę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 propaguje zmiany we wszystkich przestrzeniach nazw, eliminując konieczność indywidualnego adresowania każdej uruchomionej aplikacji. Jednak ta metoda jest zazwyczaj mniej preferowana ze względu na niedogodność ponownego uruchamiania systemu.
Referencje
Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!
Inne sposoby wsparcia HackTricks:
- Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź PLAN SUBSKRYPCJI!
- Zdobądź oficjalne gadżety PEASS & HackTricks
- Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
- Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @carlospolopm.
- Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud github repos.