Приветствую всех, кто решил прочитать мою новую статью с анализом уязвимостей.
В прошлый раз в небольшой серии из трех статей я рассказывал об уязвимостях в Steam( 1 , 2 И 3 ).
В этой статье я расскажу об уязвимостях аналогичного продукта — Origin, который также является лаунчером для игр.
Обнаруженные уязвимости получили обозначения CVE-2019-19247 и CVE-2019-19248. 
В этот раз игры с банами-анбанами не будет. История общения с подразделением безопасности Electronic Arts Inc. изначально была на профессиональном уровне.
При подаче заявления мне дали регистрационный номер, отчеты были тщательно изучены и подтверждены.
Ни одно мое письмо не было проигнорировано, и для небольшого обсуждения была организована телеконференция.
Мне было очень легко поддерживать эти отчеты, за что большое спасибо Адриану Стоуну, Элиз Мерфи и другим сотрудникам EA, работавшим над моими отчетами.
Сообщение в блоге о безопасности И консультативный .
Теперь об уязвимостях.
Я обнаружил две уязвимости «повышения привилегий» (lpe — local Privilege escalation или eop — эскалация привилегий) в клиенте Origin Windows. Этот тип уязвимости позволяет любому пользователю ОС Windows получить больше прав, чем было изначально предоставлено администратором.
В данном случае речь идет о двух «стандартных» повышениях — от любого пользователя до NT AUTHORITY\SYSTEM (учетная запись с максимальными правами в ОС).
Первая уязвимость довольно скучная, поэтому я кратко опишу ее в следующем разделе.
А вот второй оказался довольно интересным, в его разделе я расскажу, как именно я его искал.
CVE-2019-19248
Эта уязвимость состоит из двух частей:- Создание папки по произвольному пути (с правами «Всем-Полный доступ»);
- Используем пункт 1 для получения прав NT AUTHORITY\SYSTEM.
Подготовка окружающей среды
Вам необходимо закрыть клиент Origin и остановить службу «Origin Client Service» (по идее, служба сама остановится, если вы закроете клиент, но на всякий случай).Папка «C:\ProgramData\Origin» имеет права «Всем-Полный доступ», что позволяет нам полностью удалить ее содержимое.
Создание ссылки
Теперь давайте создадим пару ссылок.Первая ссылка будет типа NTFS Reparse Point (Точка монтирования NTFS) — тип ссылки, указывающей из папки в папку: «C:\ProgramData\Origin».
<-> «\RPC Control».
Вам не нужны права администратора для создания точек повторной обработки.
Необходимо только, чтобы исходная папка была пустой и у пользователя были права на запись в нее (очистил на предыдущем шаге и проверил там права).
«\RPC Control» — это не папка в файловой системе, а особый вид папки — каталог объектов.
Его нельзя просмотреть обычным проводником, но можно сделать там точку повторной обработки, видимо, из-за общих абстракций, используемых в недрах Windows. Теперь создадим обычную символическую ссылку «\RPC Control\CatalogCache».
<-> «C:\Путь\К\Цель\Папка».
В файловой системе создание символических ссылок без прав администратора запрещено, но это правило не распространяется на каталоги объектов.
Следовательно, наша ссылка будет успешно создана.
В результате объединения этих двух ссылок вызовы «C:\ProgramData\Origin\CatalogCache» будут перенаправлены на «C:\Path\To\Target\Folder».
Подробнее о таких ссылках можно прочитать здесь .
В том же репозитории можно скачать утилиты для работы со ссылками.
Запуск
На последнем этапе запускаем клиент. В начале своей работы он запустит «Origin Client Service» и, обнаружив, что папка «C:\ProgramData\Origin\CatalogCache» не существует, попытается ее создать.В результате навигации по символическим ссылкам он создаст «C:\Path\To\Target\Folder» и предоставит этой папке права «Все-Полный доступ».
Это то, что и требовалось получить на первой точке эксплуатации.
Перейдем ко второму.
Ээксплуатация создания папки по произвольному пути
Здесь можно работать разными способами.Просто и достаточно надежно – создайте папку «C:\Windows\system32\LogonUI.exe.local».
«LogonUI.exe» (приложение, запускаемое из NT AUTHORITY\SYSTEM, отвечающее за работу экрана выбора пользователя и экрана блокировки) благодаря механизму «.
local-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».
Я начал делать предположения о том, как клиент передает информацию сервису, чтобы проверить, можно ли что-то использовать.
Способ передачи информации оказался простым — именованный канал.
Об этом я узнал из логов при установке — открытым текстом было указано, что канал «OriginClientService» принимает команды для работы с файлами и папками.
Я открыл IDA и загрузил туда клиент. *работы проведены в МАР: 1* Довольно быстро я обнаружил, что команды передаются в пайп в текстовом виде.
Рядом я нашел список команд и, не мудрствуя лукаво, отправил в трубу команду типа «copy «C:\test\payload.dll» «C:\Windows\pwn.dll».
Ожидая быстрого результата, я проверяю папку «C:\Windows» и не нахожу в ней ничего нового.
Но в логах есть кое-что новое - несколько слов о том, что клиент на трубе не прошел проверку ЭЦП.
Я открыл IDA и загрузил туда сервис.
*работы проведены в МАР: 2* Я узнал, что команд ни от кого не ждут. При подключении к трубе сервис проверяет, кто к ней подключался.
Из соединения извлекается pid процесса, из pid извлекается путь к исполняемому файлу, проверяется подпись файла на предмет ее корректности и выдачи EA. Тест звучит убедительно, но недостаточно.
Вы можете взять легальный «Origin.exe» (исполняемый файл клиента), скопировать его куда-нибудь в свою папку.
В эту папку поместите какую-нибудь dll из списка импорта «Origin.exe».
Например, подошла версия.
dll. Я назвал этот подход «обратной инъекцией DLL»: при обычной инъекции DLL мы копируем DLL в exe-файл, но сейчас мы сделали наоборот. Быстро пишу прокси-длл для 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 ввели для клиента специальный ограниченный режим работы, который устанавливает серьезные ограничения на работу с папками и трубами Origin. Хронология уязвимостей: 1 апреля 2019 г.: передача отчета об уязвимости по каналу; 7 апреля 2019 г.
: отправить отчет об уязвимости из случайной папки; … МНОГО БУКВ (я насчитал 40)… 10 декабря 2019 г.
: Постоянное раскрытие информации.
Всем спасибо за внимание, желаю вам того же силовикам.
Эта статья на английском языке.
Теги: #информационная безопасность #уязвимость #Windows #Аномальное программирование #эскалация привилегий #origin #eop #lpe
-
Лукас, Роберт
19 Oct, 24 -
Открытый Вебинар «Примеры Паттернов»
19 Oct, 24
