Оновлення MS16-072 ламає Group Policy. Що з цим робити?

Помилка: Filtering: Not Applied (Unknown Reason)

Нічого не віщувало біди в минулий вівторок оновлень» (14 червня): бюлетень оновлень містив лише сухий перелік важливих оновлень безпеки і стандартні рекомендації щодо їх негайної установці. Однак, після застосування оновлень, системні адміністратори по всьому світу зіткнулися з дивною поведінкою політик безпеки. Найбільш поширений симптом: почали відвалюватися» мережеві принтери і папки.

Ті, хто слідував кращим практикам розповсюдження оновлень, помітили, що таке поведінка спостерігалося тільки в тестовій групі, оновлення якої були прийняті до поширення їх по всій організації.

При спробі розібратися в ситуації, результат GPRESULT викликало деяке замішання: деякі політики безпеки рівня користувача (user scope) не застосовувалися, видаючи дуже «інформативне» повідомлення: «Filtering: Not Applied (Unknown Reason)». Деякі нові політики просто не з'являлися у висновку GPRESULT.

Хто винен?

«Винуватцем» такої поведінки стало оновлення KB3163622 (бюлетень безпеки MS16-072), покликаний закрити дірку в безпеці процесу застосування групових політик. З моменту появи технології групових політик не було приділено належну увагу забезпеченню довіреності джерела політик. Атакуючий, застосовуючи тактику MitM (Man in the Middle — атака посередника), міг підмінити відповідь від контролерів домену та надіслати на атакується комп'ютер підроблені політики безпеки, що дають, наприклад, права локального адміністратора скомпрометованої облікового запису рядового користувача.

Як виявилося, для усунення даної проблеми програмісти Microsoft не знайшли нічого краще, ніж змінити поведінку процесу застосування групових політик, який не змінювався з часу виходу Windows 2000. Традиційне поведінка передбачало доступ до політиків рівня безпеки комп'ютерів (computer scope) від облікового запису комп'ютера, а до політиків безпеки рівня користувача (user scope) — від облікового запису користувача. Після установки оновлення KB3163622 всі запити стали направлятися від облікового запису комп'ютера, щоб забезпечити довіреність джерела силами протоколу Kerberos.

Тестування оновлення (якщо таке взагалі проводилося) не виявило жодних проблем, так як за замовчуванням доступ до всіх груповим політикам дозволений для групи Authenticated Users, яка включає в себе всі облікові записи (комп'ютерів і користувачів).

В реальних умовах експлуатації системні адміністратори обмежують поширення багатьох політик з застосуванням простого і наочного механізму фільтрів безпеки (security filtering), а також безпосередньої модифікації налаштувань доступу до деяким політикам. Слід зазначити, що модифікація списків контролю доступу до політиків є штатним інструментом налаштування політик і не може бути підставою для звинувачення системних адміністраторів у створенні нестандартній ситуації.

Список фільтрів безпеки(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
Підключення до схеми (schema) AD в ADSIEdit

2. Розкрийте дерево CN=Schema, CN=Configuration. У списку праворуч виберете CN=Group Policy-Container:
Клас Group Policy Container в ADSIEdit
Клас Group Policy Container в ADSIEdit

3. Подвійним клацанням CN=Group Policy-Container відкрийте список атрибутів. Знайдіть атрибут defaultSecurityDescriptor. Відкрийте значення атрибута.

4. На всяк випадок, скопіюйте поточне значення атрибута defaultSecurityDescriptor в Блокнот і збережіть у файл. Встановіть курсор в кінець довгого значення атрибута, після останньої закриваючої дужки. Додайте наступне значення (перевірити, що означає ця «магічна» рядок можна з допомогою утиліти SDDLPARSE):

(A;CI;LCRPLORC;;;DC)
 

Редагування defaultSecurityDescriptor
" Редагування defaultSecurityDescriptor

5. Натисніть OK, щоб застосувати зміни.

6. Запустіть MMC, увійдіть у меню FileAdd/remove snap-ins і в ньому виберіть Active Directory Schema. Якщо ви не бачите AD Schema у списку, вам необхідно відключити так звану «захист від дурня». Запустіть командний рядок з підвищеними привілеями та введіть regsvr32 schmmgmt.dll, після чого перезапустіть MMC. Натисніть правою кнопкою миші на пункт «Active Directory Schema» і виберете «Reload the Schema» як показано нижче:
Оновлення схеми (schema) AD
Оновлення схеми (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.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.