Приветствую всех, кто решил прочитать мою новую статью с разбором уязвимостей. В прошлый раз небольшим циклом из трех статей я рассказал об уязвимостях в 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 AUTHORITY\SYSTEM (учетная запись, обладающая максимальными правами в ОС). Первая уязвимость довольно скучная, поэтому в следующем разделе я вкратце опишу ее. А вот вторая была довольно интересной, в ее разделе я расскажу именно о том, как я ее искал.

CVE-2019-19248

Данная уязвимость состоит из двух частей:

1. Создание папки по произвольному пути (с правами «Все-Полный доступ»);
2. Использование пункта 1 для получения прав NT AUTHORITY\SYSTEM.

Теперь о первом пункте подробнее:

Подготовка окружения

Необходимо закрыть клиент Origin и остановить сервис «Origin Client Service» (по идее, сервис сам остановится если закрыть клиент, но на всякий случай).

Для папки «C:\ProgramData\Origin» действуют права «Все-Полный доступ», что позволяет нам полностью удалить ее содержимое.

Создание ссылок

Теперь создадим пару ссылок. Первая ссылка будет типа NTFS Reparse Point (NTFS Mount Point) — вид ссылок, указывающих с папки на папку: «C:\ProgramData\Origin» <-> «\RPC Control». Для создания репарс-поинтов не нужны права администратора. Необходимо только, чтобы папка-источник была пуста, и пользователь имел права на запись в нее (очистили в прошлом шаге, там же проверили права). «\RPC Control» — это не папка в файловой системе, а особый вид папки — объектная директория. Ее нельзя посмотреть обычным эксплорером, но зато туда можно сделать репарс-поинт, видимо, из-за общих абстракций, используемых в недрах Windows.

Теперь мы создадим обычную символьную ссылку «\RPC Control\CatalogCache» <-> «C:\Путь\К\Целевой\Папке». В файловой системе создание символических ссылок без прав администратора запрещено, но это правило не распространяется на объектные директории. Поэтому наша ссылка успешно будет создана. В результате комбинации этих двух ссылок обращения к «C:\ProgramData\Origin\CatalogCache» будут перенаправлены на «C:\Путь\К\Целевой\Папке».

Почитать подробнее про такие ссылки можно тут. В этом же репозитории можно скачать утилиты для работы с ссылками.

Запуск

На последнем шаге запускаем клиент. Он в начале своей работы запустит «Origin Client Service» и, обнаружив, что папки «C:\ProgramData\Origin\CatalogCache» нет, попробует создать ее. В результате перехода по симлинкам создаст «C:\Путь\К\Целевой\Папке» и выдаст этой папке права «Все-Полный доступ».

Что и требовалось получить в первом пункте эксплуатации. Перейдем ко второму.

Эксплуатация создания папки по произвольному пути

Здесь можно работать уже большим количеством способов.

Простой и довольно надежный — создать папку «C:\Windows\system32\LogonUI.exe.local». «LogonUI.exe» (приложение работающие от NT AUTHORITY\SYSTEM, отвечает за работу экрана выбора пользователей и экрана блокировки) благодаря механизму «.local-redirection» («dotlocal redirection») будет загружать из нее библиотеку по пути «C:\Windows\system32\LogonUI.exe.local \amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17134.648_none_fb45a0e93062a6d2\comctl32.dll». Вообще сам механизм довольно распространенный, так что целей у него может быть много.

Длинный, но интересный путь — через особые махинации вычитать хэш пароля администратора. Подробнее тут.

Итого

Уязвимость эксплуатируется довольно легко, нужно только немного поработать над вторым пунктом — найти цель и написать подходящую dll. Кроме того, о данной уязвимости сообщил и Мэтт Нельсон, его райтап можно прочитать тут.

CVE-2019-19247

Это одна из моих самых любимых уязвимостей. Она показывает, насколько аккуратно надо относиться к используемой криптографии.

Все началось с того, что я установил игру через Origin. Все прошло как-то слишком гладко — пару кликов и через несколько минут скачивания игру можно запускать. Не сразу, но я понял в чем было дело: игра установилась по пути «C:\Program Files\GameName», но не задала ни единого вопроса через UAC. Я быстро проверил права, все было стандартно — обычный пользователь не мог писать в «C:\Program Files». Еще немного исследований и я узнал, что игру «прописывает» не сам клиент Origin, а его сервис «Origin Client Service».

Я начал строить предположения о том, как клиент передает информацию в сервис, чтобы проверить, а нельзя ли что-то поэксплуатировать.

Способ передачи информации оказался простым — именованный пайп. Об этом я узнал из логов при установке — открытым текстом указывалось, что пайп «OriginClientService» принимал команды на работу с файлами и папками.

Открыл IDA, загрузил туда клиент.

*работ проведено в IDA: 1*

Довольно быстро я нашел, что в пайп команды отправляют в общем-то в текстовом виде. Рядом нашел список команд и, не мудрствуя лукаво, отправил в пайп команду вида «copy “C:\test\payload.dll” “C:\Windows\pwn.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:\test\payload.exe”». Ну вы поняли… Ничего.

Логи снова говорят про подпись. Ох, мы же это уже победили. Указываем в коде, что вызвали наш скопированный Origin.exe, чтобы снова загрузилась наша прокси-dll, но уже с правами системы. Добавляем проверки и запуск консоли. Запускаем и появляется консоль с правами NT AUTHORITY\SYSTEM — наконец-то все заработало.

*работ проведено в 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: согласованное раскрытие информации.

Всем спасибо за внимание, желаю вам таких же агентов по безопасности.

This article in english.