CVE-2020-0022

Большое спасибо Insinuator за их замечательный пост в блоге и код!

Результаты

Все шаги, упомянутые в посте Insinuator, были выполнены и даже больше. Это слишком много шагов, чтобы помещать их в файл README.md, поэтому смело обращайтесь к упомянутому выше посту Insinuator.

Эксплойт полностью завершён до момента, когда:

1. Адрес управляемой атакующим достаточно большой области памяти утекает
2. Счётчик команд изменён, чтобы указывать на пользовательский адрес
3. Повторные попытки выполняются автоматически до тех пор, пока вероятность отказа значительно не снизится
4. Код оптимизирован с точки зрения времени отключения и скорости поиска в памяти до такой степени, что дальнейшая оптимизация ставит под угрозу стабильность эксплойта

Различия и улучшения

Этот эксплойт отличается от реализации Insinuator следующим образом:

1. Он написан на C, а не на Python (потому что я люблю C)
2. Он написан модульно, где каждый модуль отвечает за конкретную задачу
3. Он тестировался на Pixel 3 XL под управлением Android 9 (PQ3A.190801.002, уровень исправлений безопасности 2019-08-01), потому что это было у меня под рукой
4. Он утекает адреса в libandroid_runtime.so, а не в libicuuc.so, потому что это лучше работало на данном телефоне/цели
5. В нём реализованы две примерные цепочки JOP: одна вызывает execv напрямую, а другая вызывает fork, а затем execv
6. Он сопровождается пользовательским скриптом Ghidra, который обрабатывает файл libandroid_runtime.so и извлекает смещения функций и гаджетов (чтобы упростить перенос эксплойта на другие цели)

Демонстрация/Скриншоты

Это видеодемонстрация, показывающая, как эксплойт изменяет счётчик команд, чтобы указать на пользовательский адрес:

Первая итерация цепочки — та, которую можно увидеть в jop_experiment. Эта цепочка вызывает execv напрямую без вызова fork. Её можно найти в коммите ca28fdf. Вот что происходит при использовании этой цепочки:

Вторая итерация цепочки — та, которая вызывает fork, а затем execv. Полные детали этой цепочки можно найти здесь. Вот что происходит при использовании этой цепочки:

К счастью, Pixel 3 XL имеет защиту, которая предотвращает вызов fork и/или execv процессом Bluetooth. С точки зрения обмена знаниями или демонстрации, моя работа здесь завершена. Если я напишу и поделюсь чем-то более продвинутым, это может быть слишком полезно для чёрных шляп.

Заключение об эксплойте

Я считаю этот эксплойт завершённым. Возможные будущие улучшения:

• Написание цепочки JOP для вызова dlsym, а затем mprotect, чтобы запустить пользовательский шелл-код
• Сбор и сохранение базы данных смещений для разных целей
• Тестирование эксплойтов на нескольких целях для достижения относительной универсальности
• Объединение эксплойта с эксплойтом уровня ОС для получения привилегий root (как в моём предыдущем эксплойте CVE-2019-2215)
• И так далее...

Все эти вещи превращают этот проект из весёлого проекта по обмену знаниями в эксплойт для чёрных шляп, который можно использовать в качестве оружия, так что на этом моё путешествие заканчивается, пока.... Если у вас есть вопросы, смело связывайтесь.

Использование

Чтобы запустить эксплойт, просто выполните:

make build run ARGS="00:00:00:00:00:00" 

Где 00:00:00:00:00:00 — это MAC-адрес целевого устройства/жертвы. Кроме make clean, остальные цели сборки полезны только если вы пытаетесь модифицировать, улучшить или перереализовать эксплойт, поэтому нет необходимости подробно их описывать.

Отладка

• Бинарник gdbserver для Android можно найти в папке NDK
• Используйте это для отладки цели (не рекомендуется):

# На цели
/data/local/tmp/gdbserver 0.0.0.0:1234 --attach $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}')

# На хосте
adb forward tcp:1234 tcp:1234
gdb-multiarch -q -x ./gdbinit

• Напрямую на телефоне через gdb в termux (рекомендуется):

# На хосте
adb push ./gdbinit /data/local/tmp/gdbinit

# На цели
su
/data/data/com.termux/files/usr/bin/gdb -q -x /data/local/tmp/gdbinit -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 
# ИЛИ
/data/data/com.termux/files/usr/bin/gdb -q -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 

Вы можете перезапустить службу Bluetooth на машине атакующего, если она перестала работать:

sudo systemctl restart bluetooth.service

Заметки

В этом разделе объясняются некоторые явления, которые наблюдались во время разработки этого эксплойта:

• SSP отключён (при создании файлового дескриптора сокета HCI), чтобы предотвратить тайм-аут на удалённой цели:

• Мы распыляем пакеты очистки кучи, чтобы уменьшить вероятность сбоя цели из-за непреднамеренного переполнения, которое изменяет vtable объекта base::MessageLoop, используемого через get_message_loop:

• Это не было хорошо объяснено в посте Insinuator. Мы утекаем адрес пакета, пытаясь нацелиться на 32-байтовые куски malloc, которые включают один элемент связанного списка для каждого элемента в unordered_map partial_packets. Это было выяснено с помощью map_experiment map_experiment не соответствует тому, что утекает в реальной программе, поэтому я просто последовал шаблону Insinuator и использовал другой шаблон (который я также нашёл экспериментально).

• Сбой и перезапись счётчика команд успешно разрушают объект сигнала chrome

• Цепочка JOP была симулирована с помощью jop_experiment. Полная (первая, только execv) цепочка JOP объяснена в JOP_PLAN.md