Приветствую всех, кто решил прочитать мою новую статью с разбором уязвимостей. В прошлый раз небольшим циклом из трех статей я рассказал об уязвимостях в Steam (1, 2 и 3). В данной статье я расскажу об уязвимостях похожего продукта — Origin, который тоже является лаунчером для игр. Обнаруженные уязвимости получили номера CVE-2019-19247 и CVE-2019-19248.
В этот раз не будет никакой дичи с банами-анбанами. История общения с security подразделением компании Electronic Arts Inc изначально шла на профессиональном уровне. При обращении мне выдали регистрационный номер, отчеты тщательно изучили и подтвердили. Ни один мой имейл не был проигнорирован, а для небольшого обсуждения был организован конфколл. Сопровождение этих отчетов было для меня очень простым, за что большое спасибо Adrian Stone, Elise Murphy и другим сотрудникам EA, работавшим с моими отчетами. Запись в security-блоге и advisory.
Теперь к уязвимостям. Я нашел две уязвимости типа «повышение привилегий» (lpe — local privilege escalation или eop — escalation of privileges) в Windows клиенте Origin. Такой тип уязвимостей позволяет любому пользователю ОС Windows получить больше прав, чем изначально выдано администратором. В данном случае речь идет о двух «типовых» повышениях — от любого пользователя до NT AUTHORITYSYSTEM (учетная запись, обладающая максимальными правами в ОС). Первая уязвимость довольно скучная, поэтому в следующем разделе я вкратце опишу ее. А вот вторая была довольно интересной, в ее разделе я расскажу именно о том, как я ее искал.
CVE-2019-19248
Данная уязвимость состоит из двух частей:
- Создание папки по произвольному пути (с правами «Все-Полный доступ»);
- Использование пункта 1 для получения прав NT AUTHORITYSYSTEM.
Теперь о первом пункте подробнее:
Подготовка окружения
Необходимо закрыть клиент Origin и остановить сервис «Origin Client Service» (по идее, сервис сам остановится если закрыть клиент, но на всякий случай).
Для папки «C:ProgramDataOrigin» действуют права «Все-Полный доступ», что позволяет нам полностью удалить ее содержимое.
Создание ссылок
Теперь создадим пару ссылок. Первая ссылка будет типа NTFS Reparse Point (NTFS Mount Point) — вид ссылок, указывающих с папки на папку: «C:ProgramDataOrigin» <-> «RPC Control». Для создания репарс-поинтов не нужны права администратора. Необходимо только, чтобы папка-источник была пуста, и пользователь имел права на запись в нее (очистили в прошлом шаге, там же проверили права). «RPC Control» — это не папка в файловой системе, а особый вид папки — объектная директория. Ее нельзя посмотреть обычным эксплорером, но зато туда можно сделать репарс-поинт, видимо, из-за общих абстракций, используемых в недрах Windows.
Теперь мы создадим обычную символьную ссылку «RPC ControlCatalogCache» <-> «C:ПутьКЦелевойПапке». В файловой системе создание символических ссылок без прав администратора запрещено, но это правило не распространяется на объектные директории. Поэтому наша ссылка успешно будет создана. В результате комбинации этих двух ссылок обращения к «C:ProgramDataOriginCatalogCache» будут перенаправлены на «C:ПутьКЦелевойПапке».
Почитать подробнее про такие ссылки можно тут. В этом же репозитории можно скачать утилиты для работы с ссылками.
Запуск
На последнем шаге запускаем клиент. Он в начале своей работы запустит «Origin Client Service» и, обнаружив, что папки «C:ProgramDataOriginCatalogCache» нет, попробует создать ее. В результате перехода по симлинкам создаст «C:ПутьКЦелевойПапке» и выдаст этой папке права «Все-Полный доступ».
Что и требовалось получить в первом пункте эксплуатации. Перейдем ко второму.
Эксплуатация создания папки по произвольному пути
Здесь можно работать уже большим количеством способов.
Простой и довольно надежный — создать папку «C:Windowssystem32LogonUI.exe.local». «LogonUI.exe» (приложение работающие от NT AUTHORITYSYSTEM, отвечает за работу экрана выбора пользователей и экрана блокировки) благодаря механизму «.local-redirection» («dotlocal redirection») будет загружать из нее библиотеку по пути «C:Windowssystem32LogonUI.exe.local amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17134.648_none_fb45a0e93062a6d2comctl32.dll». Вообще сам механизм довольно распространенный, так что целей у него может быть много.
Длинный, но интересный путь — через особые махинации вычитать хэш пароля администратора. Подробнее тут.
Итого
Уязвимость эксплуатируется довольно легко, нужно только немного поработать над вторым пунктом — найти цель и написать подходящую dll. Кроме того, о данной уязвимости сообщил и Мэтт Нельсон, его райтап можно прочитать тут.
CVE-2019-19247
Это одна из моих самых любимых уязвимостей. Она показывает, насколько аккуратно надо относиться к используемой криптографии.
Все началось с того, что я установил игру через Origin. Все прошло как-то слишком гладко — пару кликов и через несколько минут скачивания игру можно запускать. Не сразу, но я понял в чем было дело: игра установилась по пути «C:Program FilesGameName», но не задала ни единого вопроса через UAC. Я быстро проверил права, все было стандартно — обычный пользователь не мог писать в «C:Program Files». Еще немного исследований и я узнал, что игру «прописывает» не сам клиент Origin, а его сервис «Origin Client Service».
Я начал строить предположения о том, как клиент передает информацию в сервис, чтобы проверить, а нельзя ли что-то поэксплуатировать.
Способ передачи информации оказался простым — именованный пайп. Об этом я узнал из логов при установке — открытым текстом указывалось, что пайп «OriginClientService» принимал команды на работу с файлами и папками.
Открыл IDA, загрузил туда клиент.
*работ проведено в IDA: 1*
Довольно быстро я нашел, что в пайп команды отправляют в общем-то в текстовом виде. Рядом нашел список команд и, не мудрствуя лукаво, отправил в пайп команду вида «copy “C:testpayload.dll” “C:Windowspwn.dll”». В ожидании быстрого результата проверяю папку «C:Windows» и ничего нового в ней не нахожу. Зато новое есть в логах — какие-то слова про то, что клиент у пайпа не прошел проверку цифровой подписи.
Открыл IDA, загрузил туда сервис.
*работ проведено в IDA: 2*
Выяснил, что команд от абы кого не ждут. При подключении к пайпу сервис проверяет, кто же такой к нему подключился. Из соединения извлекается pid процесса, из pid'а извлекается путь к исполняемому файлу, у файла проверяется подпись на корректность и то, что она выдана EA.
Звучит проверка здраво, но недостаточно. Можно взять легальный «Origin.exe» (исполняемый файл клиента), скопировать его куда-то в свою папку. В этой папке разместить какую-нибудь dll из списка импорта «Origin.exe». Например, подошла version.dll. Я назвал этот подход «обратная dll-инъекция»: в обычной dll-инъекции мы копируем dll к exe-файлу, а сейчас поступили наоборот. Быстро пишу прокси-dll для version.dll, добавляю код с отправкой команды в пайп. Полезная нагрузка все равно не скопировалась. Читаем логи — «что значит, не удалось расшифровать команду!?». Пропустил я шифрование.
Открыл IDA, загрузил туда клиент.
*работ проведено в IDA: 3, обход подписи: 1*
Раз клиент в обычной своей работе отправляет зашифрованные команды, значит и я смогу. Там посмотрел, тут посмотрел, результат такой: шифрование AES, инициализирующий вектор постоянный, ключ читается из файла. Практически копируем этот кусок и IDA в код, компилируем, проверяем. И снова ничего. Но логи снова дают полезную информацию — нельзя в качестве целевого пути указывать не Program Files.
Открыл IDA, загрузил туда сервис.
*работ проведено в IDA: 4, обход подписи: 1, обход шифрования: 1*
Так, и правда, на получение команды стоят проверки, что, оказывается, не всюду можно файлы копировать. И пути с «..» нельзя писать. Смотрим, какие еще команды есть.
Работа с реестром — там снова куча ограничений. А вот запуск файлов выглядит интересно. По крайней мере проверок особо не видно. Правим код, отправляем команду «ExecuteProcess “C:testpayload.exe”». Ну вы поняли… Ничего.
Логи снова говорят про подпись. Ох, мы же это уже победили. Указываем в коде, что вызвали наш скопированный Origin.exe, чтобы снова загрузилась наша прокси-dll, но уже с правами системы. Добавляем проверки и запуск консоли. Запускаем и появляется консоль с правами NT AUTHORITYSYSTEM — наконец-то все заработало.
*работ проведено в IDA: 4, обход подписи: 2, обход шифрования: 1*
Так, надо перезагрузить, провести финальный прогон и еще полюбоваться на консоль с максимальными правами. Перезагрузка, проверка и… ничего. Как так-то? Только что же работало.
Диагностика показывает, что сервис «Origin Client Service» не был запущен, поэтому я его запускаю. А он не запускается. Точнее запускается, но тут же завершает работу. Запускаю клиент Origin и сервис нормально запускается. После этого эксплоит снова корректно отрабатывает. Можно было бы на этом остановится, но это не мой путь — я хочу заставить эксплоит отрабатывать полноценно.
Открыл IDA, загрузил туда сервис.
*работ проведено в IDA: 5, обход подписи: 2, обход шифрования: 1*
Оказывается, при старте он проверяет то, с какими параметрами стартовали сервис. Там оказывается ничего прям интересного. Base64 от зашифрованного pid процесса, у файла которого проверяется подпись. Вроде звучит сложно, но шифрование мы уже обошли, подпись тоже. Пишем немного кода и полноценный эксплоит готов.
Итого
Эксплоит работает. Работ проведено в IDA: 5 раз, обход подписи: 3 раза, обход шифрования: 2 раза.
Вывод
Уязвимости поправлены: разработчики из EA ввели специальный restricted-режим работы для клиента, в котором устанавливаются серьезные ограничения на работу с папками и пайпами Origin.
Таймлайн уязвимостей:
1 апреля 2019: передача отчета об уязвимости с пайпом;
7 апреля 2019: передача отчета об уязвимости с произвольной папкой;
… ОЧЕНЬ МНОГО ПИСЕМ (я насчитал 40)…
10 декабря 2019: согласованное раскрытие информации.
Всем спасибо за внимание, желаю вам таких же агентов по безопасности.
Автор: Кравец Василий
