Previous Page Page 2 of 3 in the SecuritySRP category Next Page
Секреты Software Restriction Policies (часть 5.a)

Чуть не забыл про обещание выложить ответ тех.поддержки по поводу проблематики, изложенной в Секреты 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. Вот так.

Security |  SRP
Friday, August 07, 2009 1:20:33 AM (FLE Daylight Time, UTC+03:00)   Comments [2]    

 

Секреты Software Restriction Policies (часть 5)

Сегодня расскажу о ещё одном способе обхода политики 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:

Designated File Types

 

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

Blocked MMC Console

Вроде всё логично, т.к. для 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 по этому поводу, поэтому если от них будут какие-то новости, то я об этом обязательно расскажу. Такие дела.

Security |  SRP
Friday, July 31, 2009 8:10:19 PM (FLE Daylight Time, UTC+03:00)   Comments [0]    

 

Секреты Software Restriction Policies (часть 4)

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

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

Source GPO fig.1.

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

No source GPO 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 порядок применения политик не имеет значения.

Security |  SRP
Tuesday, May 26, 2009 9:53:33 PM (FLE Daylight Time, UTC+03:00)   Comments [0]    

 

Секреты Software Restriction Policies (часть 3)

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 начинает действовать только после перелогона, что усложняет нам жизнь.

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

System Temp variable path

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

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

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

trust

по умолчанию 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 файле и:

Running VBS Script

он запускается! Чтобы это сработало важно только добавить сертификат, который использовался при подписи скрипта в 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.

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

Security |  SRP
Wednesday, May 13, 2009 11:12:14 PM (FLE Daylight Time, UTC+03:00)   Comments [14]    

 

Секреты Software Restriction Policies (часть 2)

Update 04.09.2009: относительно пункта 3 данного поста обязательно прочтите обновление информации по нему: Секреты Software Restriction Policies (часть 3) (так же прочитать пункт 3). Т.е. вы должны исключить LNK файлы из проверки политикой и, следовательно, исключения для них создавать не надо.

Так же прочтите обновление по этой же ссылки относительно использования переменных окружения в правилах SRP.

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

Итак, для тех, кто ещё не в курсе, о чём идёт речь предлагается прочитать:

В данном посте я планирую раскрыть секреты расширения SCF, трюки с hh.exe, рассмотреть вопросы унификации правил и два важных момента в управлении политикой.

1) Расширение SCF – это командный файл, который обрабатывается стандартным шеллом (он же explorer.exe). Данные файлы достаточно хитры, поскольку проводник (explorer) даже в режиме показа известных расширений никогда не показывает его. Это ещё пол беды. Основная угроза, которая может от них исходить – встраиваемость в файлы. В двух словах это выглядит как прописывание своего кода в любой файл (будь то текстовый, графический, медиафайл и т.д.), подмена расширения и иконки. Синтаксис SCF файлов очень похож на синтаксис INI и INF файлов. Т.е. он состоит из секций, заключённых в квадратные скобки и элементы секций:

[section]
parameter=value
[section2]
parameter2=value2
parameter3=value3

Самый знакомый нам файл такого типа – Show Desktop в панели quick launch. Это самый настоящий SCF файл, который имеет следующее содержание:

[shell]
Command=2
IconFile=explorer.exe,3
[TaskBar]
Command=ToggleDesktop

как видно отсюда, мы можем изменять иконку файла на любую. Очень полезно для маскировки файла под другой тип файла. И в секции TaskBar мы видим вызов внутренней команды explorer.exe – ToggleDesktop. Напомню, что эти файлы обрабатываются только оболочкой explorer.exe. Если сохранить эту часть в текстовом файле и указать расширение SCF, то вы получите сворачивалку окон. Если, к примеру, в секции Command указать другую команду, например, Explorer, то при двойном клике на него запустится сам explorer.exe:

[shell]
Command=2
IconFile=explorer.exe,3
[TaskBar]
Command=Explorer

А теперь как встраивать код в другие файлы. Берём любой произвольный файл, например картинку в формате JPEG, открываем его в текстовом редакторе, но лушче будет в FAR и в самое начало или самый конец файла пишем:

[shell]
Command=2
IconFile=imageres.dll,66
[TaskBar]
Command=Explorer

сохраняем изменения и переименовываем файл в image.jpeg.scf.В Windows Vista/Windows Server 2008 мы получим файл размером с картинку, подходящее расширение и значок JPEG файла (хвост .scf будет скрыт от нас в любом случае). Если по нему нажать 2 раза, то запустится explorer. Причём никаких ошибок вы не получите, потому что остальное содержимое файла будет проигнорировано и будет выполнена только та часть кода, которую мы добавили. Искать иконки можно различными редакторами ресурсов, как Restorator или ResHacker. Просто в категории Icon или IconGroup выбираете нужный номер иконки и вставляете этот номер в параметр значка. При этом скорее всего потребуется уменьшить это число на единицу, поскольку Explorer будет считать значки с нуля, в то время как редакторы ресурсов считают с единицы. Но это уже детали.

К сожалению я в данный момент не обладаю сведениями о полном функционале файлов SCF, но доподлинно известно, что ими можно манипулировать как оболочкой explorer.exe, так и браузером Internet Explorer. Поэтому я пока не могу сказать на сколько это может быть опасно. Но неадекватное поведение файла при его запуске может доставить массу хлопот как самим пользователям, так и администраторам.

Следовательно имеет смысл при развёртывании политики SRP включить данное расширение в список блокируемых, а значок Show Desktop.scf разрешить по хэшу! Это важно, поскольку разрешение пути позволит пользователю модифицировать файл и исполнить его.

Примечание: в новых версиях Windows начиная от Windows Vista значок ShowDesktop.scf был сменён с SCF файла на Show Desktop.lnk, следовательно для этих версий ОС достаточно будет просто включить данное расширение в список и всё. Хотя SCF файл в Windows Vista будет работать :)

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

Start –> Run… –> hh.exe path\helpfile.chm

и всё. К сожалению, я не нашёл метода, как гибко бороться с этим, только явно запрещать политикой SRP запуск программы hh.exe. Ещё к бОльшему сожалению блокировать CHM файлы в системах до Windows Vista тяжело, поскольку почти вся справка Windows там написана в CHM. Однако, в Windows Vista и выше встроенная справка уже не базируется на CHM файлах, поэтому в них мы можем со значительно меньшими последствиями просто блокировать hh.exe. Но тут можно упереться в вопрос совместимости сторонних приложений, которые зачастую содержат справку в CHM файлах. Поэтому, я не призываю блокировать hh.exe, но просто исследовать данный вопрос в каждом индивидуальном случае отдельно.

Примечание: на данный момент мне неизвестно о других расширениях, которые подвержены данной проблемы. Я тестировал набор расширений, но добиться подобного результата не удалось. Хочется надеяться, что это единственное такое хитрое расширение :)

3) унификация и стандартизация создания исключений в политику SRP. Прочитав топик на форуме TechNet – сслыка, я в очередной раз пришёл к мнению, что человек первый раз столкнувшись с SRP не обладает навыками эффективного создания исключений. Это и не удивительно вобщем, поэтому я в темах про SRP ставлю перед собой задачу – рассказать про Best Practices для эффективной реализации этой политики.

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

Политика SRP даёт нам широкие возможности для этого, это и использование системных переменных окружений %variable%, но и чтение этих переменных из реестра. Повторюсь, что данная концепция решает несколько задач, как унификация правил для различных платформ и обход локализованных барьеров. В качестве примеров можно привести различия некоторых стандартных путей в ОС Windows XP и Windows Vista.

  • Например, профили пользователей раньше хранились в C:\Documents and Settings, а в Vista – C:\Users. Уже здесь мы видим эффект от использования системных переменных окружения как %userprofile%.
  • Но если в сети используются и локализованные системы (смешанные), то системные переменные доставят нам хлопот, поскольку придётся часто дублировать исключения пути: %userprofile%\Desktop\*.lnk и %userprofile\Рабочий стол\*.lnk. Это так же существенный барьер, который обойти стандартными переменными окружения практически нерентабельным. И вот здесь мы видим эффект от чтения нужных путей из реестра.

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

  • пользователи могут запускать исполняемые файлы из системной папки Windows и Program Files
  • пользователи могут запускать ярлыки из своего пользовательского Start Menu
  • пользователи могут запускать ярлыки из Start Menu общего профиля, который известен как AllUsersProfile
  • пользователи могут запускать ярлыки со своего и AllUsers рабочего стола
  • пользователи могут запускать ярлыки из своего меню быстрого запуска (Quick Launch)
  • пользователи не могут запускать исполняемые файлы из папки спулера и системного Temp.

И вот такой список исключений нам потребуется:

Unrestricted - %systemroot%
Unrestricted - %programfiles%
Unrestricted - %userprofile%\Application Data\Microsoft\Internet Explorer\Quick Launch\*.lnk – (Windows XP/2003 only)
Unrestricted - %HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\AppData%/Microsoft/Internet Explorer/Quick Launch/*.lnk – (Windows Vista/2008 или выше)
Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Desktop%*.lnk
Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Programs%*.lnk
Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Programs%*/*.lnk
Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Programs%*/*/*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Administrative Tools%*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Desktop%*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs%*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs%*/*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs%*/*/*.lnk
Dissalowed - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers%
Dissalowed - %systemroot%\Temp

Здесь хочу сделать несколько комментариев:

  • Мы явно запрещаем запуск недозволенных приложений из системных папок, куда пользователи по умолчанию имеют право записи и исполнения. Это C:\Windows\Temp и папка спулера, поскольку они явно разрешаются первым правилом. Следовательно, чтобы предотвратить запуск файлов из этих папок мы явно их запрещаем отдельными правилами.
  • я указал 2 пути для QuickLaunch для систем Windows XP и Windows Vista. Это обусловленно тем, что в Windows XP/Windows Server 2003 максимальная длина исключения для пути ограничена 133 знаками и вот такой “финт ушами”, который я привёл для Windows Vista, не проходит. В новых ОС этот недостаток устранён.
  • здесь я не привёл явного запрещения для hh.exe, т.к. это стартовый набор правил, которое обеспечивает достаточную совместимость с другими приложениями.
  • Мы разрешаем несколько уровней вложения для Start Menu, поскольку всё это меню как правило состоит из 3-х уровней вложения.

Примечание: для бизнес-приложений, которые как правило инсталлируются на отличный от системного том (обычно D:\) и для них рекомендуется делать исключения по хешу, нежели по пути. Это полезно по двум причинам:

  • зачастую бизнес-приложения пишутся “быдлокодерами” (простите уж за такую лексику, но это суровая правда), которые требуют разрешения записи пользователям в папку с исполняемым модулем. Спастись от заражения этого модуля пользователями можно только хешем. Это, к сожалению, актуальная проблема, которую нужно решать примерно так: “разработчиков софта, требующего админских привилегий, нужно силой пересаживать на OpenBSD, и не кормить дошираком до тех пор, пока их г***ософт не начнет там работать в ANSi-режиме на библиотеке ncurses” © Amin
  • в случае, если случится факт заражения (в данном случае только от лица неосторожного администратора), то высока вероятность, что вирус постарается инфицировать все .exe файлы в системе и по изменившемуся хешу это можно быстро вычислить (приложение больше не запустится) и в кратчайшие сроки вывести поражённую систему из сети для дальнейшего расследования инцидента.

4) обновление ярлыков временного отключения и включения SRP. Я считаю удобным держать на рабочем столе администратора ярлыки, которые запускают REG файлы, которые в свою очередь временно отключают и возвращают политику в исходную позицию. Если для одной рабочей станции – это менее критично, то в условиях домена отключать политику для установки/обновления ПО на уровне GPO – крайне нецелесообразно. Я уже публиковал в своём предыдущем блоге тексты REG файлов, но без учёта папки Temp.

Т.к. мы явно запретили запуск недозволенных расширений из папки C:\Windows\Temp, то даже временная деактивация политики ярлыками не позволит нам сделать некоторые действия, например, установка драйвера или приложения, если установщик сперва распаковывает INF файлы в эту папку, поскольку перевод глобального режима политики в Unrestricted не отменит этот явный запрет. Следовательно мы помимо перевода политики в Unrestricted должны вывести администраторов из под действия политики. Вот REG файлы для временного отключения и включения политики:

SRP_Disable.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00040000
"PolicyScope"=dword:00000001

SRP_Enable.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00000000
"PolicyScope"=dword:00000000

5) обновление политики. В процессе работы с ярлыками обнаружился один неприятный факт: если отключить политику реестром и не включить обратно, то после перезагрузки машины кроме включения политики реестром обратно потребуется выполнить ещё 2 перезагрузки. Как вы, наверное, поняли, эти ключи реестра не изменяют саму политику, а только её поведение. Следовательно пришлось решать вопрос возвращения политики в исходное состояние при перезагрузках при помощи групповых политик. По умолчанию, политики перезаписывают соответствующие ключи реестра только при изменение состояния политики (чего мы ярылками не делаем). Т.к. SRP у нас основывается на реестре (все её правила и настройки хранятся именно в реестре), то нужно задать принудительное переприменение политики при перезагрузках (или периодических обновлений политики в домене). Делается это в Group Policy:

Computer Configuration\Administrative Templates\System\Group Policy\Registry policy processing

и этот элемент необходимо выставить в Enabled внутри поставить галочку в Process even if the Group Policy objects have not changed. В таком случае даже если администратор забудет реестром обратно включить политику SRP, то политика процессинга сама вернёт её в исходное состояние – Disallowed.

-------------------

Сегодня мы рассмотрели очередную партию насущных вопросов по настройке и управлению политикой Software Restriction Policies. Я недеюсь, что этот материал будет полезен как начинающим (тех, кто только начинает работать с политикой SRP) и опытным администраторам, которые уже используют политики SRP в своих сетях.

Security |  SRP
Tuesday, February 24, 2009 4:09:51 PM (FLE Standard Time, UTC+02:00)   Comments [8]    

 

Previous Page Page 2 of 3 in the SecuritySRP category Next Page
 · 

All content © 2008 - 2012, Vadims Podāns
"Spaces" Theme provided by: Vadims Podāns
About
Vadims Podāns


E-mail - Send mail to the author(s)
Live Messenger -
For english language visitors

Translate via Google Translator

My english blog

Библиотека

Ресурсы по PowerShell

Ресурсы по PKI

Календарик
<February 2012>
SunMonTueWedThuFriSat
2930311234
567891011
12131415161718
19202122232425
26272829123
45678910

Карта расположения посетителей
Favorites





Disclaimer
Вся информация на сайте предоставляется на условиях «как есть», без предоставления каких-либо гарантий и прав.

При использовании материалов c данного сайта ссылка на оригинальный источник обязательна.
Protected by Copyscape Online Plagiarism Scanner