Повышение Локальных Привилегий Клиента Steam Для Windows 0Day

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

Это абсолютное нежелание вендоров принимать информацию об уязвимостях и проблемах.

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

Неприятно публично подтверждать в открытых источниках, что были проблемы, что сотрудники что-то не так сделали.

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



Повышение локальных привилегий клиента Steam для Windows 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 и устанавливает некоторые права для всех подразделов.



Повышение локальных привилегий клиента Steam для Windows 0day

Интересно, какие права здесь выставлены? Создаем тестовый ключ, запускаем сервис (лог procmon выше) и смотрим, что происходит с правами.

Здесь обнаруживается, что раздел HKLM\SOFTWARE\Wow6432Node\Valve\Steam Для всех пользователей установлены полные права доступа, которые наследуются по всем подразделам.

Рождается гипотеза, что всем подразделам будут предоставлены одинаковые права.

HKLM\SOFTWARE\Wow6432Node\Valve\Steam\Apps по телефону RegSetKeySecurity .

Что делать, если в реестре есть символическая ссылка и ветка HKLM\SOFTWARE\Wow6432Node\Valve\Steam\Apps\test укажет, например, HKLM\SOFTWARE\test2 ? Проверяем и видим, что права в случае с симлинком прописаны для целевой ветки реестра.



Повышение локальных привилегий клиента Steam для Windows 0day

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

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

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

Это права, которые сервис Steam предоставил ветке.

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

Отчет об уязвимостях

Я отправил отчет об уязвимостях в Valve через Hackerone. Здесь меня ждал первый сюрприз — прежде чем отправить уязвимость напрямую в Valve, мне сначала нужно было убедить сотрудников хакерона, что у меня действительно есть отчет об уязвимости, поскольку Valve использует функцию «Управляется HackerOne» .

Я не против — у меня есть PoC, который вызывает консоль от имени NT AUTHORITY\SYSTEM — доказательства очевидны.

И получаю отказ по отчету.

Причина указана в том, что мой отчет выходит за рамки исследования, поскольку «Атаки, требующие возможности перетаскивать файлы в произвольные места файловой системы пользователя».

(для атаки необходима возможность размещать файлы в произвольных путях файловой системы).

Моя реакция: «У меня даже нет ни одной операции с файловой системой, но она не работает по этой причине, серьезноЭ» Пишу комментарий по этому поводу и приходит еще один сотрудник, который все же берется проверить уязвимость.

Подтверждает его и передает в Valve. Ура, цель достигнута.

Или нет…? Проходит время, и отчет снова помечается как неприменимый.

Причины: «Атаки, требующие возможности перетаскивания файлов в произвольные места файловой системы пользователя» и «Атаки, требующие физического доступа к устройству пользователя» (атака требует физического доступа к устройству пользователя).

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

Например, в причине «Атаки, требующие возможности перетаскивания файлов в произвольные места на файловой системе пользователя» я выделил ключевые слова, на мой взгляд. Мне показалось, что по этой причине 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 июня - отклонено: «Атаки, требующие возможности перетаскивать файлы в произвольные места файловой системы пользователя».

16 июня — вновь обнаружен с комментарием.

2 июля - Подтверждено сотрудником HackerOne, передано Valve. 20 июля — отвергнуты «Атаки, требующие возможности перетаскивать файлы в произвольные места файловой системы пользователя», «Атаки, требующие физического доступа к устройству пользователя».

7 августа - эта статья была опубликована.



Немного предположений

Я крайне разочарован.

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

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

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

Из-за популярности Steam количество потенциальных жертв очень велико.

В 2015 году количество активных аккаунтов Steam оценивалось в 125 миллионов.

Да, не у всех пользователей Steam установлена ОС Windows, но у большинства она наверняка есть, а у некоторых пользователей есть несколько «живых» учетных записей на одном компьютере.

Но масштаб проблемы по-прежнему впечатляет. А может быть, все это было оставлено специально? Может быть, Steam — это какой-то легальный бэкдор? Точно установить это невозможно, но давайте сравним факты:

  1. Есть уязвимость, которую легко эксплуатировать (и, судя по сообщения в твиттере , не один).

  2. Обнаружить его довольно легко — не уверен, что я был первым, кто его нашел, но, по крайней мере, первым, кто описал его публично.

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

Мне правда все это не нравится.

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



Бонус

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

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

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

Данная статья была подготовлена к публикации к 30 июля (эта дата была выбрана исходя из 45 дней после отправки отчета), но задержалась.

И вот, спустя две недели после моего сообщения от 20 июля, появляется человек, который говорит мне: «Мы не даем разрешения на раскрытие уязвимости».

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

При этом ни одного слова от Valve. Нет, ребята, так не пойдет. Вы не уважали мой труд, я не буду уважать ваш - не вижу причин не опубликовать этот отчет для всех.

Скорее всего меня из-за этого забанят на х1, но я не расстроюсь.

УПД.

Оказывается, вчера (6 августа) вышло обновление Steam. Нет, это ничего не исправило.

Версия файла: 5.27.59.20 подпись от 06.08.2019.

После раскрытия

Продолжаем обновлять хронику: 7 августа (после публикации) - отчет по h1 был открыт заново.

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

В нем также говорилось: «Valve не собирается исправлять то, что, по их мнению, является неприменимым».

Эти слова еще раз подтвердили мою убежденность в том, что я был прав, публично раскрыв подробности.

7 августа Мэтт Нельсон пишет что уязвимость, о которой он сообщил, точно такая же, как и моя.

Что подтверждает мой тезис о легкости его поиска.

Он открывает свой PoC .



Повышение локальных привилегий клиента Steam для Windows 0day

9 августа — Steam Beta получает обновление, где одна из строк — «Исправлен эксплойт повышения привилегий с использованием символических ссылок в реестре Windows».

Есть подозрения, что исправление можно обойти, а пока запасаемся попкорном.

13 августа -Пар получает обновление , где одна из строк — «Исправлен эксплойт повышения привилегий с использованием символических ссылок в реестре Windows».

Похоже, сервис не выставляет права в реестре, поэтому можно считать, что это исправлено.

15 августа - исследователь показал, что патч можно обойти , уязвимость все еще актуальна.

Краткое решение - можно вернуть предыдущие (до патча) версии сервиса.

20 августа — Valve забанила меня в своей программе на H1. Остальная часть H1 мне доступна.

Эта статья на английском языке.

Теги: #информационная безопасность #steam #уязвимость #эскалация привилегий #уязвимость нулевого дня #0day #eop #lpe #публичное раскрытие

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.