Install Burp Certificate

Вивчайте та практикуйте 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.

Websec | Uw Cybersecurity Specialist

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

По-перше, вам потрібно завантажити сертифікат 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

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

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

Встановити сертифікат CA: Просто перетягніть DER сертифікат Burp, змінивши розширення на .crt на мобільному, щоб він зберігся в папці Завантаження, і перейдіть до Встановити сертифікат -> CA сертифікат

Перевірте, що сертифікат був правильно збережений, перейшовши до Довірені облікові дані -> КОРИСТУВАЧ

Зробіть його системно довіреним: Завантажте модуль Magisc MagiskTrustUserCerts (файл .zip), перетягніть його на телефон, перейдіть до додатку Magics на телефоні в розділ Модулі, натисніть Встановити з пам'яті, виберіть модуль .zip і після встановлення перезавантажте телефон:

Після перезавантаження перейдіть до Довірені облікові дані -> СИСТЕМА і перевірте, що сертифікат Postswigger там

Після 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. Цей підхід дозволить поширити зміни на всі простори імен, уникаючи необхідності окремо вирішувати питання з кожним запущеним додатком. Однак цей метод зазвичай менш бажаний через незручність перезавантаження.