Опыты над опытными пользователями

Организации часто присоединяют учетные записи пользователей Windows к группе безопасности «Опытные пользователи». Тем самым они пытаются максимально ограничить свободу действий пользователей, избежав сложностей, связанных с учетными записями пользователей с ограниченными правами (limited users). Участники группы «Опытные пользователи» вправе устанавливать программное обеспечение, корректировать параметры питания и времени, а также устанавливать элементы управления ActiveX. Все эти действия недоступны для пользователей с ограниченными правами.

При этом многие администраторы не отдают себе отчет в том, что расширенные возможности «опытных пользователей» представляют серьезный риск в плане безопасности. Указания на то, что пользователь, состоящий в группе «Опытные пользователи», может без труда повысить свои права до уровня полноценного администратора, имеются во многих источниках, в том числе вот в этой статье базы знаний Майкрософт и в записи в блоге специалиста по безопасности корпорации Майкрософт Джеспера Йохансена (Jesper Johansen). Поскольку у меня не было данных о конкретных механизмах повышения прав, на которые ссылаются эти источники, я решил провести собственное расследование.

Впрочем, прежде нужно было четко сформулировать задачу. В отсутствие явных изъянов в системе безопасности, таких как переполнение буфера, повышение прав возможно лишь в том случае, если одна учетная запись может добиться исполнения произвольного кода в контексте учетной записи с более широкими привилегиями. Из числа учетных записей по умолчанию расширенные по сравнению с «опытными пользователями» привилегии характерны для учетных записей администратора и системной учетной записи, в контексте которых исполняются процессы некоторых служб Windows. Следовательно, для того чтобы получить неограниченные административные полномочия, участнику группы «Опытные пользователи» достаточно выполнить одно из трех действий: внести изменения в файл, исполняемый в контексте одной из этих учетных записей, скорректировать такой файл в расчете на загрузку произвольной библиотеки DLL или внедрить в одну из указанных учетных записей автозапуск некоего исполняемого файла.

Первым делом мне нужно было составить список файлов и каталогов, к которым участники группы «Опытные пользователи» имеют доступ на запись, а пользователи с ограниченными правами – нет. Эксперимент проводился под управлением обычных, распространяемых в розницу версий ОС Windows 2000 Professional с пакетом обновления 4 (SP4), Windows XP с пакетом обновления 2 (SP2) и Windows Vista. Изучать ситуацию в серверных системах не имело особого смысла, поскольку рассматриваемый сценарий с участием «опытных пользователей» в большинстве случаев имеет место на рабочих станциях.

Пойти напролом – выяснить, в какие объекты файловой системы участники группы «Опытные пользователи» могут вносить изменения, обследовав на предмет разрешений каждый файл и каталог – наверное, можно, но практичность такого подхода вызывает серьезные сомнения. Программа командной строки Cacls в составе ОС Windows выводит на консоль дескрипторы безопасности, но я совершенно не знаю языка описания дескрипторов безопасности (SDDL), а для анализа вывода программы нужно написать сценарий. Служебная программа AccessEnum Брайса Когсвелла (Bryce Cogswell), казалось бы, подходит для поставленных целей и к тому же умеет анализировать безопасность реестра, но все-таки она предназначена для обнаружения потенциальных уязвимостей, связанных с разрешениями, а не для анализа прав доступа, предоставленных тем или иным учетным записям. Решая проблему инструментария, я должен был учитывать, что мне потребуется, помимо прочего, исследовать безопасность служб Windows.

В итоге я пришел к выводу о том, что для решения задачи нужно написать новую служебную программу. Так появилась AccessChk. Этой программе передается, во-первых, имя учетной записи или группы, а во-вторых, путь в файловой системе, раздел реестра или имя службы Windows. На выходе она сообщает фактические права доступа к объекту, которыми располагает указанная учетная запись или группа – с учетом членства учетной записи в группах. Скажем, если учетной записи Mark предоставлен доступ к некоему файлу, но одновременно названная учетная запись состоит в группе Developers, участникам которой доступ к этому файлу явно запрещен, то программа AccessChk сообщит, что у учетной записи Mark нет прав доступа к файлу.

В целях удобочитаемости вывода программа AccessChk ставит букву ‘W’ рядом с именем объекта, если у учетной записи есть разрешения на его изменение, и букву ‘R’, если учетная запись имеет право чтения данных или состояния объекта. Предусмотрены параметры, заставляющие программу AccessChk выполнять рекурсию по подкаталогам или подразделам реестра, а параметр –v позволяет получить сведения о конкретных правах доступа, имеющихся у учетной записи. Специально для поиска объектов, в отношении которых у учетной записи есть доступ на запись, я добавил параметр –w.

Вооруженный новой утилитой, я полностью подготовился к тому, чтобы начать расследование. Первым подопытным стала система Windows XP с пакетом обновления 2 (SP2) и VMWare tools без каких бы то ни было дополнительных приложений (помимо названного инструментария). Первая выполненная команда выглядела следующим образом:

accesschk –ws “power users” c:\windows

В результате был получен список всех файлов и подкаталогов, находящихся внутри каталога \Windows, которые группа «Опытные пользователи» вправе изменять. Естественно, многие файлы, находящиеся в каталоге \Windows, относятся к операционной системе или службам Windows, а значит, исполняются в контексте системной учетной записи (Local System). По сообщению AccessChk, участники группы «Опытные пользователи» вправе вносить изменения в большинство подкаталогов \Windows, а значит, и создавать в них новые файлы. Следовательно, любой участник группы «Опытные пользователи» может создавать файлы в каталогах \Windows и \Windows\System32, чего часто требуют старые приложения сомнительного качества. Кроме того, «опытным пользователям» нужна возможность создавать файлы в каталоге \Windows\Downloaded Program Files. Без этого они не смогут устанавливать элементы управления ActiveX, поскольку обозреватель Internet Explorer сохраняет таковые именно в этом каталоге. Впрочем, возможность создания файлов в указанных каталогах сама по себе не позволяет повысить уровень привилегий.

Несмотря на то, что участники группы «Опытные пользователи» вправе создавать файлы в каталоге \Windows и большинстве его подкаталогов, настроенные по умолчанию в ОС Windows разрешения безопасности таковы, что доступ на запись к большинству файлов в этих каталогах имеют только участники группы «Администраторы» и системная учетная запись. Исключениями из этого правила являются файлы шрифтов (имеющие расширение log), некоторые файлы справки (chm), изображения и звуковые ролики (jpg, gif и wmv), а также файлы установки (inf). Ни изменение, ни подмена этих файлов не позволяет получить административные полномочия. Манипуляции с драйверами устройств, находящимися в каталоге \Windows\System32\Drivers, позволяют без труда повысить уровень прав, но участники группы «Опытные пользователи» не имеют к ним доступа на запись.

В полученном списке обнаружились файлы с расширениями exe и dll, так что я решил проверить их на предмет возможностей злоупотребления. Исполняемые файлы, к которым «опытным пользователям» предоставляется доступ на запись, в большинстве своем либо являются служебными программами, работающими в интерактивном режиме, либо исполняются с сокращенным набором прав. Чтобы повысить с их помощью уровень прав, нужно как минимум заставить администратора выполнить интерактивный вход в систему. Но есть одно исключение, и оно сразу бросается в глаза – ntoskrnl.exe.

Да, именно так – любой «опытный пользователь» может заменить или внести изменения в важнейший файл операционной системы Windows. Правда, через пять секунд после модификации этого файла защита файлов Windows (WFP) заменит его резервной копией, которая в большинстве случаев извлекается из каталога \Windows\System32\Dllcache. Поскольку участники группы «Опытные пользователи» не имеют доступа на запись к каталогу Dllcache, то и манипуляции с резервной копией им не под силу. Однако же ничто не мешает «опытному пользователю» обмануть WFP, написав элементарную программу, которая заменяет файл, сбрасывает его на диск в модифицированном виде, а потом перезагружает систему, тем самым предотвращая вмешательство WFP.

Я проверил – этот метод действительно работает. Оставался открытым вопрос о том, каким образом подобная уязвимость позволяет повысить уровень прав. Как выяснилось, для этого достаточно, воспользовавшись дизассемблером, найти функцию, которая применяется в Windows для проверки привилегий (она называется SeSinglePrivilegeCheck) и изменить точку входа в её дисковом образе таким образом, чтобы функция всегда возвращала значение TRUE – именно этот результат её выполнения свидетельствует о наличии у пользователя искомой привилегии. Стоит пользователю запустить систему с модифицированным таким образом ядром, как он получит все привилегии, необходимые для полного административного контроля над системой – в частности, привилегии Load Driver (Загрузка драйвера), Take Ownership (Смена владельца) и Create Token (Создание маркера). 64-разрядные версии ОС Windows XP посредством функции PatchGuard делают невозможными манипуляции с ядром, однако редкие предприятия их закупают.

Как бы то ни было, подмена файла Ntoksrnl.exe – это не единственный способ добиться прав администратора при помощи каталога \Windows. По крайней мере одна библиотека DLL (Schedsvc.dll), которая по умолчанию может быть изменена «опытными пользователями», исполняется как служба Windows в контексте системной учетной записи. Schedsvc.dll – это библиотека с реализацией службы планировщика заданий Windows. Операционная система в состоянии нормально функционировать без этой службы, так что «опытный пользователь» может заменить её библиотеку любой другой – хотя бы и такой, которая банально добавляет учетную запись злоумышленника в локальную группу «Администраторы». Разумеется, этот файл также находится под защитой WFP, обойти которую позволяет вышеописанная методика.

Обнаружив уже целый ряд возможностей для повышения уровня прав, я продолжил свои изыскания, проанализировав права доступа «опытных пользователей» к каталогу \Program Files. Картина сложилась примерно такая же, как и в случае с каталогом \Windows. Участники группы «Опытные пользователи» вправе создавать подкаталоги \Program Files, но они не могут вносить изменения в большинство предустановленных компонентов Windows. Исключения, как и в предыдущем случае, работают в интерактивном режиме – в частности, это программа Windows Messenger (\Program Files\Messenger\Msmgs.exe) и проигрыватель Windows Media (\Program Files\Windows Media Player\Wmplayer.exe).

Все это не означает, что права доступа к каталогу \Program Files не создают брешей в системе безопасности. Изучив самые свежие выходные данные, я заметил, что «опытные пользователи» могут вносить изменения в любые файлы и подкаталоги, созданные в каталоге \Program Files после базовой установки ОС Windows. В моей тестовой системе одним из таких файлов оказался \Program Files\Vmware\Vmware Tools\Vmwareservice.exe – файл образа службы Vmware, исполняемой в контексте системной учетной записи. Другой пример, несколько забавный, связан с бета-версией 2 Windows Defender, который устанавливает исполняемый файл своей службы в каталоге \Program Files\Windows Defender с параметрами безопасности по умолчанию. Достаточно подменить эти файлы образов служб, и права администратора в распоряжении пользователя. Это даже проще, чем подмена файлов в каталоге \Windows, поскольку в данном случае в процесс не вмешивается WFP.

Далее я обратил свой взор на реестр, выполнив следующую команду:

accesschk –swk “power users” hklm

Размер полученного списка впечатляет – оказывается, «опытные пользователи» имеют доступ на запись к большей части раздела HKLM\Software. Первым делом я изучил на предмет возможностей повышения прав раздел HKLM\System. Такой выбор обусловлен тем, что доступ на запись ко многим входящим в него параметрам – в частности, к разделам служб Windows и конфигурации драйверов в составе HKLM\System\CurrentControlSet\Services – позволяет банально взломать системную учетную запись. Впрочем, анализ показал, что участники группы «Опытные пользователи» не имеют доступа на запись к сколько-нибудь опасному содержимому этого раздела.

Почти все содержимое другой крупной ветви HKLM – Software, – к которому «опытные пользователи» имеют доступ на запись, связано с обозревателем Internet Explorer, проводником, сопоставлением файлов и конфигурацией управления питанием. Кроме того, таким пользователям предоставляется доступ на запись к разделу HKLM\Software\Microsoft\Windows\CurrentVersion\Run. Это позволяет им настраивать запуск произвольных исполняемых файлов в момент интерактивного входа в систему других пользователей. Правда, для непосредственного повышения уровня прав по такой схеме нужен случай интерактивного входа администратора, что в одних системах происходит нечасто, а в иных не происходит никогда. Как и в случае с каталогом \Program Files, «опытным пользователям» по умолчанию предоставляются права доступа к подразделам HKLM\Software, не связанным с операционной системой. Это значит, что приложения сторонних производителей, задающие в своих разделах реестра общесистемного уровня пути к исполняемому коду, создают бреши в системе безопасности. Кстати сказать, единственное установленное в системе стороннее приложение – VMWare – такую брешь не создало.

Разобравшись с реестром, осталось лишь прояснить ситуацию со службами Windows. Единственные разрешения, связанные со службами, в которых программа AccessChk усмотрела доступ на запись – это SERVICE_CHANGE_CONFIG и WRITE_DAC. Пользователь с разрешением SERVICE_CHANGE_CONFIG может настроить запуск одновременно со службой произвольного исполняемого кода, а разрешение WRITE_DAC позволяет скорректировать набор разрешений на доступ к службе, присвоив полномочия SERVICE_CHANGE_CONFIG. В моей обычной испытуемой ОС Windows XP с пакетом обновления 2 (SP2) обнаружилось следующее:

Чтобы узнать учетную запись, в контексте которой исполняется служба DcomLaunch, я запустил программу PsService и выяснил вот что:

Итак, любому участнику группы «Опытные пользователи» не составит труда изменить путь к образу службы DComLauncher, указав на любой другой образ, перезагрузить систему и в результате получить полный набор прав администратора.

Бреши в системе защиты могут создавать и другие службы. По умолчанию разрешения доступа к службам, созданным сторонними приложениями, не позволяют «опытным пользователям» осуществлять запись, но некоторые приложения модифицируют стандартные разрешения, в результате чего такая возможность появляется. Скажу больше – на моей рабочей 64-разрядной версии Windows XP с помощью программы AccessChk удалось обнаружить брешь, с помощью которой повышать уровень своих прав могут не только «опытные пользователи», но и пользователи с ограниченными правами.

На этом основная часть моего расследования подошла к концу. Увы, расхожее мнение подтвердилось – действительно, при определенных навыках участник группы «Опытные пользователи» может без лишних трудностей получить все права администратора, воспользовавшись эксплойтами, присущими операционной системе или созданными сторонними приложениями.

Наконец, мне захотелось узнать эволюцию политики корпорации Майкрософт в отношении группы «Опытные пользователи». В одной из статей базы знаний Майкрософт за 1999 год документируется известная возможность повышения уровня прав через хранитель экрана, обнаруженная в ОС Windows NT 4 и устраненная еще до выпуска Windows 2000. Судя по этой статье, в тот момент специалистам Майкрософт не было известно о существовании других уязвимостей (а они наверняка существовали). Бреши имеются и в ОС Windows 2000 с пакетом обновления 4 (SP4), но эта версия, надо заметить, несколько безопаснее стандартной конфигурации ОС Windows XP с пакетом обновления 2 (SP2) – «опытным пользователям» не предоставляется доступ на запись ни к файлу Ntoskrnl.exe, ни к файлу образа планировщика. Правда, вместо DComLauncher они имеют возможность манипулировать службой WMI, которая также исполняется в контексте системной учетной записи.

В ОС Windows XP с пакетом обновления 1 (SP1) появились новые уязвимости, связанные с группой «Опытные пользователи». В частности, её участники получили доступ на запись к таким важнейшим системным файлам, как Svchost.exe (процесс размещения служб Windows). Потенциально опасные разрешения были также предоставлены в отношении служб WMI и SSDPSRV. Некоторые службы даже позволяли повышать уровень прав по схеме, описанной в мартовской статье базы знаний Майкрософт.

В новейшей операционной системе Майкрософт, Windows Vista, все вышеперечисленные уязвимости устранены путем уравнивания группы «Опытные пользователи» и пользователей с ограниченными правами. Таким образом, ИТ-специалисты получили недвусмысленный сигнал о двух альтернативах – пользователей следует либо ограничивать в правах, либо, напротив, предоставлять административные полномочия, которые явно наделяют их возможностями управления своими системами.

Итак, специалисты корпорации Майкрософт, безусловно, могут (точнее, смогли) устранить уязвимости операционной системы, обнаруженные в ходе моего расследования, но они не в силах сохранить за «опытными пользователями» право устанавливать приложения и элементы управления ActiveX и при этом гарантировать, что новые подобные уязвимости не возникнут из-за поведения сторонних приложений. Что же касается администраторов, то им не следует испытывать иллюзии относительно того, что членство в группе «Опытные пользователи» представляет собой безопасную альтернативу работе в качестве пользователя с ограниченными правами.

Исходная запись создана пользователем Mark Russinovich 1 мая 2006 г. в 11:01:00
Запись перенесена из блога Sysinternals.com/Blog