Хабрахабр

Steam Windows Client Local Privilege Escalation 0day

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

Итак, герой нашей истории — ПО Steam от компании Valve. И уязвимость повышения привилегий в нем, которая позволяет любому пользователю выполнить команды от имени NT AUTHORITY\SYSTEM.

Уязвимость

Сама уязвимость довольно простая. Steam для своей работы устанавливает сервис “Steam Client Service”. Глянем на SDDL-описатель сервиса:

O:SYG:SYD:(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;RPWP;;;BU)

В данном случае, эта запись означает, что запускать и останавливать сервис может любой пользователь из группы «Пользователи».
Посмотрим, что сервис делает при старте. Здесь нас интересует часть (A;;RPWP;;;BU). Не особо много интересного, но есть часть операций, которые выглядят необычно — сервис перечисляет содержимое раздела HKLM\SOFTWARE\Wow6432Node\Valve\Steam\Apps и для всех подразделов выставляет какие-то права.

Создаем тестовый ключ, запускаем сервис (лог procmon’а выше) и смотрим, что с правами. Интересно, что же за права выставляются? Рождается гипотеза, что такие же права будут выставляться и всем подразделам HKLM\SOFTWARE\Wow6432Node\Valve\Steam\Apps через вызов RegSetKeySecurity. Тут и обнаруживается, что еще у раздела HKLM\SOFTWARE\Wow6432Node\Valve\Steam выставлены права на полный доступ для всех пользователей, которые наследуются на все подключи. А что если в реестре будет стоять симлинк, и ветка HKLM\SOFTWARE\Wow6432Node\Valve\Steam\Apps\test будет указывать, например на HKLM\SOFTWARE\test2?

Проверяем и видим, что права в случае симлинка прописываются для целевой ветки реестра.

Проверяем права у целевой ветки и видим в SDDL-форме (пропуская неинтересное):

(A;ID;KA;;;BU)(A;OICIIOID;GA;;;BU)

Именно такие права прописал ветке сервис Steam. В словесной форме это означает, что полный (чтение и запись) доступ для всех пользователей.

Я выбрал ветку HKLM\SYSTEM\ControlSet001\Services\msiserver — она соответствует сервису «Установщик Windows», который тоже может быть запущен пользователем, но работать сервис будет с правами NT AUTHORITY\SYSTEM. Теперь, когда подготовлен примитив по получению контроля над практически любой веткой реестра, докрутить PoC уже легко. Наш исполняемый файл запускается с максимально возможными правами — NT AUTHORITY\SYSTEM. После получения контроля над веткой HKLM\SYSTEM\ControlSet001\Services\msiserver мы меняем путь к исполняемому файлу в ключе ImagePath и запускаем сервис msiserver.

Собираем все, что написано выше в код и получаем простое повышение привилегий на любом компьютере с Windows, где установлен Steam.

Сообщение об уязвимости

Я отправил отчет об уязвимости в Valve через Hackerone.

Мне не жалко — у меня PoC, который вызывает консоль от имени NT AUTHORITY\SYSTEM — доказательства на лицо. Тут меня ждала первая неожиданность — прежде чем передавать уязвимость непосредственно в Valve, мне нужно было сначала убедить hackerone staff в том, что у меня действительно отчет об уязвимости, так как Valve используют функцию «Managed by HackerOne». Причиной указывается, что мой отчет вне скоупа исследований, поскольку «Attacks that require the ability to drop files in arbitrary locations on the user's filesystem.» (атака требует возможности располагать файлы в произвольных путях файловой системы). И я получаю отказ в отчете. Моя реакция: «У меня даже нет ни одной операции с файловой системой, но отказ по такой причине, серьезно?»

Подтверждает ее и передает Valve. Пишу комментарий об этом и приходит другой сотрудник, который все же берется проверять уязвимость. Или нет…? Ура, цель достигнута.

Причины: «Attacks that require the ability to drop files in arbitrary locations on the user's filesystem» и «Attacks that require physical access to the user’s device» (атака требует физический доступ к устройству пользователя). Проходит время и отчет снова помечается как неприменимый. Тут я понял, что атаки на повышение привилегий попросту не интересны Valve.

Небольшой комментарий по поводу причин

Изначально я считал, что из скоупа исключают отчеты, которые не содержат уязвимости как таковой, но демонстрируют какое-то странное применение установленного ПО.

Мне казалось, что такой причиной Valve хотели исключить спекуляции на тему «давайте я установлю игру в папку, доступную всем пользователям, затем буду запускать ее с правами админа, не проверяя не подменил ли кто файлы», но для них это, видимо, повод исключить вообще все что касается локальных атак. Например, в причине «Attacks that require the ability to drop files in arbitrary locations on the user's filesystem» я выделил ключевые, на мой взгляд, слова.

Для меня, физический доступ — это возможность отверткой открутить болты жесткого диска, загрузиться с внешнего носителя и другие интересные вещи непосредственно с оборудованием ПК. Тоже самое и с физическим доступом. Равно как и преодолеть двухфакторную аутентификацию при физическом доступе к телефону. Довольно логично предположить, что имея такой доступ можно сделать почти все, что угодно. Так и RCE запретить недолго: компьютер же соединен с серверами волнами или проводами — физически!
Valve же, видимо, любое действие на компьютере пользователя рассматривает как физику.

Поскольку прошло 45 дней с момента отчета, я решил публично раскрыть детали уязвимости, хотя я не уверен, что это сподвигнет разработчиков Steam внести изменения.

1 x64 и Windows 10 x64. Небольшие статистические данные: уязвимость была проверена на Windows 8 x64, Windows 8. Я не знаю особенностей нумерации версий ПО Steam, поэтому зафиксирую версии компонентов сервиса:

  • SteamService.dll (5.16.86.11, подписан Valve 14.06.2019)
  • SteamService.exe (5.16.86.11, подписан Valve 14.06.2019)

Таймлайн:

15 июня — отправлен отчет об уязвимости.
16 июня — отклонен, «Attacks that require the ability to drop files in arbitrary locations on the user's filesystem.».
16 июня — переоткрыт с комментарием.
2 июля — подтвержден сотрудником HackerOne, передан Valve.
20 июля — отклонен, «Attacks that require the ability to drop files in arbitrary locations on the user's filesystem.», «Attacks that require physical access to the user’s device.».
7 августа — опубликована эта статья.

Немного спекуляций

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

Вы уверены, что бесплатная игра, сделанная на коленке неизвестным разработчиком, будет вести себя честно? Довольно иронично обнаружить, что лаунчер, который фактически предназначен для того, чтобы запускать сторонние программы на вашем компьютере, позволяет им втихую получить максимальные привилегии. Конечно, часть угроз останется и при работе без прав администратора, но высокие права у вредоносных программ могут существенно попортить нервов – отключение антивируса, закрепление в системные автозагрузки, изменение практически любых файлов, любых пользователей. Верите, что за скидку в 90% вы не получите скрытый майнер?

В 2015 году количество активных учётных записей Steam оценивалось как 125 миллионов. Благодаря популярности Steam, количество потенциальных пострадавших очень велико. Но масштабы проблемы все же впечатляют.
А может все это оставлено специально? Да, не у всех пользователей Steam ОС Windows, но у большинства точно, и у каких-то пользователей по нескольку «живых» аккаунтов на одной машине. Точно установить это невозможно, но давайте сопоставим факты: Может, Steam — это своего рода легальный бекдор?

  1. Есть уязвимость, которую легко эксплуатировать (причем, судя по сообщениям в твиттере, не одна).
  2. Ее довольно легко обнаружить — я не уверен, что я первый нашел ее, но как минимум первый описал публично.
  3. Нежелание принимать отчет о такой уязвимости и похожих (скоуп специально выбран так, что повышение привилегий из него выпадает).

Все это мне очень не нравится. Я не буду призывать вас удалять Steam, но предлагаю быть очень внимательным с тем, что он делает. На кону ваша безопасность.

Бонус

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

20 июля — после отклонения отчета, я предупредил h1, что публично раскрою детали уязвимости после 30 июля.
2 августа — еще один сотрудник h1 отмечается в закрытом отчете и говорит, что они не разрешают мне проводить раскрытие.

И вот, спустя две недели от моего сообщения 20 июля, появляется человек, который говорит мне: «мы не даем разрешение на раскрытие уязвимости». Данная статья была подготовлена к публикации уже к 30 июля (такая дата была выбрана из расчета 45 дней после отправки отчета), но задержалась. При этом не единого слова от Valve. Фактически, получается: мы отметили твой отчет, как неподходящий, мы закрыли обсуждение, мы не посчитали нужным ничего тебе объяснять и мы просто не хотим, чтобы ты публиковался. Вы не стали уважать мою работу, я не буду уважать вашу — не вижу причин не публиковать этот отчет для всех. Нет, ребята, так дело не пойдет. Скорее всего меня забанят на h1 из-за этого, но я огорчаться не стану.

This article in english.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть