Ничего не предвещало беды в прошлый «вторник обновлений» (14 июня): бюллетень обновлений содержал лишь сухой список важных обновлений безопасности и стандартные рекомендации по их немедленной установке. Однако, после применения обновлений, системные администраторы по всему миру столкнулись со странным поведением политик безопасности. Наиболее распространённый симптом: начали «отваливаться» сетевые принтеры и папки.
Те, кто следовал лучшим практикам распространения обновлений, заметили, что такое поведение наблюдалось только в тестовой группе, обновления для которой были приняты до распространения их по всей организации.
При попытке разобраться в ситуации, результат GPRESULT поверг в некоторое замешательство: некоторые политики безопасности уровня пользователя (user scope) не применялись, выдавая весьма «информативное» сообщение: «Filtering: Not Applied (Unknown Reason)». Некоторые новые политики просто не появлялись в выводе GPRESULT.
Кто виноват?
«Виновником» такого поведения стало обновление безопасности из статьи KB3163622 (бюллетень безопасности MS16-072, номер KB для различных ОС: KB3159398, KB3163017, KB3163018, KB3163016), призванное закрыть дыру в безопасности процесса применения групповых политик. С момента появления технологии групповых политик не было уделено должное внимание обеспечению доверенности источника политик. Атакующий, применяя тактику MitM (Man in the Middle — атака посредника), мог подменить ответ от контроллеров домена и прислать на атакуемый компьютер поддельные политики безопасности, дающие, например, права локального администратора скомпрометированной учётной записи рядового пользователя.
Как оказалось, для устранения данной проблемы программисты Microsoft не нашли ничего лучше, чем изменить поведение процесса применения групповых политик, которое не менялось со времени выхода Windows 2000. Традиционное поведение предусматривало доступ к политикам безопасности уровня компьютеров (computer scope) от учётной записи компьютера, а к политикам безопасности уровня пользователя (user scope) — от учётной записи пользователя. После установки обновления KB3163622 все запросы стали направляться от учётной записи компьютера, чтобы обеспечить доверенность источника силами протокола Kerberos.
Тестирование обновления (если таковое вообще проводилось) не выявило никаких проблем, так как по умолчанию доступ ко всем групповым политикам разрешён для группы Authenticated Users, которая включает в себя все учетные записи (компьютеров и пользователей).
В реальных условиях эксплуатации системные администраторы ограничивают распространение многих политик с применением простого и наглядного механизма фильтров безопасности (security filtering), а также непосредственной модификации настроек доступа к некоторым политикам. Следует отметить, что модификация списков контроля доступа к политикам является штатным инструментом настройки политик и не может быть поводом для обвинения системных администраторов в создании нестандартной ситуации.
Список фильтров безопасности (security filtering)
В результате, на Microsoft полился поток жалоб, а форумы запестрели скороспелыми рекомендациями отменить (decline) обновление KB3163622 в WSUS. Ситуация, к сожалению, стала не редкостью в последние годы, когда чуть ли не каждый месяц некоторые обновления выходят повторно в новой редакции после негативной реакции пользователей. В этот раз, однако, Microsoft дала понять, что не пойдёт на попятную и к новым правилам применения политик безопасности придётся привыкнуть.
15 июня в бюллетень MS16-072 добавили короткое указание, что, как говорится, «это не баг, это — фича», и такое изменение поведения будет сохранено.
Сотрудник Microsoft Ian Farr 16 июня опубликовал скрипт на PowerShell, который позволяет системным администраторам проверить, повлияет ли новое обновление на существующие политики.
На протяжении недели на специализированных ресурсах кипели страсти, так как кроме трех строчек в бюллетене безопасности никакой официальной информации от Microsoft не поступало. Наконец, через 9 дней после выхода обновления, в официальном блоге Ask the Directory Services Team вышла подробная статья, которая, по хорошему, должна была если не предварять выпуск обновления (пусть, по соображениям безопасности, до выхода «заплатки» нельзя раскрывать суть уязвимости), то уж по крайней мере идти первой строкой в июньском бюллетене.
Что делать?
TL;DR: Ниже приведена Инструкция по внесению изменений в GPO и AD для предотвращения ущерба от установки этого обновления.
При всём уважении к AD DS Team, мне кажется, что решение, которое они предлагают — добавить Authenticated Users или Domain Computers с доступом только для чтения во все политики, которые перестали работать, — является полумерой. При модификации или создании новых политик безопасности отныне и навсегда нужно будет помнить о необходимости добавлять одну из вышеупомянутых групп. Наглядный инструмент фильтров безопасности (security filtering), доступный прямо на первой странице редактора политик безопасности (group policy editor) вообще теряет всякий смысл, так как всё равно необходимо вручную изменять списки контроля доступа.
Более простым в эксплуатации мне представляется следующее решение: добавить группу Domain Computers с правами только на чтение (но не на применение) во все политики (если это возможно по соображениям безопасности), а также произвести минимальную модификацию схемы (schema) AD, чтобы новые политики создавались сразу с необходимыми правами.
Плюсом такого решения является отсутствие необходимости его поддержки: поведение групповых политик практически не изменится, нет необходимости менять правила создания/модификации политик. Продолжит работать и механизм фильтров безопасности (security filters), который очень наглядно позволяет представлять и редактировать параметры доступа к политикам.
Минусом является необходимость модификации схемы (schema) AD, но модификация настолько тривиальная, что она не должна вызвать никаких проблем.
Почему я предлагаю добавить Domain Computers, а не Authenticated Users? Во-первых, для того, чтобы не нарушать Принцип минимальных привилегий: даже после такого надругательства над этим принципом, которое совершает данное обновление, мы всё ещё можем не дать непривилегированному пользователю читать политики, которые применяются к привилегированным пользователям простым заходом в SYSVOL. Во-вторых, по умолчанию Authenticated Users уже имеют права на чтение и применение политики. Удаляя Authenticated Users из списка фильтров безопасности (security filtering) мы удаляем не только права на применение, но и права на чтение. В то же время, если группа Domain Computers добавлена в списки доступа только для чтения, она не отображается в списке security filtering и не будет удалена.
Соображения по применимости данных рекомендаций
Для начала я рекомендую изучить список групповых политик в вашем домене, которые будут непосредственно задеты изменением поведения. В этом поможет скрипт с TechNet или одна из его модификаций, в последние дни опубликованных в различных блогах. Необходимо понять, какова была цель изменения настроек безопасности. Мне представляется такой список наиболее очевидных целей:
1. Вторичное ограничение доступа к ресурсу. Например, доступ к сетевому принтеру ограничен группой Example1 в настройках безопасности самого принтера и, дополнительно, политика безопасности, которая подключает этот принтер, применяется только к членам группы Example1. В такой ситуации добавление прав на чтение (но не применение политик) для Domain Computers совершенно безопасно.
2. Ограничение распространения информации, которая содержится в самой политике безопасности. Я не рекомендовал бы хранить уязвимые (sensitive) данные (например, пароли) в политиках безопасности, но, допускаю, что до прошлой недели такой подход имел право на существование, так как доступ к файлам политики безопасности в общей папке SYSVOL автоматически ограничивается списком доступа, применённым к самой политике. После изменений, которые приносит обновление, доступ вынужденно получат учётные записи всех компьютеров. Обратиться к папке SYSVOL от имени компьютера всё ещё не самая тривиальная задача для пользователя с ограниченными правами, но, потенциально, это возможно (например, с применением отдельной уязвимости локального повышения привилегий). Прежде чем переходить к следующим пунктам инструкции, следует взвесить потенциальные риски, и, возможно, убрать уязвимую (sensitive) информацию из политики безопасности.
2a. В условиях повышенных требований к безопасности, согласно Принципу минимальных привилегий, доступ по умолчанию для Authenticated Users может быть заменён на более узкий для всех политик безопасности. В таком случае, необходим полный пересмотр всей стратегии защиты политик. Для политик уровня пользователя (user scope) попытка сузить круг доступа теперь неминуемо приведёт к нарушению постулата о разделения пользовательских и компьютерных политик безопасности. Например, попытка ограничить распространение политики, применимой только к привилегированным пользователям, группой компьютеров, на которых эти пользователи работают, приведёт к фактическому смешению уровней политик (user and computer scope), что не является хорошей практикой.
Инструкция
После того, как вы приняли решение о применимости предлагаемого подхода (см. предыдущий раздел), необходимо запустить PowerShell с правами доменного администратора или иной учетной записи, имеющей полный доступ ко всем политикам безопасности и ввести следующую команду:
Get-GPO -All | Set-GPPermissions -TargetType Group -TargetName "Domain Computers" -PermissionLevel GpoRead
Данная команда добавит права на чтения (но не применение) политик для группы Domain Computers во все политики безопасности домена. После её выполнения можно смело устанавливать обновление KB3163622, для существующих политик безопасности оно больше не страшно.
Предупреждение. Следующим шагом является изменение схемы (schema) AD для того, чтобы вновь создаваемые политики уже имели разрешение для чтения политики группой Domain Computers в своём списке контроля доступа. Хотя изменение минимально, я хотел бы посоветовать тем администраторам, которые не знают, что такое схема (schema) AD, сперва изучить данное понятие либо ограничиться предыдущим пунктом инструкции и добавлять Domain Computers в новые политики вручную, либо запускать вышеупомянутую команду PowerShell (или её модификацию с заменой «-All» на имя политики) после создания каждой новой политики безопасности.
Дальнейшая инструкция является вольным переводом статьи Darren Mar-Elia.
Проверьте, что у вас есть достаточный уровень доступа для проведения следующих операций. Вы должны входить в состав (напрямую или косвенно) группы Schema Admins.
1. Запустите ADSIEdit.msc в меню Action, откройте пункт Connect To и выберите Schema из списка:
Подключение к схеме (schema) AD в ADSIEdit
2. Раскройте дерево CN=Schema, CN=Configuration. В списке справа выберите CN=Group-Policy-Container:
Класс Group Policy Container в ADSIEdit
3. Двойным щелчком по CN=Group-Policy-Container откройте список атрибутов. Найдите атрибут defaultSecurityDescriptor. Откройте значение атрибута.
4. На всякий случай скопируйте текущее значение атрибута defaultSecurityDescriptor в Notepad и сохраните в файл. Установите курсор в самый конец длинного значения атрибута, после последней закрывающей скобки. Добавьте следующее значение (проверить, что означает данная «магическая» строка можно с помощью утилиты SDDLPARSE):
(A;CI;LCRPLORC;;;DC)
Редактирование defaultSecurityDescriptor
5. Нажмите OK, чтобы применить изменения.
6. Запустите MMC, войдите в меню File→Add/remove snap-ins и в нём выберите Active Directory Schema. Если вы не видите AD Schema в списке, вам необходимо отключить так называемую «защиту от дурака». Запустите командную строку с повышенными привилегиями и введите regsvr32 schmmgmt.dll, после чего перезапустите MMC. Кликните правой кнопкой мыши на пункт «Active Directory Schema» и выберите «Reload the Schema» как показано ниже:
Обновление схемы (schema) AD
7. В результате вышеперечисленных действий новые групповые политики будут создаваться сразу с настроенным доступом для чтения группе Domain Computers:
Новая политика безопасности
Заключение
Я не берусь судить, была ли возможность закрыть брешь менее хлопотным для администраторов по всему миру способом (пусть и за счёт большего объёма работы для программистов Microsoft). Во всяком случае, подробное описание изменения должно было быть включено в изначальный бюллетень безопасности, а не опубликовано спустя 9 дней в (пусть и официальном) блоге.
Следует отметить, что, закрывая брешь MitM повышения уровня доступа (elevation of privilege), обновление KB3163622 открывает множественные бреши раскрытия информации (information disclosure), и с этим придётся считаться.
Ссылки
1. Microsoft KB3163622 (бюллетень безопасности MS16-072).
2. Ian Farr. Скрипт на PowerShell, который позволяет системным администраторам проверить, повлияет ли новое обновление на существующие политики.
3. Ask the Directory Services Team. Ajay Sarkaria. Подробная статья с описанием изменений поведения политик безопасности.
4. Darren Mar-Elia. Modifying Default GPO Permissions at Creation Time.
