Безопасность Windows путем формирования белых списков ПО

Intro

Одним из базовых принципов обеспечения ИБ в любой системе является принцип минимума полномочий и минимизации программ разрешенных к запуску (в т.ч. скриптов, апплетов, активных компонентов и т.д.) В различных СЗИ таких как SecretNet, Панцырь, Страж NT, Dallas Lock, DeviceLock обязательной частью функционала идет возможность форматировать белые листы ПО разрешенного к исполнению на защищаемой машине. Переоценить такую фичу вряд ли возможно, ведь она очень сильно выручает на тех системах, где осуществляется массовый публичный доступ (библиотеки, аэропорты и гостиницы, почта) или самообслуживание (АТМ и т.д.). А в корпоративном секторе software white listining находит активное применение на машинах предназначенных для проведения финансовых операций (системы ДБО и банк-клиент).

Еще со времен Windows XP в стандартный набор системы входил такой инструмент как Software Restriction Policies, позволявший админам оградить машину от запуска любого потенциально опасного ПО, в первую очередь вирусов и различных вредоносных скриптом, spyware, adware-компонентов. В последних версиях ОС от Microfost появился новый инструмент под именем AppLocker отличающийся от SRP и предлагающий более продвинутые возможности.

Конечно AppLocker не панацея от всех бед, но учитывая, что он идет "из коробки" и в отличии от сторонних СЗИ не требует дополнительных затрат на лицензию, технология очень не плохо выручает в оговоренных выше ситуациях.

Software Restriction Policies как предок AppLocker

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

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

Как работает Software Restriction Policies?

С помощью SRP можно создать “белый список” программ, которые заведомо разрешены для запуска; все остальные программы будут заблокированы. Например, мы говорим системе “запускай всё из папок C:\Windows, C:\Program Files, а остальное не разрешается”. В результате, приезжающий на флешке вирус тихо «обламывается», не сумев запуститься с неразрешённого пути E:\ или Z:\.

Что-то попыталось пролезть с ненадёжного веб-сайта? Оно тоже не запустится, так как было сохранено в папке профиля пользователя Temporary Internet Files или %Temp%. А мы оттуда ничего запускать не разрешали! Присланный посредством Skype «новый супер-пупер скринсейвер», на самом деле представляющий собой троянскую программу, тоже не запустится.

Политика Software Restriction Policies сильно выигрывает в сравнении с любыми тормозяще-навороченными, но в то же время очень ненадёжными антивирусными программами, будь то Kaspersky, NOD или Avast (название и производитель не имеют значения). К сожалению, никакие системы из серии Windows Home не поддерживаются.

Политики ограничения основанные на групповых политиках

Администраторы могут использовать SRP для определения того, каким приложениям разрешено/запрещено выполняться на целевом компьютере. Для профилактики проблемы выполнения неизвестного кода, администраторы могут использовать SRP для следующих задач:

• Борьба с компьютерными вирусами
• Регулирование ActiveX
• Выполнение только подписанных скриптов
• Запуск только подтвержденных приложений
• Создание строго ограниченной конфигурации для компьютера

Чуть чуть об удобстве для администрирования

Иногда вам придётся устанавливать новые программы, а также обновлять их и саму систему. Для этого политику SRP нужно временно отключать. Создайте два файла, которые помогут вам облегчить отключение/включение SRP, и сохраните их в папке Windows:

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers] "DefaultLevel"=dword:00040000 S

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers] "DefaultLevel"=dword:00000000

На самом деле, значение DefaultLevel не отключает политику, а переводит её из режима «белого списка» Default: Disallowed в режим «чёрного списка» Default: Unrestricted, разрешая запуск любых программ, кроме тех, что описаны в контейнере Additional Rules в режиме Disallowed.

По возможности, не создавайте записи с типом доступа Disallowed, так как это осложняет работу с политикой. Создайте ярлыки на reg-файлы на рабочем столе Администратора. Процедура установки новых программ усложняется лишь ненамного по сравнению с тем, как вы привыкли это делать:

отключаем защиту SRP ярлыком SRP Disable;

инсталлируем программу или выполняем обновление системы;

снова включаем SRP ярлыком SRP Enable.

Дополнительное чтиво

Подробно с картинками о настойке SRP на системах Windows

Блокировка вирусов и шифровальщиков с помощью Software Restriction Policies

Встречайте AppLocker!

И так в нескольких абзацах что такое AppLocker? По сути это следующая стадия эволюции хорошо знакомой нам политики Software Restriction Policies, который доступен в операционных системах начиная с Windows 7 (редакции Ultimate и Enterprise) и Windows Server 2008 R2. Безусловно, политики SRP остались в этих ОС в качестве совместимости.

Прежде всего, чтобы как-то начать с ним работать следует включить и запустить службу Application Identity. Чтобы добраться до самой политики AppLockerнужно запустить редактор групповой политики и развернуть его в секции Computer Configuration. Если это изолированная рабочая станция, то просто Start –> Run… –> secpol.msc. И мы увидим примерно такое окно:

Здесь мы видим деление на 3 категории:

1. Executable Rules – содержит правила для файлов с расширениями COM, SCR и EXE;
2. Windows Installer Rules – содержит правила для файлов с расширениями MSI и MSP;
3. Script Rules – содержит правила для файлов с расширениями BAT, CMD, JS, PS1 и VBS.

Вот такого разделения весьма не хватало в политиках SRP, где всё было в кучу, теперь всё сгруппировано по категориям. Однако, в AppLocker нету возможности управлять расширениями, в отличии от SRP (где можно было редактировать окно Designated File Types), что является первой точкой возможнного ослабления защиты.

Создаём свои первые правила

По умолчанию в консоли никаких правил нету (в отличии от SRP, где основные правила исключений уже были). Чтобы создать правила по умолчанию нужно выбрать нужную категорию и правой кнопкой мышки выбрать Create Default Rules. И тогда появится 3 правила по умолчанию (и так будет в каждой категории):

1. Allow Everyone all files in Windows directory;
2. Allow Everyone all files in ProgramFiles directory;
3. Allow BUILTIN\Administrator all files.

Тут всё понятно – это аналог дефолтных правил в SRP с добавлением того, что администратор может запускать что угодно. Но я буду рекомендовать удалять последнее правило из каждой категории, которое позволяет администраторам запускать всё что угодно (а случай работы с полностью отключенным UAC я даже обсуждать не хочу). Мы ведь помним, что в 99% случаев всех заражений виноват именно локальный администратор.

Примечание: понятие BUILTIN\Administrators здесь трактуется как использование приложений в привелигированном режиме (elevated mode). При обычном запуске приложений на администратора распространяются только первые 2 правила.

На этом этапе мы видим кардинальное перерождение уровня Basic User в новый формат. Basic User в SRP позволял запускать файлы в обычном режиме и запрещал запускать приложения в elevated mode. Здесь же этот функционал работает с точностью до наоборот. Задание исключений для группы BUILTIN\Administrators не позволяет нам запускать приложения в обычном режиме, но разрешает их запуск в elevated mode. И ярковыраженного Basic User больше нету.

Уже из скриншота видно, что мы можем как-то разделять правила по группам пользователей. Этого, кстати, тоже не хватало в SRP. Теперь мы имеем возможность разделять правила для различных пользователей даже на уровне одной изолированной от домена рабочей станции. Это решает сразу 2 проблемы, которые были в SRP:

• нету необходимости в неудобном переключателе между режимом применения политики (для всех пользователей, кроме администраторов или для всех пользователей без исключения) в окне Enforcement.
• нету необходимости редактировать политики в нескольких местах. Т.е. в отличии от SRP, AppLocker уже не имеет настроек в секции User Configuration. Это упрощает процесс создания и внедрения политик на уровне домена, не требуя от администратора досконального знания, как политики из разных разделов GPO будут вести себя в случае конфликтов. Хотя, это знать полезно.

Как только мы создали правила, AppLocker уже начинает работать. Это довольно-таки спорный момент. В SRP у нас было отдельная секция, где мы задавали уровень по умолчанию, а в AppLocker этого уже нету. Каждая категория начинает работать в момент, когда создано хоть одно правило. Тогда работа идёт в строгом соответствии с этими правилами (даже если оно одно). Если удалить все правила из конкретной категории, то политика для данной категории отключается и конкретные типы файлов можно запускать без ограничений. Если сравнить с SRP, то мы так же помним, что политики SRP не экспортируются никак! Т.е. мы не можем их переносить между компьютерами, бэкапить на уровне локальной рабочей станции. Поэтому для предотвращения потери конфигурации и правил в SRP был введён переключатель режима. AppLocker в этом плане немного изменился – мы имеем возможность экспорта настроек и правил политики. Для этого нужно выставить курсор на секцию AppLocker и правой кнопкой мышки выбрать Export Policy. К счастью, политики экспортируются в читабельный XML файл, а не в бинарный мусор (как в случае с экспортом правил IPSec). Для полного отключения политики, там же после экспорта выбрать Clear Policy. Т.е. для временного отключения AppLocker мы сначала эксортируем настройки и правила, очищаем политику и работаем. Когда работу закончили – импортируем политику и мы снова под колпаком. SRP поддерживал возможность временного отключения политики на конкретной рабочей станции через реестр. Теперь мы такого функционала лишены, хотя с возможностью экспорта это не сильно и нужно нам. Ну и, повторюсь, AppLocker работает только в режиме белого списка.

Группировка правил

Оснастка AppLocker Microsoft Management Console (MMC) содержит четыре раздела правил:

• исполняемые файлы;
• сценарии;
• файлы Windows Installer;
• файлы DLL.

Такая организация правил позволяет администратору дифференцировать правила по типам приложений. В таблице 2 приведено соответствие между разделами правил и форматами файлов.

Основные изменения в правилах

А теперь уже конкретно по правилам. В SRP у нас была возможность создавать 4 типа правила: Certificate, Hash, Network Zone, Path. Как и ожидалось, Network Zone не смог найти себе места в этих политиках, поэтому в AppLocker этот тип удалён и остаётся только 3: Publisher (бывший Certificate rule), Hash, Path с такой же приоритезацией. Правила издателя (Publisher) и пути (Path) несколько изменились в своей сути. Начнём с правила пути.

Изменения в правилах пути

Если вспомнить SRP, то там мы могли использовать абсолютные пути, переменные окружения (но на самом деле оказалось, что это очень опасно), подстановочные знаки и чтение путей из реестра. В AppLocker мы можем использовать только абсолютные пути и специальные переменные окружения. Вот таблица (взята из встроенной в Windows справки):

 Мы в правилах можем использовать только переменные, которые указаны во второй колонке. Мы лишены возможности использовать другие переменные как %temp%, %logonserver% и др. Но, в то же время, мы можем использовать в правилах переменные для обозначения CD/DVD приводов и съёмных накопителей (просто флешки). Здесь следует учесть, что эти переменные не являются переменными окружения Windows, а внутренние для AppLocker, даже не смотря на совпадение в синтаксисе. Это ещё сильнее утвердило во мне мысль, что Microsoft знал про баг с переменными окружения в Windows и сейчас уже подмена переменных ничего не даёт совсем для обхода запретов политики. Вобщем, тут мы немного потеряли (переменные окружения и чтение путей из реестра), но, в то же время, приобрели защиту от подмены переменных окружения и получили перменные для съёмных дисков и CD/DVD приводов.

Изменения в правилах издателя (Publisher rule)

Это по сути ребрендинг правил сертификатов (Certificate Rule). Тут изменения более глобальные. И так же, частично в лучшую сторону и частично в обратную. Когда вы делаете правило издателя сертификата, то вы указываете на файл, который содержит цифровую подпись и всё. Политика сама извлечёт из файла цифровую подпись и прикрутит издателя к правилу. Вот как это выглядит вживую:

Если говорить про версии файлов, то мы видим (правда, затенённое) поле с раскрывающимся списком, где мы можем задавать как точное совпадение версии (Exact match), так и сравнительную версию – только текущая и более новые версии (And above) или только текущая и более старые версии (And below).

Здесь, в отличии от SRP уже не используется внутренний в Windows механизм Trusted Publishers, который использовался в SRP, поэтому подсовывание сертификатов в этот контейнер ничем нам не поможет, как я уже демонстрировал в случае с SRP.

Исключения из правил

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

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

Примечание: не забывайте, что в Windows 7 и Windows Server 2008 R2 системный темп всё так же разрешён на запись пользователям и подпадает под дефолтные ращрешающие правила. Поэтому, если вы ещё их не перенесли в другое место, вы должны в правилах папки Windows должны включить исключения на папку Temp и папку спулера печати.

Обход правил AppLocker'а

Как уже писалось ранее AppLocker не серебренная пуля и имеет недостатки\уязвимости, которые позволяют обойти ограничения на запуск ПО.

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

Скрипты для обхода AppLocker через Regsvr32 размещены автором на GitHub, ознакомиться с ними можно здесь.

По информации engadget, компания Microsoft пока никаких официальных комментариев по этому вопросу не предоставила, поэтому неизвестно, будет ли «лататься» патчем данная уязвимость или нет. 

С другой стороны проблему обхода AppLocker можно решить весьма простым способом: заблокировать Regsvr32 в брандмауэре системы, исключив, таким образом, внешнее обращение к нему по Сети. Еще одним решением называется включение правил для DLL, которые по умолчанию отключены из-за просадок производительности.

Также существует еще несколько способов обхода AppLocker, упомянутых в комментариях пользователем navion: раз и два.

Windows 10: How to bypass Applocker with default rules

Bypass AppLocker Default Rules Windows 10

Полный гайд с картинками по взлому AppLocker доступен здесь:

How To Bypass Windows AppLocker