hasan-khalil/cve-2020-6514Эксплойт для CVE-2020-6514, нацеленный на повреждение памяти WebRTC SCTP в приложениях Android. Использует Frida для перехвата нативных функций и изменения пакетов SCTP для удаленного выполнения кода.
Эксплойт При написании эксплойта я изначально изменял SCTP-пакеты, отправляемые на целевое устройство, путём изменения исходного кода WebRTC и его перекомпиляции. Это было непрактично для атак на закрытые приложения, поэтому я в итоге перешёл на использование Frida для перехвата бинарного файла атакующего устройства. Функциональность перехвата Frida позволяет выполнять код до и после вызова определённой нативной функции, что позволило моему эксплойту изменять исходящие SCTP-пакеты, а также проверять входящие. Функционально это эквивалентно изменению исходного кода атакующего клиента, но вместо изменений, вносимых в исходный код на этапе компиляции, они выполняются динамически с помощью Frida во время выполнения. Исходный код эксплойта доступен здесь.
Атакующему устройству необходимо перехватить семь функций, как показано ниже.
usrsctp_conninput // принимает входящие SCTP
DtlsTransport::SendPacket // отправляет исходящие SCTP
cricket::SctpTransport::SctpTransport // определяет, когда транспорт SCTP готов
calculate_crc32c // вычисляет контрольную сумму для SCTP-пакетов
sctp_hmac // выполняет HMAC для угадывания секретного ключа
sctp_hmac_m // подписывает SCTP-пакет
SrtpTransport::ProtectRtp // подавляет RTP для уменьшения шума кучи
Эти функции можно перехватывать как символы или как смещения в бинарном файле.
Также для работы эксплойта необходимы три смещения адресов из бинарного файла целевого устройства. Смещение между функцией system и функцией malloc, а также смещение между гаджетом, описанным в предыдущей статье, и функцией malloc — два из них. Эти смещения находятся в libc, системной библиотеке Android, поэтому их необходимо определять на основе версии Android целевого устройства. Также требуется смещение от расположения vtable cricket::SctpTransport до расположения malloc в глобальной таблице смещений (GOT). Это необходимо определить из бинарного файла, содержащего WebRTC в атакуемом приложении.
Обратите внимание, что предоставленные скрипты эксплойта имеют серьёзное ограничение: при каждом чтении памяти это работает только в том случае, если установлен 31-й бит указателя. Причины этого объясняются в Части 2. Скрипт эксплойта содержит пример того, как это исправить и прочитать любой указатель с помощью фрагментов FWD_TSN, но это реализовано не для каждого чтения. Для целей тестирования я перезагружал устройство до тех пор, пока библиотека WebRTC не отображалась в благоприятном месте. Приложения Android Список популярных приложений Android, интегрирующих WebRTC, был определён путём поиска в APK-файлах на Google Play конкретной строки в usrsctp. Примерно 200 приложений с более чем пятью миллионами пользователей, по-видимому, используют WebRTC. Я оценил эти приложения, чтобы определить, могут ли они потенциально быть затронуты уязвимостями в эксплойте, и каким будет воздействие.
Оказалось, что способы использования WebRTC приложениями весьма разнообразны, но их можно разделить на четыре основные категории.
Воздействие уязвимостей, используемых в эксплойте, различно для каждой из этих категорий. Проецирование является низким риском, так как для установки WebRTC-соединения требуется много взаимодействия с пользователем, и пользователь изначально имеет доступ к обеим сторонам соединения, поэтому мало что можно получить от компрометации другой стороны.
Стриминг также является довольно низким риском. Хотя возможно, что некоторые приложения используют одноранговые соединения, когда у потока мало зрителей, они обычно используют промежуточный сервер, который завершает WebRTC-соединение от отправляющего пира и устанавливает новые соединения с принимающими пирами. Это означает, что злоумышленник обычно не может отправлять повреждённые пакеты напрямую пиру. Даже при настройке, где стриминг выполняется по принципу «пир-пиру», для просмотра потока целью требуется взаимодействие с пользователем, и часто нет способа ограничить, кто может получить доступ к потоку. По этой причине стриминговые приложения, использующие WebRTC, вероятно, бесполезны для целевых атак. Конечно, возможно, что эти уязвимости затрагивают серверы, используемые стриминговыми сервисами, но это не исследовалось в данной работе.
Браузеры почти наверняка уязвимы к большинству ошибок в WebRTC, поскольку они позволяют в значительной степени контролировать его настройку. Чтобы использовать такую ошибку в браузере, злоумышленнику необходимо настроить хост, который выступает в роли другого пира в одноранговом соединении, и убедить цель посетить веб-страницу, которая начинает вызов этому хосту. В этом случае уязвимость будет иметь аналогичное воздействие, как и другие уязвимости повреждения памяти в JavaScript.
Конференции — это наиболее рискованное использование WebRTC, но фактическое воздействие уязвимости сильно зависит от того, как пользователи приложения связываются друг с другом. Наиболее рискованным дизайном является приложение, в котором любой пользователь может связаться с любым другим пользователем на основе идентификатора. Некоторые приложения требуют, чтобы вызываемый абонент определённым образом взаимодействовал с вызывающим до того, как может быть совершён вызов, что усложняет связь с целью и в целом снижает риск. Некоторые приложения требуют, чтобы пользователи ввели код или перешли по ссылке, чтобы начать вызов, что даёт аналогичный эффект. Существует также большая группа приложений, в которых сложно или невозможно позвонить конкретному пользователю, например приложения «чат-рулетка» и приложения, имеющие функции, позволяющие пользователю начать вызов в службу поддержки клиентов.
В рамках этого исследования я сосредоточился на приложениях для конференций, которые позволяют пользователям связываться с конкретными другими пользователями. Это сократило мой список из 200 приложений до 14 приложений, как показано ниже.
