Обход некоторых видов ограничений запуска приложения через механизмы Software Restriction Policies (в режиме Unrestricted) в групповых политиках Active Directory

Некоторые администраторы применяют в своей инфраструктуре Active Directory (AD) функционал Software Restriction Policies (SRP), имеющийся в составе Group Policy, для того, чтобы явным образом ограничивать запуск и исполнение каких-либо приложений. То есть используется сценарий ограничительных мер по типу "разрешено всё, кроме того, что явно запрещено". Например, в рамках мероприятий по противодействию новомодным комплексным шифровальщикам, у некоторых администраторов может возникнуть желание явно запретить запуск некоторых исполняемых файлов, используемых вредительским ПО, не запрещая при этом запуск всех прочих приложений и не используя механизмы проверки цифровых подписей.

В данной заметке мы поговорим о том, почему мероприятия подобного рода могут оказаться малоэффективны, наглядно продемонстрировав пример того, как любой непривилегированный пользователь может без особых сложностей обойти некоторые механизмы защиты. В качестве наглядного примера мы рассмотрим ситуацию с запретом исполнения небезызвестной утилиты PsExec из пакета PsTools Sute.

Итак, предположим, что администратор домена настроил общую для всех компьютеров политику, в которой в разделе Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies > Additional Rules несколькими правилами запретил запуск утилиты PsExec по двум критериям – Path и Hash. То есть при запуске приложений проверяется, как путь так и хеш файла

При этом в Security Level администратор выбрал режим работы SRP - Unrestricted, то есть разрешено всё, кроме исключений, описанных в Additional Rules

Назначив такую политику на доменные компьютеры, администратор выполняет попытку запуска утилиты PsExec, и убедившись в том, что система вещает о невозможности запуска - "This program is blocked by group policy. For more information, contact your system administrator", считает свою задачу выполненной.

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

Пользователь конечно может попытаться переименовать файл, чтобы выйти из под действия Path-правила SRP, но система всё равно не даст запустить приложение, так как хеш приложения будет совпадать с запрещающим Hash-правилом SRP.

Таким образом перед нашим пользователем встаёт задача изменения хеша исполняемого файла, чтобы SRP больше не считал его запрещённым приложением. Но как изменить хеш файла, не повредив при этом сам файл? Если пользователь имеет доступ на изменение файла, то для решения поставленной задачи можно использовать механизм подмены цифровой подписи файла, при условии, что в системе не используется никаких механизмов форсированной проверки цифровых подписей запускаемых приложений и самому приложению "фиолетово" до подвешенной на него цифровой подписи.

Чтобы продемонстрировать простоту и доступность этого метода, в первую очередь нашему Пете потребуется цифровой сертификат с поддержкой Code Signing (1.3.6.1.5.5.7.3.3).

Получение Code Signing сертификата

Получить Code Signing сертификат можно разными путями. Если администратор доменных служб сертификации AD любезно предоставил всем желающим использовать шаблон сертификата, в котором есть поддержка Code Signing, то Петя сможет получить сертификат, которому любая доменная система уже будет отчасти доверять. С другой стороны, если нет необходимости заморачиваться с доверием сертификату (если проверка подписания исполняемых файлов не обязательна), то нашему Пете вполне подойдёт самоподписанный сертификат, который он способен сделать и установить в своё хранилище личных сертификатов без чьей-либо помощи и без необходимости иметь какие-то административные привилегии.

Если Петя сидит на модной Windows 10, где администратором домена не запрещено использовать PowerShell, то создать само-подписанный сертификат нужного типа – вопрос вызова буквально одного командлета:

New-SelfSignedCertificate -CertStoreLocation cert:\currentuser\my `
-Subject "CN=Petya Code Signing" `
-KeyAlgorithm RSA `
-KeyLength 2048 `
-Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" `
-KeyExportPolicy Exportable `
-KeyUsage DigitalSignature `
-Type CodeSigningCert `
-NotAfter $([datetime]::now.AddYears(25))

В результате такого запроса будет сгенерирован самоподписанный сертификат с правом подписывания кода сроком действия в 25 лет. Созданный сертификат автоматически будет помещён в хранилище личных сертификатов пользователя.

Если злобный администратор закрыл доступ к оснасткам MMC, то Петя, не прибегая лишний раз к инструментам командной строки, без особых трудностей может визуально убедиться в присутствии сгенерированного сертификата в хранилище личных сертификатов, например, через окно управления настройками браузера, которое может быть вызвано как из меню браузера Internet Explorer, так и из Панели управления.

А если система у нашего Пети более старая, чем Windows 10, или администратор настолько коварен, что ограничил доступ к оболочке PowerShell, то можно прибегнуть к помощи старой доброй "on-board" утилиты certreq.

Создаём конфигурационный файл запроса по типу:

[NewRequest]
Subject = "CN=Petya Code Signing v2"
KeyLength = 2048
KeyAlgorithm = RSA
ProviderName = "Microsoft Enhanced RSA and AES Cryptographic Provider"
MachineKeySet = false
Exportable = true
KeySpec = 2
KeyUsage = 0x80
RequestType = Cert
NotAfter = "29.03.2043"
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.3 ; Code signing

Выполняем запрос, указав конфигурационный файл:

certreq -new C:\Temp\PetyaRequest.inf

В результате выполнения такого запроса сертификат будет сгенерирован и также  автоматически установлен в личное хранилище сертификатов пользователя

Итак, нужный сертификат имеется. Далее нам потребуется любой инструмент, который умеет работать с цифровыми подписями исполняемых файлов Windows.

Подмена цифровой подписи

Для работы с цифровой подписью существуют разные утилиты, но мы по традиции выбираем ту, которая "родней" с точки зрения вендора – утилита SignTool. Эту утилиту можно найти в составе Visual Studio или Windows SDK (например, для SDK Windows 8.1 x64 эту утилиту можно найти в каталоге C:\Program Files (x86)\Windows Kits\8.1\bin\x64). Подробней о работе этой утилиты можно почитать здесь. 

Посмотреть текущие цифровые подписи интересующего нас приложения можно командой:

signtool verify /pa /v C:\Tools\PsExec.exe

либо,  просто заглянув в графической оболочке Windows Explorer в свойства интересующего нас исполняемого файла на вкладку Цифровые подписи:

Теперь Пете остаётся только заменить имеющуюся цифровую подпись собственной:

signtool sign /a /v C:\Tools\PsExec.exe

В ходе выполнения команды, для подписи указанного файла из личного хранилища сертификатов пользователя автоматически будет выбран наиболее подходящий сертификат (опция /a), а прежняя цифровая подпись файла будет заменена подписью пользователя:

Разумеется, после подмены цифровой подписи, изменится размер файла и теперь его хеш будет отличаться от хеша оригинального файла, который был запрещён администратором SRP.

Теперь в качестве завершающего штриха пользователю остаётся только переименовать исполняемый файл таким образом, чтобы его имя не совпадало с именем оригинального заблокированного приложения.

В конечном результате Петя может запускать приложение.

В качестве вывода, хочется отметить, что SRP – механизм, безусловно, интересный и в своей степени заслуживающий внимания, но приступать к его продуктивной эксплуатации нужно только внимательно изучив все особенности его работы. В противном случае может получиться так, что настроенные администратором правила не будут нести ничего, кроме бестолковых накладных расходов на каждой доменной машине, на которой задействован данный функционал. А ведь эти мощности можно использовать для просмотра котиков, ну или, на худой конец, для майнинга :)

Для тех, кто ещё только собирается внедрять SRP или хочет навести у себя в этом порядок, весьма полезными могут отказаться русскоязычные статьи Vadims Podans: Sysadmins LV - Software Restriction Policies.