Update 04.09.2009: для защиты от атаки на SRP путём подмены сертификатов цифровой подписи обязательно прочтите обновлённый материал: Защищаем Software Restriction Policies. Т.е. вместо отключения возможности добавления сертификатов в Trusted Publishers, вы можете запрещать пользователям добавлять свои сертификаты в контейнер Trusted Root Certification Authorities.

Update 20.12.2009: пофиксено правило запрета для папки Temp. Вместо переменной %systemroot% используется путь из реестра.

Update 22.04.2010: пофиксен путь реестра для принтеров.

Хорошие новости – сегодня раскроем очередную партию секретов Software Restriction Policies.

Плохие новости – буду срывать покровы и показывать, как ещё можно злонамеренно обходить политику.

Жизнь такая интересная штука, которая любит преподносить сюрпризы, как приятные, так и не очень. Вот и сейчас, казалось бы, считал, что разобрался с вопросом SRP, куда уж дальше? А вот и нет. Давайте по порядку.

1) Возьмём пост: Секреты Software Restriction Policies (часть 2) и список стандартных правил из него. Ни в коем случае в исключениях нельзя использовать переменные окружения, типа %systemroot%, %programfiles%, %userprofile%, etc, поскольку это таит в себе угрозу:

Start –> Run… –> set programfiles=c:\users\username\desktop

и эта строчка перепишет переменную окружения %programfiles% на новое значение. Как можно догадаться, что теперь это исключение в политике будет отрабатывать не на настоящую папку Program Files, а на десктоп пользователя и пользователь сможет запускать оттуда что угодно! И вы ничего с этим не сделаете. Следовательно, эти 2 переменные следует заменить на оригинальные значения (т.е. ключи реестра), если вы использовали переменные окружения, вместо ключей реестра, которые показывают реальный путь до этих папок:

Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

Но эти 2 переменные – не единственные, которые мы используем. Если у нас доменная сеть, то пользователям нужно разрешать запуск логонных скриптов, которые хранятся в папке NetLogon контроллера домена. Общий вид исключения выглядит как:

Unrestricted - %logonserver%\Netlogon\*.bat

Поскольку папка Netlogon реплицируется между контроллерами домена, то переменная %logonserver% позволяет гарантированно запустить логонный скрипт, даже если остальные контроллеры домена временно недоступны. Но, как я уже показал, переменную %logonserver% можно перенаправить куда угодно и используя это исключение может запускать свои приложения. Чтобы устранить этот недостаток можно пойти двумя путями:

• использовать полный прямой путь до папки со скриптами. Это может быть не очень удобно
• использовать цифровые подписи для логонных скриптов. Значительно повышает эффективность работы и безопасность запуска скриптов, но требует более серьёзной технической подготовки от IT-персонала.

Так же не следует заменять %logonserver% на \\domain.com\netlogon\*.bat, поскольку при разрешении имени домена далеко не факт, что пользователь получит имя и адрес работающего контроллера. В принципе, такой формат будет возвращать имя нужного контроллера, но я не готов ручаться, что это будет работать всегда.

Стало быть, утверждение из предыдущего поста: “следует предельно максимально использовать переменные окружения и ключи реестра вместо абсолютных путей” следует считать частично верным. Т.е. переменные окружения использовать не рекомендуется использовать вообще. А так же не рекомендуется использовать ключи реестра из ветки HKCU, поскольку пользователь может их менять на своё усмотрение.

2) с подсказки коллеги с форума SysAdmins.SU WindowsNT (который тоже активно применяет SRP в своих организациях и занимается исследованием этой темы). Пользователи могут шедулить задания, которые будут исполняться через каждую минуту и ждать, когда администратор временно отключит политику SRP и задание, таки, выполнится! Вот тут я не знаю как быть. Как вариант – дать пользователям Read Only на C:\Windows\Tasks через командную строку (например, через icacls), что запретит пользователям создавать задания. На сколько это хорошо или плохо уже судить не мне, поэтому здесь ничего категорично советовать не буду.

3) SRP бессмысленна с обработкой расширения LNK, поскольку тут таится другая угроза. Я думаю, что многие смотрели на эти исключения, но не видели лазейки. Например, исключение:

Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Desktop%*.lnk

Вы думаете, оно разрешит нам запускать только ярлыки с рабочего стола? Наивняк! Я тоже так думал, до вчерашнего дня, когда я отлаживал один скрипт на PowerShell и понял одну вещь. SRP не отличает файл от папки. Создаёте на десктопе папку, например, 1.LNK и из этой папки запускаете что хотите! SRP не отличит, что 1.LNK это папка, а не ярлык.

Я создавал исключения для .LNK по причине, что я не знаю, что это такое. Я знаю, что .LNK только ссылка. А может ли LNK самостоятельно исполнять какой-то код? Мне этого неизвестно. Поэтому я сначала использовал исключения для LNK.

4) так же WindowsNT подсказал другую проблему. Я уже неоднократно говорил об опасностях папки C:\Windows\Temp и папки спулера, а именно – что пользователи имеют право записи и исполнения в этих папках. Но эти папки разрешаются общим правилом SystemRoot, поэтому мы использовали отдельные запреты:

Dissalowed - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\DefaultSpoolDirectory%
Dissalowed - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%Temp

и для установки приложений и драйверов мы использовали REG файлы (ссылка на тему – в самом начале поста). Однако, как выяснилось, значение PolicyScope начинает действовать только после перелогона, что усложняет нам жизнь.

Поэтому было принято решение рекомендовать переносить спулер и системный темп за пределы системного каталога. Как вы это сделаете – выбирайте на свой вкус. Самое простое:

• спулер - http://support.microsoft.com/kb/318748
• системный Temp – переопределить переменную в Environment Variables:

Подменить его можно или вручную или стартапным скриптом.

Следовательно REG файлы для временного отключения и включения политики на локальном компьютере нужно отредактировать, а именно – убрать параметры Policy Scope и оставить только Default Level.

5) а теперь самый главный бонус для самых терпеливых, кто дочитал до сюда :-) . Внимание, на экран:

по умолчанию Trusted Publisher Management в SRP выставлен в All administrators and end users (в Windows Vista и Windows Server 2008) или End users в Windows XP/Windows Server 2003. Это поле отвечает за возможность добавления сертификатов в секцию Trusted Publishers пользовательского certificate store. И мало кто обращает на него внимания, поскольку значение этой настройки весьма неоднозначна в интернете и точную формулировку мало кто может дать и эту опцию почти никто не трогает.

А теперь делаем финт ушами:

потребуется .NET Framework SDK или любой инструмент для генерации сертификата. Самое простое – утилита makecert.exe.

• генерируем сертификат:

открываем командную строку, перемещаемся в папку, где хранится утилита makecert.exe и выполняем команду:

makecert.exe -n "cn=srp" -ss my -eku 1.3.6.1.5.5.7.3.3

этой командой сгенерируется сертификат с OID равным Code Signing. Сертификат хранится в хранилище Current User\Personal.

• Экспортируем сертификаты в .CER файл:

Открываем оснастку certmgr.msc, переходим в Personal и экспортируем этот сертификат в файл под именем, например, siging.cer. Далее открываем сертификат, переходим на вкладку Certification Path, выделяем Root Agency сертификат, жмём View Certificate –> Details –> Copy to file. Экспортируем корневой сертификат в .CER файл, например, root.cer. Эти сертификаты нам потребуются для обхода SRP.

• создаём скрипт:

открываем блокнот и в нём набираем:

msgbox “Hello World!”

сохраняем как script.vbs.

• подписываем этот скрипт:

для подписи потребуется утилита signcode.exe из того же SDK. Открываем командную строку, переходим в ней в папку, где хранится signcode.exe и выполняем команду:

signcode.exe -cn "srp" script.vbs

или

signcode.exe -cn "srp" -t http://timestamp.verisign.com/scripts/timstamp.dll script.vbs

эту часть пользователь может выполнить у себя дома. Теперь пользователю нужно доставить оба файла сертификатов и скрипт на рабочий компьютер как угодно. На рабочем компьютере (который защищён SRP) пользователь извлекает на рабочий стол (в любое место, куда ему разрешена запись) VBS файл и открывает оснастку certmgr.msc. В ней он импортирует:

• root.cer в секцию Trusted Root CAs
• signing.cer в секцию Trusted Publishers

пользователь дважды щёлкает на VBS файле и:

он запускается! Чтобы это сработало важно только добавить сертификат, который использовался при подписи скрипта в Trusted Publishers.

Бороться с этим можно только одним способом. Переставить переключатель в Allow only all administrators to manage Trusted Publishers. Если так сделать, то такой финт ушами уже не получится. Но тут мы сразу потеряем автоматическую установку Windows Update в Windows XP/2003. На сколько я понимаю Windows Update использует эту же лазейку. Т.е. при поступлении обновлений некая служба (вероятно Windows Update) с системными правами добавляет сертификат подписи в Trusted Publishers и инициирует запуск самих апдейтов, которые подписаны этим сертификатом. А апдейты в Windows XP/2003 сначала разжимаются в папку с рандомным именем в корне рандомного диска и устанавливаются. После чего сертификат удаляется из store. В Windows VIsta и выше файлы обновлений уже имеют расширение .MSU и не мониторятся политикой по умолчанию, поэтому в этих системах можно запретить пользователям добавлять сертификаты в Trusted Publishers. Но (не буду утвержать на 100%, но скорее всего это так) мы ещё потеряем возможность использования правил по сертификатам, которые настроены в User Configuration групповой политики, поскольку сертификат из той политики добавляется именно в User Store.

Вот такие дела, вобщем.