Встановлення сертифіката Burp
Reading time: 7 minutes
tip
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Підтримайте HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.
На віртуальній машині
По-перше, вам потрібно завантажити сертифікат Der з Burp. Ви можете зробити це в Proxy --> Options --> Import / Export CA certificate
Експортуйте сертифікат у форматі Der і давайте перетворимо його в форму, яку 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
Тоді, щоб налаштувати сертифікат burp, зробіть:
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
Якщо ви отримали root доступ до вашого пристрою за допомогою Magisc (можливо, емулятора), і ви не можете виконати попередні кроки для встановлення сертифіката Burp, оскільки файлова система є тільки для читання і ви не можете змонтувати її для запису, є інший спосіб.
У цьому відео вам потрібно:
- Встановити сертифікат CA: Просто перетягніть DER сертифікат Burp, змінивши розширення на
.crt
на мобільному, щоб він зберігся в папці Завантаження, і перейдіть доВстановити сертифікат
->CA сертифікат
.png)
- Перевірте, що сертифікат був правильно збережений, перейшовши до
Довірені облікові дані
->КОРИСТУВАЧ
.png)
- Зробіть його довіреним для системи: Завантажте модуль Magisc MagiskTrustUserCerts (файл .zip), перетягніть його на телефон, перейдіть до додатку Magics на телефоні в розділ
Модулі
, натиснітьВстановити з пам'яті
, виберіть модуль.zip
, і після встановлення перезавантажте телефон:
.png)
- Після перезавантаження перейдіть до
Довірені облікові дані
->СИСТЕМА
і перевірте, що сертифікат Postswigger там
.png)
Після Android 14
У останньому випуску Android 14 спостерігається значна зміна в обробці сертифікатів органів сертифікації (CA), яким довіряє система. Раніше ці сертифікати зберігалися в /system/etc/security/cacerts/
, доступні та змінювані користувачами з правами root, що дозволяло негайне застосування по всій системі. Однак з Android 14 місце зберігання було переміщено до /apex/com.android.conscrypt/cacerts
, каталогу в межах шляху /apex
, який за своєю природою є незмінним.
Спроби змонтувати шлях APEX cacerts як записуваний зазнають невдачі, оскільки система не дозволяє такі операції. Навіть спроби демонтувати або накласти тимчасову файлову систему (tmpfs) на каталог не обходять незмінність; програми продовжують отримувати доступ до оригінальних даних сертифіката, незважаючи на зміни на рівні файлової системи. Ця стійкість зумовлена тим, що монтаж /apex
налаштований з PRIVATE пропагандою, що забезпечує, щоб будь-які зміни в каталозі /apex
не впливали на інші процеси.
Ініціалізація Android включає процес init
, який, запускаючи операційну систему, також ініціює процес Zygote. Цей процес відповідає за запуск процесів додатків з новим простором монтування, який включає приватний монтаж /apex
, таким чином ізолюючи зміни в цьому каталозі від інших процесів.
Проте існує обхідний шлях для тих, хто потребує змінити сертифікати CA, яким довіряє система, в каталозі /apex
. Це передбачає ручне змонтування /apex
для видалення PRIVATE пропаганди, що робить його записуваним. Процес включає копіювання вмісту /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
поверх існуючої директорії системних сертифікатів, що не є APEX. Це досягається за допомогою наступної команди:
mount -t tmpfs tmpfs /system/etc/security/cacerts
- Підготовка CA сертифікатів: Після налаштування записуваної директорії, CA сертифікати, які планується використовувати, повинні бути скопійовані в цю директорію. Це може включати копіювання стандартних сертифікатів з
/apex/com.android.conscrypt/cacerts/
. Важливо відповідно налаштувати дозволи та мітки SELinux для цих сертифікатів. - Прив'язка для Zygote: Використовуючи
nsenter
, входять в простір імен монту 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
, щоб увійти в простір імен кожного додатку окремо та виконати подібне зв'язування. Необхідна команда:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
- Альтернативний підхід - М'який перезапуск: Альтернативний метод передбачає виконання прив'язки до процесу
init
(PID 1), після чого слідує м'який перезапуск операційної системи за допомогою командstop && start
. Цей підхід дозволить поширити зміни на всі простори імен, уникаючи необхідності окремо вирішувати питання з кожним запущеним додатком. Однак цей метод зазвичай менш бажаний через незручність перезавантаження.
References
tip
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Підтримайте HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.