The Patch is Only the Beginning

The Patch

The Never-Ending Cycle of Patch Management

Not all patches work out of the gate. Anyone who has been responsible for patch management knows that it is a never ending cycle of download, test, patch and repeat. What is often overlooked, unfortunately, is that sometimes, even when a patch is applied, the vulnerability it is supposed to fix isn't always fixed...not right away at least.

Patch-Plus Issues: The Hidden Vulnerabilities After Patching

Over the past few years, there have been several Microsoft vulnerabilities that need additional action after the patch is applied to actually render the vulnerability remediated. When performing Internal Vulnerability Scanning, time and again many of our clients are surprised to see KB article numbers coming up in the results as missing patches they know have been applied. And they are correct. However, registry keys or additional configuration are still needed to actually make the patch active...thus the systems are still vulnerable until that last step is taken.

Cleaning up these"Patch+" issues can not only make your systems safer from attack, but also make your next vulnerability scan that much cleaner...and may even lower your report overall risk score.

Standard Disclaimer: The Importance of Testing before Making Changes

First, the standard disclaimer. DO NOT MAKE ANY CHANGES BEFORE PROPER TESTING. Procedures to properly manage Group Policy and safely edit the registry are outside the scope of this blog post. Make sure you understand the ramifications of any settings you change beforehand, and always apply changes to a test group before full-scale deployment.

Identifying High-Risk Updates: Spotlight on MS15-011, KB2264107, and MS15-124

Okay. With all that out of the way, we will look at three common Microsoft updates that fall into this category, all of which are classified as"High Risk" or greater:

• MS15-011 GPO Path Hardening
• KB2264107 DLL Preloading
• MS15-124 Internet Explorer ASLR Bypass

Request a Quote

Understanding MS15-011 GPO Path Hardening

MS15-011 relates to a vulnerability reported in most modern versions of Windows where a domain joined machine that is configured via GPO to download and run an executable or script does not properly check to make sure it is connected to a domain server. This means that if a domain joined laptop for example connects to a malicious wireless network, it will still look for UNC paths to run the configured executable. If an attacker can spoof the UNC path (which is easy if it is an attacker controlled WIFI network) they can get the laptop to download and run a malicious executable...often as SYSTEM.

Microsoft released updates to fix this; however, the update only creates new functionality to secure specific UNC paths. Once the updates are applied, you must manually configure which UNC paths should be accessed with additional security measures. This is done via new Group Policy options.

In Group Policy Management, if you open any Group Policy Object (GPO), and go to Computer Configuration/Administrative Templates/Network/Network Provider, you will see a new"Hardened UNC Paths" item. Edit this and you will see:

If you choose"Enabled" and then click the"Show" button inside the Options pane, you will be able to add one or more UNC paths that you want to require additional security on. There are a few different syntax options depending on your goal. For example, adding an entry of \\*\ will apply the settings to any server with that share name. You can also specify any share names on specified servers, specific complete paths, etc. After creating the path entry, you can specify which security options you want to secure that path with. Microsoft's minimum recommended configuration is:

\\*\NETLOGON RequireMutualAuthentication=1, RequireIntegrity=1

\\*\SYSVOL RequireMutualAuthentication=1, RequireIntegrity=1

This protects your standard domain shares from spoofing and prevents the common attack scenario outlined above.

For full documentation on syntax and more see:

Dealing with KB2264107 DLL Preloading

This patch addresses a weakness that can be abused in many different attack scenarios, so we will not attempt to enumerate all of them here. The basics of this vulnerability is this: Because Windows will check several places for an application requested DLL file in a known order, attackers found they could abuse this functionality and place malicious DLL files in locations higher up in the search chain and get their bad DLL to run.

The patch Microsoft released created new security settings that administrators can use to help prevent these attacks. Because just turning these settings on can break some applications, they left the actual enabling up to the administrator. It can be enabled for an entire system or just certain applications. The patch allows admins to create a new registry key, CWDIllegalInDllSearch, and block some of the more problematic search locations. This new key is a Dword value that will determine what locations are disabled.

Microsoft recommends creating this entry and setting the value to either

CWDIllegalInDllSearch = 2 (Block DLL loading from network locations in most instances)

Or

CWDIllegalInDllSearch = 0xFFFFFFFF (Block all possible DLL-preloading attack vectors)

Note that Microsoft cautions that the second option has a higher likelihood of breaking legitimate applications. As already mentioned, thoroughly test any settings before large-scale deployment.

Remember that deployment of new registry entries can be accomplished through Group Policy and does not necessarily require touching each PC. For small environments there is also a Fix-It tool to run on individual systems. Additional information can be found in the links below.

Additional Reading:

Tackling MS15-124 Internet Explorer ASLR Bypass

MS15-124 is actually a roll-up of multiple patches for a variety of vulnerabilities. One of the vulnerabilities allows an attacker to bypass Windows' Address Space Layout Randomization (ASLR). ASLR attempts to make it much more difficult for an attacker to manipulate memory contents to run malicious code by randomizing what is stored where in memory. The vulnerability (CVE-2015-6161) allows an attacker to map out processes in memory at runtime, thereby rendering ASLR ineffective.

Again, fully applying this fix requires adding a registry key. The update allows the creation of a registry key that enables User32 Exception Handler Hardening. This key is named and a new DWORD entry under it is set to"1" to enable the feature. Note that the key and value are set in two different places on 64-bit systems. Again, the best way to deploy this fix in a large environment is via a GPO setting. For small environments there is a link below to a Microsoft"Fix-It" that will set the values for you.

Additional Reading:

• https://technet.microsoft.com/library/security/MS15-124#Enable_User32
• https://www.microsoft.com/en-us/msrc?rtc=1
• https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753092(v=ws.11)?redirectedfrom=MSDN (Creating Registry Items via GPO)
• https://support.microsoft.com/en-us/kb/3125869 (Fix-It Link)

Making Your Next Vulnerability Scan Report Shorter

While none of this is particularly difficult, you do have to be aware of the additional steps to remove the vulnerability, and then determine the best way to apply the change to all applicable systems in your environment. This post only covers three vulnerabilities; however, if you multiply this out across most of the Windows systems in your environment, they add up pretty quickly. Circling back and fixing these issues will result in a more secure environment and may mean your next vulnerability scan report will be quite a bit shorter.

  Download Blog

Authored By: Jeremy Johnson, CISSP