В последнее время мне всё чаще стали задавать вопрос, что выбрать, AppLocker или старый добрый SRP?

Казалось бы, что тут думать — AppLocker и точка. Многие, наверное, помнят пиар-акцию под названием «Windows 7 + 1», которую проводили многие MVP для рекламы новых технологий Windows 7. И весьма досадно то, что некоторые MVP вместо раскрытия реальной объективности новых технологий распространяли просто маркетинговый булшит и даже подтасовывали факты. Например статья Владимира Безмалого про AppLocker:

• AppLocker как средство обеспечения информационной безопасности
• AppLocker Часть 2

Этот вариант статьи можно ещё прочитать и здесь: http://www.osp.ru/win2000/2009/09/10721226/. Моё внимание обратила на себя табличка сравнения SRP и AppLocker. Вот она с моими комментариями:

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

На счёт мастера создания правил я немного не понял. В принципе, окно создания правила в SRP тоже своего рода мастер. Только одношаговый, в отличии от AppLocker.

А сообщения об ошибках в SRP были тоже. Как в виде диалогоых окон, так и в журнале Application в эвентлоге. Т.е. тут у меня 2 мнения — либо человек не работал с SRP, либо намеренно исказил факты, чтобы подкрутить популярность AppLocker'а, поскольку революции AppLocker не совершил. Ведь с появлением AppLocker мы приобрели не только удобный интерфейс, но и потеряли несколько полезных вещей, которые есть в SRP. Как я уже отмечал ранее, мы потеряли возможность самостоятельно регулировать список контролируемых расширений файлов и потеряли возможность фильтрования файлов по конкретным сертификатам. Новое правило издателя позволяет контролировать версию разрешённого приложения, но не отличает каким сертификатом подписано приложение. Да и применимость издателей такая же как и у классических правил сертификатов — т.е. низкая. К сожалению я не могу вспомнить ни одно бизнес-приложение (не стандартные приложения типа Microsoft Office), которое бы было подписано. Плюс невозможность использования системных переменных окружения так же усложняет создание правил в доменной среде. Эту табличку можно переделать в такой вид:

	SRP	AppLocker
Применение правил	Все пользователи	Определённые группы и пользователи
Уровень по умолчанию	Unrestricted	Deny
Разрешающее действие
Запрещающее действие
Особое действие
Правила сертификатов
Правила издателей
Правила хешей
Правила сетевой зоны
Правила пути
Системные переменные окружения
Собственные переменные окружения
Пути из реестра
Режим аудита
Группировка правил
Мастер создания правил
Импорт/экспорт политик
Поддержка PowerShell
Сообщения об ошибках
Настраиваемый список расширений

Мы видим, что преимущество AppLocker перед SRP резко переходит на нет. Я не хочу сказать, что AppLocker — отстой, а лишь хочу показать, что реализация этой технологии не на столько крутая, что её стоит пиарить как революцию.

Из блога Владимира Безмалого:

В Windows 7 SRP также могут применяться, однако все чаще будет использоваться AppLocker. Почему?

К сожалению этого не случится, во всяком случае в цикле Windows 7. Как уже отмечалось, наиболее значительное изменение в AppLocker — это новый простой, удобный и понятный интерфейс, чего в SRP не было. В значительной степени из-за этого SRP на домашних компьютерах применялся лишь в единичных случаях. Сейчас же применить AppLocker гораздо проще на домашних системах при получении одинаково эффективного результата. Но Microsoft слишком жадный и включил эту технологию только в Windows 7 Ultimate и Enterprise. Я верю, что от появления SRP в домашних редакциях Windows 7 количество применений SRP на них не увеличится совсем. Учитывая, что с ноутбуками будет чаще всего проинсталлирована какая-то домашняя редакция Windows 7, то профита от AppLocker они не получат тоже. Но если дома есть возможность использовать AppLocker и вы хотите получить адекватный уровень защиты от запуска случайных файлов — используйте AppLocker. Хотя, скажите, кто из вас, кроме меня, использует Windows 7 Ultimate/Enterprise дома и использует AppLocker?

Если вы будете иметь возможность перевести часть парка машин предприятия на Windows 7 Enterprise, то вопрос использования AppLocker может сложиться не в его пользу. Это обусловлено тем, что если у вас уже используется SRP, то вам AppLocker не будет нужен до тех пор, пока весь парк не будет переведён на Windows 7 Enterprise. Ведь с AppLocker вы ощутимых бенефитов не получите в плане безопасности, но сразу усложните себе жизнь тем, что вам придётся поддерживать гораздо больше политик — SRP и AppLocker. При необходимости поддерживать клиентов отличных от Windows 7 Enterprise лучше использовать то, что может охватить наиболее число машин — SRP.

Внимать моим рекомендациям — личное дело каждого, просто я отразил своё видение проблематики. Вобщем, я не верю в массовое светлое будущее AppLocker по крайней мере до выхода следующей версии Windows, даже не смотря на активный и нечестный пиар технологии со стороны Microsoft (что вполне нормально для самого создателя) и прочих пиарщиков. Но начинать его использование по мере возможности — очень даже можно и нужно, т.к. однажды SRP просто не окажется в релизе ОС.

Вот и пришло время сделать сводный пост по своим исследованиям Software Restriction Policies. Здесь я опубликую ссылки на предыдущие материалы, посвящённые этой действительно интересной технологии. К сожалению это скорее всего будет означать завершение срывов покровов в этом направлении. Безусловно, технологии не стоят на месте, а постоянно развиваются, поэтому очень долго топтаться на одном месте не стоит. Но это совсем не означает, что SRP стал реликвией, музейным экспонатом и просто утилем. SRP до сих пор имеет и какое-то время будет иметь важное значение в обеспечении безопасности ОС Windows, поскольку теперь политики SRP поставляются во все домашние редакции Windows 7. А так же будет неотъемлемой частью обеспечения безопасности уже активно используемых систем начиная с Windows XP.

И, собственно, сам список.

• На страже безопасности – Software Restriction Policies

Опубликованная в журнале «Системный администратор» статья даст представление о том, что такое SRP, поведает о ключевых особенностях этих политик и может выступать в качестве теоретической базы для работы с SRP.

• Секреты Software Restriction Policies

Первая часть исправлений к журнальной статье, в которой рассказывается про особенности использования прямых «/» и обратных «\» слешей в правилах пути, а так же про обход политик через системные папки, которые разрешены пользователям для записи.

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

В этой части рассказаны методы обхода SRP на примере запуска CHM файлов и потенциальной возможности запуска некоторого кода с использованием файлов с расширением SCF. Плюс даны некоторые рекомендации по организации правил для типовой рабочей станции и косметические настройки обработки групповых политик в отношении SRP.

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

Очередной обзор нескольких способов обхода политик SRP путём подмены системных переменных окружения, использованием в обработке расширений LNK и подстановкой нелегитимных доверенных издателей (цифровых подписей). Так же приведён потенциальный полувандалистский метод атаки на SRP путём генерации зашедуленного задания в ожидании, когда политика будет отключена в профилактических целях.

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

В этом посте детально рассказано о непростом порядке сортировки и применения множества правил SRP. Используя этот материал вы научитесь разрешать конфликты в правилах и упростит планирование правил SRP.

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

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

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

содержит официальное заявления сотрудника техподдежки Microsoft — Rahul Denkanikota. В результате двухмесячного общения с техподдержкой мне лично была предложена замена для mshta.exe, которая уже лишена недостатка оригинального файла. Однако, данное решение не планируется выпускать в массы по причине очень большой специфики. В остальных же случаях, если это возможно, следует полностью отказаться от mshta.exe и заблокировать его на уровне правил SRP.

• Защищаем Software Restriction Policies

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

Вот и всё…

Одной из самых больших проблем с 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 рулит!

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