Я не первый год занимаюсь поиском уязвимостей, и, казалось бы, многое видел, но есть такая часть работы, к которой не удается привыкнуть и которую не могу понять. Это абсолютное нежелание вендоров принимать информацию об уязвимостях и проблемах. Я понимаю, что очень неприятно, когда тебе прямо показывают, что ты допустил ошибку и, скорее всего, не одну. Неприятно подтверждать в открытых источниках публично, что проблемы были, что сотрудники что-то недоработали. Но я не понимаю почему информацию об уязвимости нужно отвергать.
Итак, герой нашей истории — ПО Steam от компании Valve. И уязвимость повышения привилегий в нем, которая позволяет любому пользователю выполнить команды от имени NT AUTHORITYSYSTEM.
Уязвимость
Сама уязвимость довольно простая. 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). В данном случае, эта запись означает, что запускать и останавливать сервис может любой пользователь из группы «Пользователи».
Посмотрим, что сервис делает при старте. Не особо много интересного, но есть часть операций, которые выглядят необычно — сервис перечисляет содержимое раздела HKLMSOFTWAREWow6432NodeValveSteamApps и для всех подразделов выставляет какие-то права.
Интересно, что же за права выставляются? Создаем тестовый ключ, запускаем сервис (лог procmon’а выше) и смотрим, что с правами. Тут и обнаруживается, что еще у раздела HKLMSOFTWAREWow6432NodeValveSteam выставлены права на полный доступ для всех пользователей, которые наследуются на все подключи. Рождается гипотеза, что такие же права будут выставляться и всем подразделам HKLMSOFTWAREWow6432NodeValveSteamApps через вызов RegSetKeySecurity. А что если в реестре будет стоять симлинк, и ветка HKLMSOFTWAREWow6432NodeValveSteamAppstest будет указывать, например на HKLMSOFTWAREtest2?
Проверяем и видим, что права в случае симлинка прописываются для целевой ветки реестра.
Проверяем права у целевой ветки и видим в SDDL-форме (пропуская неинтересное):
(A;ID;KA;;;BU)(A;OICIIOID;GA;;;BU)
В словесной форме это означает, что полный (чтение и запись) доступ для всех пользователей. Именно такие права прописал ветке сервис Steam.
Теперь, когда подготовлен примитив по получению контроля над практически любой веткой реестра, докрутить PoC уже легко. Я выбрал ветку HKLMSYSTEMControlSet001Servicesmsiserver — она соответствует сервису «Установщик Windows», который тоже может быть запущен пользователем, но работать сервис будет с правами NT AUTHORITYSYSTEM. После получения контроля над веткой HKLMSYSTEMControlSet001Servicesmsiserver мы меняем путь к исполняемому файлу в ключе ImagePath и запускаем сервис msiserver. Наш исполняемый файл запускается с максимально возможными правами — NT AUTHORITYSYSTEM.
Собираем все, что написано выше в код и получаем простое повышение привилегий на любом компьютере с Windows, где установлен Steam.
Сообщение об уязвимости
Я отправил отчет об уязвимости в Valve через Hackerone.
Тут меня ждала первая неожиданность — прежде чем передавать уязвимость непосредственно в Valve, мне нужно было сначала убедить hackerone staff в том, что у меня действительно отчет об уязвимости, так как Valve используют функцию «Managed by HackerOne». Мне не жалко — у меня PoC, который вызывает консоль от имени NT AUTHORITYSYSTEM — доказательства на лицо. И я получаю отказ в отчете. Причиной указывается, что мой отчет вне скоупа исследований, поскольку «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.
Например, в причине «Attacks that require the ability to drop files in arbitrary locations on the user's filesystem» я выделил ключевые, на мой взгляд, слова. Мне казалось, что такой причиной Valve хотели исключить спекуляции на тему «давайте я установлю игру в папку, доступную всем пользователям, затем буду запускать ее с правами админа, не проверяя не подменил ли кто файлы», но для них это, видимо, повод исключить вообще все что касается локальных атак.
Тоже самое и с физическим доступом. Для меня, физический доступ — это возможность отверткой открутить болты жесткого диска, загрузиться с внешнего носителя и другие интересные вещи непосредственно с оборудованием ПК. Довольно логично предположить, что имея такой доступ можно сделать почти все, что угодно. Равно как и преодолеть двухфакторную аутентификацию при физическом доступе к телефону. Valve же, видимо, любое действие на компьютере пользователя рассматривает как физику. Так и RCE запретить недолго: компьютер же соединен с серверами волнами или проводами — физически!
Поскольку прошло 45 дней с момента отчета, я решил публично раскрыть детали уязвимости, хотя я не уверен, что это сподвигнет разработчиков Steam внести изменения.
Небольшие статистические данные: уязвимость была проверена на Windows 8 x64, Windows 8.1 x64 и Windows 10 x64. Я не знаю особенностей нумерации версий ПО 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% вы не получите скрытый майнер? Конечно, часть угроз останется и при работе без прав администратора, но высокие права у вредоносных программ могут существенно попортить нервов – отключение антивируса, закрепление в системные автозагрузки, изменение практически любых файлов, любых пользователей.
Благодаря популярности Steam, количество потенциальных пострадавших очень велико. В 2015 году количество активных учётных записей Steam оценивалось как 125 миллионов. Да, не у всех пользователей Steam ОС Windows, но у большинства точно, и у каких-то пользователей по нескольку «живых» аккаунтов на одной машине. Но масштабы проблемы все же впечатляют.
А может все это оставлено специально? Может, Steam — это своего рода легальный бекдор? Точно установить это невозможно, но давайте сопоставим факты:
- Есть уязвимость, которую легко эксплуатировать (причем, судя по сообщениям в твиттере, не одна).
- Ее довольно легко обнаружить — я не уверен, что я первый нашел ее, но как минимум первый описал публично.
- Нежелание принимать отчет о такой уязвимости и похожих (скоуп специально выбран так, что повышение привилегий из него выпадает).
Все это мне очень не нравится. Я не буду призывать вас удалять Steam, но предлагаю быть очень внимательным с тем, что он делает. На кону ваша безопасность.
Бонус
Дело в том, что в процессе подготовки этой статьи произошло довольно интересное событие, в связи с которым я решил дополнить таймлайн.
20 июля — после отклонения отчета, я предупредил h1, что публично раскрою детали уязвимости после 30 июля.
2 августа — еще один сотрудник h1 отмечается в закрытом отчете и говорит, что они не разрешают мне проводить раскрытие.
Данная статья была подготовлена к публикации уже к 30 июля (такая дата была выбрана из расчета 45 дней после отправки отчета), но задержалась. И вот, спустя две недели от моего сообщения 20 июля, появляется человек, который говорит мне: «мы не даем разрешение на раскрытие уязвимости». Фактически, получается: мы отметили твой отчет, как неподходящий, мы закрыли обсуждение, мы не посчитали нужным ничего тебе объяснять и мы просто не хотим, чтобы ты публиковался. При этом не единого слова от Valve. Нет, ребята, так дело не пойдет. Вы не стали уважать мою работу, я не буду уважать вашу — не вижу причин не публиковать этот отчет для всех. Скорее всего меня забанят на h1 из-за этого, но я огорчаться не стану.
Автор: xi-tauw
