Update MS16-072 breaks Group Policy. What to do with it?

Error: Filtering: Not Applied (Unknown Reason)

Nothing boded of trouble last "Tuesday of updates" (June 14): the update bulletin contained only a dry list of important security updates and standard recommendations for their immediate installation. However, after applying the updates, system administrators around the world are faced with strange behavior of security policies. The most common symptom: network printers and folders began to “fall off”.

Those who followed the best practices for distributing updates noticed that this behavior was observed only in the test group, updates for which were accepted before distribution throughout the organization.

When trying to understand the situation, the result of GPRESULT plunged into some confusion: some user-level security policies were not applied, giving a very “informative” message: “Filtering: Not Applied (Unknown Reason)”. Some new policies simply did not appear in the GPRESULT output.

Who's guilty?


The “culprit” of this behavior was the security update from article KB3163622 (security bulletin MS16-072 , KB number for various OSs: KB3159398 , KB3163017 , KB3163018 , KB3163016 ), which was designed to close the security hole in the process of applying group policies. Since the advent of Group Policy technology, due attention has not been paid to ensuring the power of attorney of the source of policies. Attacker using MitM tactics ( Man in the Middle — атака посредника), мог подменить ответ от контроллеров домена и прислать на атакуемый компьютер поддельные политики безопасности, дающие, например, права локального администратора скомпрометированной учётной записи рядового пользователя.

Как оказалось, для устранения данной проблемы программисты Microsoft не нашли ничего лучше, чем изменить поведение процесса применения групповых политик, которое не менялось со времени выхода Windows 2000. Традиционное поведение предусматривало доступ к политикам безопасности уровня компьютеров (computer scope) от учётной записи компьютера, а к политикам безопасности уровня пользователя (user scope) — от учётной записи пользователя. После установки обновления KB3163622 все запросы стали направляться от computer account to ensure that the source is trusted by Kerberos.

Testing the update (if any) did not reveal any problems, since by default access to all group policies is allowed for the Authenticated Users group , which includes all accounts (computers and users).

In real-world environments, system administrators restrict the distribution of many policies using a simple and clear security filtering mechanism.), as well as directly modifying access settings for some policies. It should be noted that modifying access control lists to policies is a regular tool for setting policies and cannot be a reason to accuse system administrators of creating a non-standard situation.

Security Filtering List
The list of security filters (security filtering)

As a result, a flood of complaints poured on Microsoft, and the forums were full of hasty recommendations to cancel ( decline) update KB3163622 in WSUS. The situation, unfortunately, has become not uncommon in recent years, when almost every month some updates are re-released in a new edition after a negative reaction from users. This time, however, Microsoft made it clear that it would not back down and that it would be necessary to get used to the new rules for applying security policies.

On June 15, a brief indication was added to MS16-072 that, as they say, “this is not a bug, this is a feature,” and such a change in behavior will be saved.

Microsoft employee Ian Farr released a PowerShell script on June 16 that allows system administrators to check if a new update will affect existing policies.

Over the course of the week, passion had been seething on specialized resources, since apart from three lines in the security bulletin, no official information was received from Microsoft. Finally, 9 days after the update was released, a detailed article was published on the official Ask the Directory Services Team blog , which, if it was good, should, if not precede the release of the update (for security reasons, the essence of the vulnerability should not be disclosed before the patch) , then at least go the first line in the June newsletter.

What to do?


TL; DR: The following is instructions for making changes to the GPO and AD to prevent damage from installing this update.

With all due respect to the AD DS Team, it seems to me that the solution they are proposing - to add Authenticated Users or Domain Computers with read-only access to all policies that have stopped working - is half measure. When modifying or creating new security policies, now and forever you will need to remember the need to add one of the above groups. A clear security filtering tool available directly on the first page of the group policy editor) generally loses all sense, since you still need to manually change access control lists.

It seems easier to use the following solution: add the Domain Computers group with read-only rights (but not application rights ) to all policies (if this is possible for security reasons), and also make minimal modifications to the AD schema so that new policies created immediately with the necessary rights.

The advantage of this solution is the lack of the need to support it: the behavior of group policies will not change much, there is no need to change the rules for creating / modifying policies. Will continue to work and security filtering mechanism ( security the filters), which allows you to very clearly present and edit the settings for access to policies.

The downside is the need to modify the AD schema , but the modification is so trivial that it should not cause any problems.

Why do I propose adding Domain Computers instead of Authenticated Users ? Firstly, in order not to violate the Principle of Minimum Privileges : even after such abuse of this principle that this update makes, we can still prevent an unprivileged user from reading policies that apply to privileged users by simply entering SYSVOL. Secondly, by default Authenticated Usersalready have rights to read and apply the policy. Removing Authenticated Users from the list of security filters ( security filtering ) we remove not only the right to use, but also the right to read. At the same time, if the Domain Computers group is added to read-only access lists, it will not appear in the security filtering list and will not be deleted.

Considerations for the applicability of these recommendations


To begin with, I recommend that you examine the list of group policies in your domain that will be directly affected by the behavior change. This will help the script with TechNet or one of its modifications, published in various blogs in recent days. You need to understand what the purpose of changing security settings was. This list of the most obvious goals seems to me:

1. Secondary restriction of access to the resource . For example, access to a network printer is limited by the Example1 group in the security settings of the printer itself and, in addition, the security policy that connects this printer applies only to members of the Example1 group . In such a situation, adding read permissions (but not applying policies) toDomain Computers is completely safe.

2. Restriction of the dissemination of information contained in the security policy itself . I would not recommend keeping sensitive.) data (for example, passwords) in security policies, but I assume that until last week this approach had the right to exist, since access to the security policy files in the SYSVOL public folder is automatically limited to the access list applied to the policy itself. After the changes that the update brings, access will be forced to the accounts of all computers. Accessing the SYSVOL folder on behalf of a computer is still not the most trivial task for a user with limited rights, but, potentially, it is possible (for example, using a separate local privilege escalation vulnerability). Before proceeding to the following paragraphs of the instruction, potential risks should be weighed and, possibly, sensitive information should be removed from the security policy.

2a. In conditions of increased security requirements, according to the Principle of Minimum Privileges, the default access for Authenticated Users can be replaced with a narrower one for all security policies . In this case, a complete review of the entire policy protection strategy is necessary. For user scope policies, an attempt to narrow the circle of access will now inevitably lead to a violation of the tenet about the separation of user and computer security policies. For example, an attempt to restrict the distribution of policies that apply only to privileged users to the group of computers on which these users work will lead to an actual mixture of user and computer scope), which is not good practice.

Instruction manual


After you have decided on the applicability of the proposed approach (see the previous section), you must run PowerShell with the rights of a domain administrator or another account that has full access to all security policies and enter the following command: This command will add read permissions (but non-application) policies for the Domain Computers group in all domain security policies. After its implementation, you can safely install update KB3163622, for existing security policies it is no longer scary. Warning

Get-GPO -All | Set-GPPermissions -TargetType Group -TargetName "Domain Computers" -PermissionLevel GpoRead



. The next step is to modify the AD schema so that the newly created policies already have permission to read the policy by the Domain Computers group in their access control list. Although the change is minimal, I would like to advise those administrators who do not know what the schema AD is, to study this concept first, either to confine ourselves to the previous paragraph of the instruction and add Domain Computers to new policies manually, or to launch the aforementioned PowerShell command (or its modification with the replacement “-All” in the name of the policy) after creating each new security policy.

The following instructions are a free translation of the Darren Mar-Elia article .

Verify that you have sufficient access for the following operations. You must be a member (directly or indirectly) of the Schema Admins group .

1. Run ADSIEdit.msc in the Action menu , open Connect To and select Schema from the list:
Connecting to an AD schema in ADSIEdit
Connect to AD schema in ADSIEdit

2. Expand the tree CN = Schema, CN = Configuration . In the list on the right, select CN = Group-Policy-Container :
Group Policy Container Class in ADSIEdit
The Group Policy Container class in ADSIEdit

3. Double-click CN = Group-Policy-Container to open the list of attributes. Find the defaultSecurityDescriptor attribute. Open the attribute value.

4. Just in case, copy the current value of the defaultSecurityDescriptor attribute to Notepad and save it to a file. Place the cursor at the very end of the attribute's long value, after the last closing bracket. Add the following value (you can check what this “magic” string means with the SDDLPARSE utility ): Editing defaultSecurityDescriptor 5. Click OK to apply the changes. 6. Launch MMC , go to FileAdd / remove snap-ins and select Active Directory Schema in it . If you do not see AD Schema

(A;CI;LCRPLORC;;;DC)

Editing defaultSecurityDescriptor




in the list, you need to disable the so-called "protection from the fool." Run the elevated command prompt and enter regsvr32 schmmgmt.dll , then restart the MMC . Right-click on the item “ Active Directory Schema ” and select “ Reload the Schema ” as shown below:
Updating an AD schema
Updating the schema AD

7. As a result of the above actions, new group policies will be created immediately with read access configured for Domain Computers group :
New Security Policy
New Security policy

Conclusion


I don’t dare to judge whether the opportunity to close the gap was less troublesome for administrators around the world (albeit due to the greater amount of work for Microsoft programmers). In any case, a detailed description of the change should have been included in the original security bulletin, and not published after 9 days in a (albeit official) blog.

It should be noted that by closing the MitM breach of elevation of privilege , the KB3163622 update opens multiple information disclosure gaps , and this has to be taken into account.

References


1. Microsoft KB3163622 (Security Bulletin MS16-072).

2. Ian Farr. A PowerShell script that allows system administrators to check whether a new update will affect existing policies.

3. Ask the Directory Services Team. Ajay Sarkaria. A detailed article describing changes in the behavior of security policies .

4. Darren Mar-Elia. Modifying Default GPO Permissions at Creation Time .

Also popular now: