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

Tip

Вчіться та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вчіться та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вчіться та практикуйте Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Перегляньте повний каталог HackTricks Training для assessment tracks (ARTA/GRTA/AzRTA) і Linux Hacking Expert (LHE).

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

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

Налаштуйте глобальний HTTP-проксі, щоб усі додатки направляли трафік через ваш перехоплювач (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

Порада: У Burp прив’яжіть свій listener до 0.0.0.0, щоб пристрої в LAN могли підключатися (Proxy -> Options -> Proxy Listeners).

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

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

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

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

Потім, щоб налаштувати сертифікат burps, виконайте:

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 certificate почне використовуватися!

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

Якщо ви отримали root-права на своєму пристрої через Magisk (можливо, емультор), і ви не можете виконати попередні кроки для встановлення Burp cert через те, що файлова система доступна лише для читання і її не вдається перемонтувати у режим запису, існує інший спосіб.

Пояснено в this video вам потрібно:

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

Alternative: AlwaysTrustUserCerts (Android 7-16 Beta)

Якщо ви на Android 14+ (або на старіших пристроях, які отримали оновлення Conscrypt Mainline і тепер використовують /apex/com.android.conscrypt/cacerts), Magisk-модуль AlwaysTrustUserCerts автоматизує bind-mounting, необхідний для системної довіри. Він дублює user CAs у системні довірені та інжектує точки монтування в простори імен Zygote/app, так що додатки бачать сертифікати без ручної роботи з nsenter.

  1. Спочатку встановіть Burp CA як user сертифікат.
  2. Встановіть модуль і перезавантажте.
  3. Якщо модуль пропонує вибір, віддайте перевагу --rbind при монтуванні /system/etc/security/cacerts в /apex/com.android.conscrypt/cacerts, щоб забезпечити видимість вкладених маунтів (від інших модулів).

Learn how to create a Magisk module

Дивіться https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437

Після Android 14

У найновішому релізі Android 14 спостерігається суттєва зміна в обробці системно довірених сертифікатів Certificate Authority (CA).

Note: Some Android 12/13 devices that received Conscrypt Mainline updates already use /apex/com.android.conscrypt/cacerts. If that directory exists on your device, you must use the same APEX injection technique described below.

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

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

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

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

# 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 системної директорії сертифікатів. Це виконується за допомогою наступної команди:
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-сертифікати. Використовується команда:

Tip: If /system/etc/security/cacerts contains nested mounts (common with Magisk modules), use --rbind instead of --bind so those mounts propagate into app namespaces.

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
# If /system/etc/security/cacerts includes nested mounts, prefer --rbind
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --rbind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

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

  1. Застосування змін до вже запущених додатків: Щоб застосувати зміни до вже запущених додатків, знову використовується nsenter для входу в простір імен кожного додатка окремо та виконання подібного bind mount. Необхідна команда:
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) з подальшим soft reboot операційної системи за допомогою команд stop && start. Цей підхід поширює зміни на всі namespaces, уникаючи необхідності окремо обробляти кожен запущений app. Однак цей метод зазвичай менш бажаний через незручність перезавантаження.

Посилання

Tip

Вчіться та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вчіться та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вчіться та практикуйте Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Перегляньте повний каталог HackTricks Training для assessment tracks (ARTA/GRTA/AzRTA) і Linux Hacking Expert (LHE).

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