Ukranian - Ht
HackTricks Training Twitter Linkedin Sponsor

Install Burp Certificate

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

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

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

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

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

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

  1. Зробіть його довіреним системою: Завантажте модуль 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 налаштовано з приватним поширенням, що забезпечує, що будь-які зміни всередині каталогу /apex не впливають на інші процеси.

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

Тим не менш, існує обхідний шлях для тих, хто потребує змінити сертифікати CA, яким довіряє система, всередині каталогу /apex. Це включає в себе ручне повторне монтування /apex, щоб видалити приватне поширення, зробивши його доступним для запису. Процес включає копіювання вмісту /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"

Прив'язка через NSEnter

  1. Налаштування записуємого каталогу: Спочатку записуємий каталог встановлюється, монтуванням tmpfs над існуючим каталогом сертифікатів системи, який не є APEX. Це досягається за допомогою наступної команди:

mount -t tmpfs tmpfs /system/etc/security/cacerts

  1. Підготовка сертифікатів ЦС: Після налаштування записувального каталогу сертифікати ЦС, які ви маєте намір використовувати, слід скопіювати в цей каталог. Це може включати копіювання типових сертифікатів з /apex/com.android.conscrypt/cacerts/. Необхідно належним чином налаштувати дозволи та мітки SELinux для цих сертифікатів.

  2. Прив'язка монтування для Zygote: Використовуючи nsenter, ви входите в простір імен монтування Zygote. Zygote, який є процесом, відповідальним за запуск додатків Android, потребує цього кроку, щоб забезпечити, що всі додатки, запущені надалі, використовуватимуть нові налаштовані сертифікати ЦС. Використана команда:

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

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

  1. Застосування змін до запущених програм: Для застосування змін до вже запущених програм, знову використовується nsenter, щоб ввійти в простір імен кожної програми окремо та виконати аналогічне зв'язування монта. Необхідна команда:

nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

  1. Альтернативний підхід - М'який перезапуск: Альтернативний метод передбачає виконання прив'язки маршрутизації до процесу init (PID 1), за яким слідує м'який перезапуск операційної системи за допомогою команд stop && start. Цей підхід передбачає поширення змін у всіх просторах імен, уникнення необхідності окремо адресувати кожний запущений додаток. Однак цей метод, як правило, менше популярний через незручність перезавантаження.

Посилання

PreviousGoogle CTF 2018 - Shall We Play a Game?NextIntent Injection

Last updated