Contents of this directory is archived and no longer updated.

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.

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


Share this article:

Comments:

sie

По пункту 1 - вы проверяли что перезапись переменных окружения (%systemroot%, %programfiles%, %userprofile%) приводит к обходу SRP? Вопрос у меня возник от того, что эти переменные создаются в сессии пользователя динамически при логоне, а SRP применяется при создании сессии, т.е. до того как пользователь получит возможность хоть что-то запустить. Если перезапись переменных окружения в сессии пользователя влечет за собой изменение поведения SRP, то это означает что SRP применяется не при создании сессии пользователя, а постоянно "перевычисляется". Где правда? :-)

Vadims Podāns

Илья, вы совершенно правы! Но этот трюк работает не совсем так, как вы подумали. Как это делается: 1) создаём дефолтную политику и выставляем дефолтный уровень в Disallowed 2) в Additional Rules делаем правило пути: %systemroot% - Unrestricted 3) копируем на рабочий стол любой .EXE файл 4) запускаем CMD: Start -> Run... -> cmd 5) в консоли пишем: set systemroot=c:\ 6) пишем desktop\file.exe файл запустится! Но по двойному клику или из другой сессии CMD файл не запустится, поскольку там %systemroot% будет показывать на папку Windows, а не C:\ или вы считаете, что этот способ тоже стоило описать в посте?

Vadims Podāns

хочу сделать одну заметку. Данный фокус не прокатит, если вы в этой же консоли CMD насильно инициируете блокировку. Т.е.: -------------------------------------------------------------- Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. C:\Documents and Settings\Administrator>echo %systemroot% C:\WINDOWS C:\Documents and Settings\Administrator>desktop\NOTEPAD.EXE The system cannot execute the specified program. C:\Documents and Settings\Administrator>set systemroot=c:\ C:\Documents and Settings\Administrator>echo %systemroot% c:\ C:\Documents and Settings\Administrator>desktop\NOTEPAD.EXE The system cannot execute the specified program. C:\Documents and Settings\Administrator> -------------------------------------------------------------- это не сработает а вот такой сценарий: -------------------------------------------------------------- Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. C:\Documents and Settings\Administrator>echo %systemroot% C:\WINDOWS C:\Documents and Settings\Administrator>set systemroot=c:\ C:\Documents and Settings\Administrator>echo %systemroot% c:\ C:\Documents and Settings\Administrator>desktop\NOTEPAD.EXE C:\Documents and Settings\Administrator>set systemroot=C:\Windows C:\Documents and Settings\Administrator>echo %systemroot% C:\Windows C:\Documents and Settings\Administrator>desktop\NOTEPAD.EXE C:\Documents and Settings\Administrator> -------------------------------------------------------------- сработает вполне. Причём, обратите внимание, что я потом вернул путь переменной обратно на папку Windows и блокировка не исчезает и блокнот запускается дальше. Он перестанет запускаться только, когда сынициируете блокировку политики.

Vadims Podāns

> вернул путь переменной обратно на папку Windows и блокировка не исчезает последнее слово должно быть "не появляется".

www.google.com/accounts/o8/id?id=AItOawl8J2I2K6pJwBlLcqkefALp4qNBCQ_Stlk

Спасибо за статью. "SRP бессмысленна с обработкой расширения LNK, поскольку тут таится другая угроза. Я думаю, что многие смотрели на эти исключения, но не видели лазейки." W2K8 научилась распознавать .lnk, вернее то, где находится запускаемый из ярлыка файл и, если этот файл подпадает под политики разрешения, позволяет запускать его. Т.е. теперь не надо задавать исключения для папок содержащих .lnk (например - рабочего стола). Еще хороша SRP вместе с политикой "Run only specified Windows applications", к примеру: в случае когда нужно запускать пользовательские логон скрипты, приходится давать права для запуска wscript.exe, что позволяет запускать скрипты откуда угодно, но с SRP можно это ограничить.

Vadims Podāns

Распознавать ярлыки умеют все системы начиная от Windows XP SP2. Поэтому рекомендация сейчас простая — отключить проверку LNK совсем. > приходится давать права для запуска wscript.exe, что позволяет запускать скрипты откуда угодно это не так. Сам запускаемый файл (.vbs, .wsf) должен подпадать под явное разрешение в политике, поэтому политикой "Run only specified Windows applications" пользоваться не обязательно.

dmc

1. По второму пункту, пока разбирались с мухами, не заметили слона: c:\>copy c:\test\program.exe %systemroot%\tasks Скопировано файлов: 1 c:\>%systemroot%\tasks\program.exe 2. В червертом пункте логично вместо %systemroot%\Temp использовать %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%Temp. Ведь все полисы доступны пользователю на чтение и при желании он об этом узнает и воспользуется.

Vadims Podāns

1) угу, спасибо за дополнение. Но на этот счёт есть пункт 2, который через cacls выставляет пользователям Read-only на Tasks. В принципе, я сейчас делаю проще: разрешаю .exe в папках Windows, System32 и ещё в необходимых подпапках. Это решение скорее всего будет более эффективным, чем раздавать запреты на папки, в которые пользователь может писать. Есть ещё папка %SystemRoot%\Debug\WPD (или WIA), где пользователи имеют право Modify! 2) > В червертом пункте логично вместо %systemroot%\Temp использовать %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%Temp а это бессысленно. Потому что мы ставим запрет, а не разрешение. Поэтому толку от того, что он может прочитать — примерно ноль.

dmc

Пользователь изменит %systemroot% на c:\111, по идее это правило запрета должно действовать на папку c:\111\temp, а на папку windows\temp запрет должен исчезнуть и действовать разрешение %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%. Но мне действительно не удалось запустить файл, где подвох не разобраться.

Vadims Podāns

Сейчас проверил у себя на Windows 7. Всё-таки работает этот трюк. Перенаправляем запрет куда-то в сторону и файлы запускаются. Сейчас поправлю пост.

shs

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers% здесь, наверное, опечатка. IMHO, должно быть так: %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\DefaultSpoolDirectory%

Egor

Существует способ устранения уязвимости с папками, назваными folder.lnk. К примеру вы разрешили запуск ярлыков на рабочем столе следующим правилом: %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Desktop%*.lnk Для того, чтобы запретить выполнение приложений в папках на рабочем столе, названных по типу folder.lnk, необходимо создать следующее запрещающее правило: %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Desktop%*.lnk/*

Vadims Podāns

Да, достаточно удалить LNK из списка расширений, которые контролирует SRP.

Egor

Ещё одна непонятная проблема. Имеется сервер SBS2008, на основе которого развёрнут домен. В домене есть клиентские машины с ОС XP. Создаю тестовую групповую политику, которая применяется только к конкретной тестовой машине XP SP3. Создаю правило, разрешающее запуск определённого приложения по хэшу. Правило на клиентской машине не отрабатывает. Такое чувство, что хэши под разными ОС не совпадают, используются разные алгоритмы. Есть какие-нибудь идеи, как этот глюк можно обойти?

Михаил

С учетом поправок какой список исключений на Ваш взгляд теперь должен быть-стандартным набором разрешений

Vadims Podāns

Я на днях напишу отдельный пост.

Михаил

СПАСИБО с нетерпением ожидаем !!

Михаил

Вадами отдельный пост Вы обещали , не пропустил ли я его ?

Vadims Podāns

Нет, не пропустили. Просто мне сейчас немного не до этого. Будет время — напишу. Если вы читаете RSS, значит, не пропустите.

Михаил

Читаю конечно . СПАСИБО

Михаил

Вадим публка с нетерпением ждет :-) Cтандартным набором разрешений обещанный Вами

Comments are closed.