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

Nothing foreshadowed troubles 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 a strange behavior of security policies. The most common symptom: network printers and folders began to fall off.



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



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

')

Who is guilty?

The culprit of this behavior was the security update from article KB3163622 (security bulletin MS16-072 , KB number for various operating systems: KB3159398 , KB3163017 , KB3163018 , KB3163016 ), designed to close the security gap 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 policy source. The attacker, using the MitM tactic ( Man in the Middle - intermediary attack), could substitute a response from the domain controllers and send fake security policies to the attacked computer, giving, for example, local administrator rights to the compromised ordinary user account.



As it turned out, to solve this problem, Microsoft programmers did not find anything better than to change the behavior of the group policy application process, which has not changed since the release of Windows 2000. Traditional behavior involved access to computer scope security policies from the computer account, and to user-level security policies - from user account . After installing the update KB3163622, all requests began to be sent from the computer account to ensure the power of attorney of the source using the Kerberos protocol.



Testing of the update (if any, was conducted at all) 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).



Under actual operating conditions, system administrators restrict the distribution of many policies using a simple and intuitive security filtering mechanism, as well as directly modifying access settings to some policies. It should be noted that the modification of access control lists to policies is a regular policy setting tool and cannot be the reason for accusing system administrators of creating a non-standard situation.





Security Filtering List



As a result, a stream of complaints poured on Microsoft, and the forums were full of quick recommendations to cancel (update) KB3163622 in WSUS. The situation, unfortunately, has become not uncommon in recent years, when almost every month some updates come out again in a new edition after a negative reaction from users. This time, however, Microsoft made it clear that it will not back down and will have 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 this behavior change will be saved.



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



During the week, specialized resources were seething with passion, since, apart from three lines in the security bulletin, no official information from Microsoft was received. Finally, 9 days after the release of the update, the official blog of the Ask the Directory Services Team published a detailed article that, for good, should if not precede the release of the update (even if, for security reasons, before the release of the patch, the essence of the vulnerability cannot be disclosed) , then at least go to the first line in the June bulletin.

What to do?

TL; DR: Below is a guide on how to make 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 propose — to add Authenticated Users or Domain Computers with read-only access to all policies that have stopped working — is a half-measure. When modifying or creating new security policies, from now on and forever you will need to remember to add one of the above groups. The intuitive security filtering tool, available directly on the first page of the security policy editor ( group policy editor ), generally loses all meaning, since it is still necessary to manually change access control lists.



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



The advantage of this solution is the absence of the need to support it: the behavior of group policies will hardly change, there is no need to change the rules for creating / modifying policies. The security filters mechanism will continue to work, which very visually allows you to present and edit access parameters to policies.



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



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

Considerations on the applicability of these recommendations

First of all, I recommend studying 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, in recent days published in various blogs. You need to understand what was the purpose of changing security settings. I see such a list of the most obvious goals:



1. Secondary access restriction to the resource . For example, access to a network printer is limited to the Example1 group in the security settings of the printer itself, and, additionally, the security policy that connects this printer applies only to members of the Example1 group. In such a situation, adding rights to read (but not apply policies) for Domain Computers is perfectly safe.



2. Restricting the dissemination of information contained in the security policy itself . I would not recommend to store sensitive ( sensitive ) data (for example, passwords) in security policies, but I admit that until last week this approach had a right to exist, since access to the security policy files in the shared folder SYSVOL is automatically limited to the access list, applied to politics itself. After the changes, which brings the update, access will be forced to get accounts of all computers. Addressing the SYSVOL folder on behalf of a computer is still not the most trivial task for a user with limited rights, but, potentially, this is possible (for example, using a separate local privilege vulnerability). Before proceeding to the following instructions, consider the potential risks, and possibly remove sensitive information from the security policy.



2a. Under the conditions of increased security requirements, according to the Principle of Minimum Privileges, the default access for Authenticated Users can be replaced with a narrower access for all security policies . In this case, a complete revision of the entire policy protection strategy is needed. For user-level policies, an attempt to narrow the circle of access will now inevitably lead to a violation of the postulate about the separation of user and computer security policies. For example, an attempt to limit the distribution of a policy that applies only to privileged users, a group of computers on which these users work, will result in an actual confusion of user and computer scope policies, which is not a good practice.

Instruction

After you have decided on the applicability of the proposed approach (see the previous section), you need to start PowerShell with domain administrator or other account having full access to all security policies and enter the following command:



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



This command will add read (but not apply) policies for the Domain Computers group to all domain security policies. After its execution, you can safely install the update KB3163622, for existing security policies, it is no longer scary.



Warning The next step is to change the schema (schema) of AD so that 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 (schema) AD is, first study this concept or limit to the previous paragraph of the instruction and add Domain Computers to new policies manually or launch the above PowerShell command (or modify it). with the replacement of "-All" in the name of the policy) after the creation of each new security policy.



Further instruction is a free translation of the article Darren Mar-Elia .



Check 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 the Connect To item and select Schema from the list:



Connect to schema (schema) AD 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



3. Double-click on CN = Group-Policy-Container to open the attribute list. Locate the defaultSecurityDescriptor attribute. Open attribute value.



4. Just in case, copy the current value of the defaultSecurityDescriptor attribute in Notepad and save to a file. Position the cursor at the very end of the long attribute value, after the last closing bracket. Add the following value (you can check the meaning of this “magic” string using the SDDLPARSE utility ):



(A;CI;LCRPLORC;;;DC)





Editing defaultSecurityDescriptor



5. Click OK to apply the changes.



6. Start MMC , go to File → Add / remove snap-ins and select Active Directory Schema . If you do not see AD Schema in the list, you need to disable the so-called "foolproof". Run a command prompt with elevated privileges and enter regsvr32 schmmgmt.dll , then restart MMC . Right click on the “ Active Directory Schema ” item and select “ Reload the Schema ” as shown below:



AD schema update



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



New security policy

Conclusion

I do not presume to judge whether it was possible to close the gap in a less troublesome way for administrators around the world (albeit at the expense of more 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 the (albeit official) blog.



It should be noted that, by closing the MitM access elevation gap ( elevation of privilege ), updating KB3163622 opens multiple gaps in information disclosure , and this will have to be considered.

Links

1. Microsoft KB3163622 (security bulletin MS16-072).



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



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



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