Одной из самых больших проблем с Software Restriction Policies была настройка доверенных издателей (Trusted Publishers), о которой я уже писал: Секреты Software Restriction Policies (часть 3). Другое, более элегантное решение лежало практически на поверхности, но я его никак не замечал. В кратце напомню проблематику:

Если у нас есть недозволенное подписанное приложение, то мы можем импортировать сертификат цифровой подписии в секцию Trusted Publishers для доверия конкретному издателю. Но кроме этого нам нужно обеспечить доверие сертификату подписи, путём размещения корневого сертификата в цепочке в секцию Trusted Root Certification Authorites пользовательского хранилища (User Store). Чтобы как-то защититься от этого, приходилось в политике SRP запрещать пользователям добавлять сертификаты цифровых подписей в секцию Trusted Publishers (делая её read-only). Это спасало от нечистых на руку пользователей, которые могли добавлять свои сертификаты и обходить политику. Однако, этот метод имел серьёзные негативные эффекты: переставал работать Windows Update на Windows XP/2003, останавливалась служба Windows Defender, невозможно было использовать продукты Live и др.

Сегодня блуждая по политикам наткнулся на ещё одну настройку, которая запрещает доверять сертификатам в пользовательском контейнере Trusted Root CAs! Для этого нужно открыть редактор групповой политики и перейти по пути:

Computer Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> выбрать свойства Trusted Root CAs

и здесь убрать единственную галочку. В Windows Vista/2008 и выше эта настройка выделена в отдельный элемент. Вместо Trusted Root CAs элемент называется Certificate Paths Validation Settings:

Хоть пути до настроек чуточку отличаются, но суть от этого не меняется. Достаточно убрать эту галочку и получать профит. Так же, как и с паблишерами, секция Trusted Root CAs в пользовательском хранилище становится в режим Read Only. Причём, эта настройка удаляет все корневые сертификаты, которые были добавлены пользователями (т.е. существуют только в пользовательских хранилищах, но не в компьютерном), т.е. администраторам не надо будет заботиться о чистке пользовательских Cert Store, оно будет вычещенно само. Если попытаться импортировать корневой сертификат из файла, то получите вот такой бонус:

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

Примечание: данная настройка отсутствует в политике Windows XP

Кстати говоря, данная настройка в Windows 7/Windows Server 2008 R2 так же позволяет избежать атаки на правила издателя (Publisher) AppLocker'а путём подстановки своего корневого сертификата и запуска файлов с поддельной цифровой подписью.

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

з.ы. на днях я ВНЕЗАПНО узнал о существовании такой мега-завальной штеллы как Snipping Tool, который поставляется вместе с Windows Vista и выше для создания скриншотов нужных окон! За 2,5 года использования висты я ни разу его так и не запустил, из-за чего приходилось извращаться через Paint, что было несколько уныло, зато у меня теперь есть удобный инструмент для снятия пруфпиков и ещё один веский повод сказать, что Vista рулит! :rock:

Чуть не забыл про обещание выложить ответ тех.поддержки по поводу проблематики, изложенной в Секреты Software Restriction Policies (часть 5). Вот какой я получил ответ от них:

Hello Vadims,

My name is Rahul and I am from the Windows Core Team at GTSC.  I have been looking at this case for the Software Restriction Policy.

After some testing we have been able to recreate the behaviour that you are noticing:

This seems to be by design. On the Explorer.exe side, everything seems to be running ok.  We cannot launch the file types restricted via policy. This is because when ShellExecute comes into play, we enforce SRP policies. This is also true for the Windows Script Host, which does it's own checks apart from the shell.  Specifically regarding mshta.exe, we have the following situation:

- Since the shell is allowed to run lnk files, we do it ok;

- Since there's a specific additional rule that will allow us to run anything located under %windir%\system32, the shell can't enforce any SRP policy, since lnk files can be run.

- The shell starts mshta.exe, which, by its own, doesn't enforce the SRP policy, allowing the file to run.

This behaviour is by design.

итого, мы имеем следующее: как выяснилось, политика SRP не очень плотно накладывается на систему и внешние приложения должны сами проверять открытие своих файлов на соответствие правилам SRP. Если мы запускаем файлы через ярлыки. Что с успехом делают cmd.exe, msiexec.exe и cmd.exe. Но такие приложения, как regedit.exe, mshta.exe, hh.exe, mmc.exe ничего не знают о существовании SRP и неспособны произвести такую проверку. Понятно, что это by design (в чём я и не сомневался), но какой-то не очень удачный design. Вот так.

Сегодня расскажу о ещё одном способе обхода политики SRP и запуске VBS кода в обход политики. На саму идею меня натолкнул Александр Станкевич.

Суть проблемы была в следующем. Если мы создадим более ограничивающую политику, например, разрешив только запуск .exe файлов из %systemroot% и %systemroot%\system32, то у нас будет 2 таких правила:

• Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%*.exe
• Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%system32/*.exe

И тогда у нас из разрешения выпадают .exe файлы из других папок, а так же выпадают остальные типы файлов из указанных папок. Но мы часто пользуемся консолями MMC, которые имеют расширение .MSC и которые проверяются политикой SRP:

Так вот, если мы попробуем запустить любой .msc файл из папки system32, то получим ошибку:

Вроде всё логично, т.к. для MSC файлов нету отдельных исключений в Additional Rules. Но эта же оснастка запускается через Start –> Administrative Templates –> Services.lnk.

В этом пункте меню находится ярлык на соответствующую оснастку в папке System32. Быстро сориентировавшись я стал искать способ использования этой лазейки и достаточно быстро её нашёл. Ни для кого не секрет, что кроме cscript.exe в системе есть ещё 2 обработчика VBS/JS – это Internet Explorer и MSHTA.exe. Запуск  VBS/JS через IE – занятие довольно утомительное, поскольку этот код сильно зажат на уровне сетевых зон и просто так код запустить не удастся (нужно существенно изменить настройки сетевых зон, чтобы IE без вопросов исполнял абсолютно всё, не спрашивая пользователя). Но MSHTA.exe (HTA – HTML Application) не использует сетевые зоны и так же является обработчиком кода VBS/JS, который завёрнут в HTML обёртку. Типичный пример HTA – Manage Your Server в Windows Server 2003. Я сделал следующий трюк – создал на рабочем столе файл .hta следующего содержания:

<HTML>
<script language="vbscript">
    msgbox "I'm dangerous VB Code!!!!1!11"
</script>
</HTML>

и попытался его запустить – получил ошибку. Однако я рядышком сделал шорткат (ссылку) на этот файл и запустил через ссылку. И файл запустился! Я увидел исполненный VBS код. В принципе, внутри тега <script> можно записать любой VBS/JS код и он будет работать. Однако такой способ не сработал для файла с расширением .VBS. В ходе экспериментов было выделено 2 группы расширений, которые различно хандлятся политикой SRP при запуске этих файлов через шорткаты:

• REG, MSC, HTA, CHM – не хандлятся политикой SRP и запускаются в обход политики через ссылки на указанные файлы.
• CMD, BAT, MSI, VBS, JS – эти типы файлов корректно хандлятся политикой SRP и их запуск через ссылки невозможен.

В принципе, HTA обычно редко используется в работе (кроме случаев собственных наработок администраторов), поэтому в общем случае можно блокировать запуск mshta.exe, reg.exe и hh.exe, который используется для просмотра CHM файлов.

В настоящее время я открыл кейс в техсаппорте Microsoft по этому поводу, поэтому если от них будут какие-то новости, то я об этом обязательно расскажу. Такие дела.

Недавно на форуме SysFaq.ru была занятная тема про порядок применения групповых политик в домене. В общем смысле там вопрос сводился к приоритету политик, что настроенный параметр в доменной политике будет иметь приоритет над тем же параметром в локальной политике и работает принцип LSDOU (Local, Site, Domain, OU). Но если говорить по SRP, то здесь есть свои нюансы.

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

fig.1.

Т.е. видно, какая политика выиграла. В случае с SRP, вы этого не увидите:

fig.2.

Когда вы получите набор правил из всех политик, то вполне вероятны конфликтные ситуации, когда в одной политике правило разрешает запуск чего-то, а в другой политике запрещается, то финальная политика определяется по своим особым законам. Причём, сложности добавляет тот факт, что внутри порядки разные. Например, порядок разбора правил путей отличается от порядка разбора всех остальных типов правил. Поэтому я решил немного детальней осветить этот вопрос, чтобы не было никакой путаницы. Я ещё в журнальной статье (На страже безопасности – Software Restriction Policies) отмечал про порядок применения типов правил. Однако, формат журнала не позволял детально рассмотреть этот момент, поэтому я его раскрываю здесь.

Итак, когда на клиентский компьютер применилось несколько политик со своими правилами, то они сортируются по конфликтным парам. Конфликтную пару могут составить 2 одинаковых правила (например, по сертификату или хешу), но с разными уровняеми (Unrestricted, Disallowed). Если для правила не нашлось конфликтной пары, то оно считается единственным правилом в паре и в итоге оно будет результирующим. При этом все пары сортируются и проверяются в строгом порядке:

• [сперва запрет, потом разрешение] Правило сертификата
• [сперва запрет, потом разрешение] Правило хэша
• [сперва запрет, потом разрешение] Правило сетевой зоны
• [сперва разрешение, потом запрет] Правило пути

Для первых трёх типов на каждый объект может быть задана одна пара правил (не может быть для одного файла 2 разных хеша, поэтому для него существует только один хеш и для этого хеша может быть 2 уровня – Unrestricted/Disallowed). И для первых трёх типов правил работает правило First Matching. При попытке запуска файла сперва проверяется запрет по правилу сертификата. Если он есть, то дальнейшая проверка правил обрывается и на основе first matching доступ прекращается. Если же запрета нету, то проверяется разрешение на основе сертификата. Если разрешение есть, то опять же на основе first matching доступ к файлу разрешается и остальные правила не проверяются. Если же правила сертификатов для объекта не обнаружено, то проверка переходит к правилам хешей. Та же самая ситуация повторяется и с хешами и правилами сетевой зоны. Если ничего из этого не соответствует объекту, то процесс переходит к проверке правил путей.

В правилах пути существует свой порядок сортировки правил:

• [сперва разрешение, потом запрет] сначала самое общее правило (например, C:\)
• [сперва разрешение, потом запрет] более точное (например, C:\Documents and Settings)
• [сперва разрешение, потом запрет] ещё более точное (например, C:\Documents and Settings\All Users\Desktop)
• [сперва разрешение, потом запрет] <...> до полного соответствия имени файла

Здесь так же правила разбиваются на пары. Т.е. для каждой точки пути подбирается такое же правило, но с другим уровнем Unrestrited/Disallowed. Как можно заметить, здесь меняется порядок проверки запретов и разрешений. Если в первых трёх типах правил первыми проверялись запреты, то в правилах путей всё наоборот – сначала обрабатываются разрешения и только потом запреты. Это обусловлено тем, что для правил путей нету правила First Matching, а проверяются абсолютно все правила. При этом, как видно из описания, сначала проверяются более общие правила с бОльшей площадью охвата (как весь диск C:\). И вот так проверяются все правила путей и результирующим правилом для объекта станет то, которое проверилось самым последним, которое будет самым точным из всех правил, под которое подпадает проверяемый объект. Безусловно, если есть пара, которая одновременно разрешает и запрещает запуск по полному имени файла, то последним проверится запрет и доступ будет запрещён. В этом смысле так же работает правило, что одинаковый запрет имеет приоритет над таким же разрешением. Если в исключениях не нашлось ни одного правила, под которое смог бы подпасть объект, тогда решение о запуске будет приниматься на основе Default Level.

Примечание: при проверке результирующей суммы в RSOP.MSC на клиентах Windows Vista SP1 и выше вы можете попасть на одну засаду. Дело в том, что новая консоль RSOP.MSC теперь показывает не всё. В разрезе результирующей политики вы не увидите правил сертификатов! Т.е. они по факту есть и работают (соответствующие сертификаты размещаются в контейнерах Trusted/Untrusted Publishers в CertStore), но в этой консоли их не будет. Почему так – я не знаю, но вам следует принимать во внимание этот факт.

Примечание: хочу замтетить, что порядок применения политик SRP влияет только на Default level, Enfocrement, Designated Files Types и секцию Trusted Publishers. Для Additional Rules порядок применения политик не имеет значения.

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.

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