Встановлення сертифіката 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
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.
Системний проксі через ADB
Налаштуйте глобальний HTTP-проксі так, щоб увесь трафік додатків маршрутизувався через ваш interceptor (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
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
.
Наприклад, ви можете запустити її так:
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system
Тоді, щоб налаштувати burps certificate, зробіть:
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 і ви не можете перемонтувати його в режим запису, є інший спосіб.
Пояснено в цьому відео: вам потрібно:
- Встановити CA-сертифікат: Просто перетягніть DER Burp certificate, змінивши розширення на
.crt
на мобільному пристрої, щоб він зберігся в папці Downloads, і перейдіть доInstall a certificate
->CA certificate
.png)
- Перевірте, що сертифікат правильно збережено, перейшовши до
Trusted credentials
->USER
.png)
- Зробити його довіреним системно: Завантажте Magisc модуль MagiskTrustUserCerts (файл .zip), перетягніть його в телефон, відкрийте додаток Magics на телефоні у секції
Modules
, натиснітьInstall from storage
, виберіть.zip
модуль і після встановлення reboot телефон:
.png)
- Після перезавантаження перейдіть до
Trusted credentials
->SYSTEM
і перевірте, що сертифікат Postswigger там присутній
.png)
Дізнайтеся, як створити модуль Magisc
Після 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
, що фактично перезапустить всі додатки і приведе систему до узгодженого стану.
# 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
- Налаштування записуваного каталогу: Спочатку створюється записуваний каталог шляхом примонтування
tmpfs
поверх існуючого non-APEX системного каталогу сертифікатів. Це досягається наступною командою:
mount -t tmpfs tmpfs /system/etc/security/cacerts
- Preparing CA Certificates: Після налаштування записуваного каталогу, CA-сертифікати, які планується використовувати, потрібно скопіювати в цей каталог. Це може включати копіювання стандартних сертифікатів з
/apex/com.android.conscrypt/cacerts/
. Важливо відповідно налаштувати права доступу та SELinux мітки цих сертифікатів. - Bind Mounting for Zygote: Використовуючи
nsenter
, потрапляють у mount namespace Zygote. Zygote, процес, який відповідає за запуск Android-додатків, вимагає цього кроку, щоб усі додатки, що запускатимуться надалі, використовували щойно налаштовані CA-сертифікати. Команда, що використовується:
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
Це гарантує, що кожен новий додаток при запуску буде дотримуватись оновлених налаштувань CA-сертифікатів.
- Застосування змін до запущених додатків: Щоб застосувати зміни до вже запущених програм,
nsenter
знову використовується, щоб увійти в namespace кожного додатка окремо та виконати аналогічний bind mount. Необхідна команда:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
- Alternative Approach - Soft Reboot: Альтернативний метод полягає в тому, щоб виконати bind mount на процесі
init
(PID 1), а потім зробити м'яке перезавантаження операційної системи за допомогою командstop && start
. Цей підхід поширює зміни на всі namespaces, уникаючи необхідності звертатися до кожного запущеного додатку окремо. Однак цей метод загалом менш бажаний через незручності, пов'язані з перезавантаженням.
References
- Android 14: Install a system CA certificate on a rooted device
- Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa
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
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.