Как пользователь с ограниченными правами может обойти групповую политику

Для защиты систем Windows часто применяются параметры групповых политик службы Active Directory. Это удобно - такие параметры можно настроить и распространить среди компьютеров и пользователей сети Active Directory. В одной из предыдущих записей я предупреждал, что предоставлять конечным пользователям привилегии локальных администраторов опасно, поскольку при желании они могут переопределить параметры групповой политики. Относительно безопасной альтернативой такой практике мне представляются учетные записи с ограниченными правами. В то же время, администраторам ОС Windows следует иметь в виду, что если пользователю, даже если его учетная запись обладает ограниченными правами, удастся запустить хотя бы одну произвольную программу, то он сможет обойти многочисленные параметры групповых политик, в том числе те, которые направлены на строгую регламентацию безопасности (например, политики ограниченного использования программ и зоны Internet Explorer).

Уязвимость многих параметров групповых политик проистекает из того обстоятельства, что за их введение в силу ответственны те самые приложения, которые ими регламентируются. К примеру, если групповая политика определяет, а обозреватель Internet Explorer реализует защиту согласно параметрам зоны, проводник ограничивает работоспособность некоторых приложений. В архитектуре Windows разрешения безопасности процесса устанавливаются таким образом, что владелец процесса получает неограниченный контроль над ним. Убедиться в этом можно, взглянув на диалоговое окно Permissions (Разрешения), которое открывается из свойств процесса в программе Process Explorer.

Таким образом, пользователь может внести изменения в код или данные процессов, которые он контролирует, в том числе процессов проводника и обозревателя Internet Explorer. Если этот код или данные управляют применением параметров групповых политик, то такие параметры можно будет обойти.

Теперь обратимся к политикам ограниченного использования программ (Software Restriction Policies, SRP). Это еще один пример параметров групповых политик, которые пользователь с ограниченными правами может нарушить. Для этого достаточно предоставить ему возможность запустить произвольный исполняемый файл. Иначе говоря, если вместо того, чтобы перечислить исполняемые файлы, которые пользователь вправе запускать (составить «белый список»), администратор укажет исполняемые файлы, которые запускать нельзя (составит «черный список»), последствия могут оказаться весьма печальными. Когда пользователь запускает процесс, к политикам SRP для проверки разрешений обращается его родительский процесс. Это позволяет владельцу родительского процесса путем определенных манипуляций пропустить или отключить обработку политик SRP. Существует множество способов сделать это - в частности, можно написать программу, которая обращается к адресному пространству родительского процесса и подменяет строки путей реестра, указывающие на местоположение политик SRP, или вносит изменения в код, считывающий параметры реестра этих политик.

Я написал простое приложение под названием Gpdisable, которое демонстрирует, что отключить политики SRP чрезвычайно просто даже для пользователя с ограниченными правами. В приложении реализованы методики инъекции библиотек DLL, документированные Джеффом Ричтером (Jeff Richter) в книге издательства Microsoft Press «Programming Applications for Microsoft Windows» (Программирование приложений для Microsoft Windows). Они предусматривают загрузку библиотеки DLL во все процессы системы, к которым пользователь имеет доступ. Инъецируемая библиотека DLL подключает обработчик к API-интерфейсу NtQueryValueKey для перехвата всех вызовов к нему со стороны процессов или загружаемых ими библиотек DLL. Код политик SRP предусматривает обращение к API NtQueryValueKey для получения значения реестра HKLM\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers\TransparentEnabled. Если это значение обнаруживается и оно не приравнено к нулю, значит, политики SRP включены. Вот как выглядит трассировка программой Regmon приложения Cmd.exe (командной строки), считывающего значение в ответ на попытку запуска блокнота (Notepad.exe), который я запретил при помощи политик SRP.

Пользователи не вправе вносить изменения в разделы реестра, расположенные в пределах ветви HKLM, а значит, и в параметры политик SRP, но приложение Gpdisable обманывает код SRP, возвращая ошибку STATUS_OBJECT_NAME_NOT_FOUND всякий раз при передаче значения “TransparentEnabled” API-интерфейсу NtQueryValueKey.

На следующем снимке экрана видно сообщение об ошибке “The system cannot execute the specified program” (Системе не удается выполнить указанную программу), которое SRP передает после 1) неудачной попытки запуска блокнота в контексте учетной записи пользователя с ограниченными правами, 2) запуска приложения Gpdisable и 3) успешного запуска блокнота.

Обратите внимание, что существующие процессы, успевшие обзавестись дочерними процессами (в частности, проводник и командная строка), кэшируют значение TransparentEnabled, а значит, параметры политик SRP продолжают действовать. Следовательно, не представляет особого труда написать программу вроде Gpdisable, которая получала бы доступ к кэшам процессов и подменяла сохраненные в них значения.

Трассировка Regmon повторного запуска блокнота аналогична первой за тем исключением, что запрос значения TransparentEnabled в ней отсутствует. Его в пользовательском режиме перехватило приложение Gpdisable, так что вызов так и не достиг ядра.

Какие еще параметры групповых политик подвержены подобным атакам? Параметры безопасности системного уровня вводятся в действие базовыми компонентами ОС, недоступными для пользователей с ограниченными правами. В то же время, большинство параметров, расположенных в области Windows Components (Компоненты Windows) узла Administrative Templates (Административные шаблоны) редактора групповых политик, неэффективны в условиях, когда конечные пользователи могут запускать произвольные приложения наподобие Gpdisable.

Интересно, что в эту категорию попадает конфигурация обозревателя Internet Explorer, в том числе зоны, а также параметры проводника, проигрывателя Media Player и программы Windows Messenger. Вывод из всего этого прост: полный контроль над средой конечных пользователей возможен только при условии жесткой регламентации программ, которые пользователи вправе запускать. Достичь этой цели можно, в частности, с помощью политик SRP по методу составления белого списка. Также важно отметить, что способность пользователей с ограниченными правами подменять параметры групповых политик обусловлена не ошибкой в ОС Windows, а осознанными проектными решениями, принятыми рабочей группой корпорации Майкрософт по групповым политикам.

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