CVE-2020-0022

Огромное спасибо Insinuator за их потрясающий пост в блоге и код!

Results

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

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

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

Differences and Improvements

Этот эксплойт отличается от реализации 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 и извлекает смещения функций и гаджетов (чтобы упростить перенос эксплойта на другие цели)

Demo/Screenshots

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

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

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

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

Conclusion of the Exploit

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

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

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

Usage

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

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

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

Debugging

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

# On target
/data/local/tmp/gdbserver 0.0.0.0:1234 --attach $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}')

# On host
adb forward tcp:1234 tcp:1234
gdb-multiarch -q -x ./gdbinit

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

# On host
adb push ./gdbinit /data/local/tmp/gdbinit

# On target
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}') 
# OR
/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

Notes

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

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

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

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

• Сбой и перезапись PC успешно приводят к падению объекта chrome signal:

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