Встановлення сертифіката Burp

Reading time: 8 minutes

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Системний проксі через ADB

Налаштуйте глобальний HTTP-проксі так, щоб увесь трафік додатків маршрутизувався через ваш interceptor (Burp/mitmproxy):

bash
# 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).

На віртуальній машині

Перш за все потрібно завантажити Der certificate з Burp. Ви можете зробити це в Proxy --> Options --> Import / Export CA certificate

Експортуйте сертифікат у форматі Der і давайте перетворимо його у формат, який Android зможе зрозуміти. Зверніть увагу, що щоб налаштувати Burp certificate на Android машині в AVD вам потрібно запустити цю машину з опцією -writable-system.
Наприклад, ви можете запустити її так:

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

Тоді, щоб налаштувати burps certificate, зробіть:

bash
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

Як тільки машина завершить перезавантаження, сертифікат burp буде використовуватися нею!

Використання Magisc

Якщо ви rooted your device with Magisc (можливо емулятор), і ви can't follow попередні steps для встановлення Burp cert, тому що filesystem is read-only і ви не можете перемонтувати його в режим запису, є інший спосіб.

Пояснено в цьому відео: вам потрібно:

  1. Встановити CA-сертифікат: Просто перетягніть DER Burp certificate, змінивши розширення на .crt на мобільному пристрої, щоб він зберігся в папці Downloads, і перейдіть до Install a certificate -> CA certificate
  • Перевірте, що сертифікат правильно збережено, перейшовши до Trusted credentials -> USER
  1. Зробити його довіреним системно: Завантажте Magisc модуль MagiskTrustUserCerts (файл .zip), перетягніть його в телефон, відкрийте додаток Magics на телефоні у секції Modules, натисніть Install from storage, виберіть .zip модуль і після встановлення reboot телефон:
  • Після перезавантаження перейдіть до Trusted credentials -> SYSTEM і перевірте, що сертифікат Postswigger там присутній

Дізнайтеся, як створити модуль Magisc

Перегляньте https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437

Після Android 14

У новому релізі Android 14 сталося суттєве зміщення в обробці системно-довірених сертифікатів центру сертифікації (CA). Раніше ці сертифікати зберігалися в /system/etc/security/cacerts/, були доступні та змінювані користувачами з правами root, що дозволяло негайно застосувати їх в системі. Однак в Android 14 місце зберігання було переміщено до /apex/com.android.conscrypt/cacerts, директорії всередині шляху /apex, яка за своєю суттю є незмінною.

Спроби перемонтувати APEX cacerts path в режим запису зазнають невдачі, оскільки система не дозволяє такі операції. Навіть спроби відмонтувати або перекрити директорію тимчасовою файловою системою (tmpfs) не обходять незмінність; додатки продовжують звертатися до оригінальних даних сертифікатів незалежно від змін на рівні файлової системи. Ця стійкість зумовлена тим, що монтування /apex сконфігуроване з PRIVATE propagation, що гарантує, що будь-які модифікації всередині директорії /apex не впливають на інші процеси.

Ініціалізація Android включає процес init, який при старті ОС також запускає процес Zygote. Цей процес відповідає за запуск процесів додатків з новою просторою монтів, яка включає приватне монтування /apex, тим самим ізолюючи зміни в цій директорії від інших процесів.

Проте існує обхідний шлях для тих, хто потребує змінити системно-довірені CA сертифікати в директорії /apex. Це включає ручне перемонтування /apex з метою видалити PRIVATE propagation, роблячи його записуваним. Процес включає копіювання вмісту /apex/com.android.conscrypt в інше місце, відмонтування директорії /apex/com.android.conscrypt щоб усунути обмеження лише для читання, а потім відновлення вмісту назад у початкове місце всередині /apex. Цей підхід вимагає швидких дій, щоб уникнути краху системи. Щоб забезпечити застосування цих змін по всій системі, рекомендується перезапустити system_server, що фактично перезапустить всі додатки і приведе систему до узгодженого стану.

bash
# 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. Налаштування записуваного каталогу: Спочатку створюється записуваний каталог шляхом примонтування tmpfs поверх існуючого non-APEX системного каталогу сертифікатів. Це досягається наступною командою:
bash
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. Preparing CA Certificates: Після налаштування записуваного каталогу, CA-сертифікати, які планується використовувати, потрібно скопіювати в цей каталог. Це може включати копіювання стандартних сертифікатів з /apex/com.android.conscrypt/cacerts/. Важливо відповідно налаштувати права доступу та SELinux мітки цих сертифікатів.
  2. Bind Mounting for Zygote: Використовуючи nsenter, потрапляють у mount namespace Zygote. Zygote, процес, який відповідає за запуск Android-додатків, вимагає цього кроку, щоб усі додатки, що запускатимуться надалі, використовували щойно налаштовані CA-сертифікати. Команда, що використовується:
bash
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

Це гарантує, що кожен новий додаток при запуску буде дотримуватись оновлених налаштувань CA-сертифікатів.

  1. Застосування змін до запущених додатків: Щоб застосувати зміни до вже запущених програм, nsenter знову використовується, щоб увійти в namespace кожного додатка окремо та виконати аналогічний bind mount. Необхідна команда:
bash
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. Alternative Approach - Soft Reboot: Альтернативний метод полягає в тому, щоб виконати bind mount на процесі init (PID 1), а потім зробити м'яке перезавантаження операційної системи за допомогою команд stop && start. Цей підхід поширює зміни на всі namespaces, уникаючи необхідності звертатися до кожного запущеного додатку окремо. Однак цей метод загалом менш бажаний через незручності, пов'язані з перезавантаженням.

References

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks