Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Those pesky registry keys required by critical security patches - Internet Security | DShield SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Those pesky registry keys required by critical security patches

With the “storm” around Meldown and Spectre slowly winding down, I would like to remind everyone on registry changes that are required by the latest patches released by Microsoft.

In most cases, the anti-virus that you are running should have created the required registry key that will allow installation of the released security patches. However, keep in mind that if the registry key is not present, that the patches will not be installed: not only that, in case the registry key is missing even future patches might not be installed, according to the Microsoft’s support web page at https://support.microsoft.com/en-us/help/4072699/january-3-2018-windows-security-updates-and-antivirus-software.

So, in order to make sure that all patches have been successfully installed make sure that the registry key mentioned in the article exists – there are various tools that can help with this.
The story with the registry key reminded me of another critical security patch that also requires a registry key to be set in order to properly work. I often tend to find servers missing this in internal penetration test, and the consequences are very serious.

The patch I am referring to is KB2871997 (https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2016/2871997), originally from 2014. This patch helps remove clear text credentials from memory on affected Windows operating systems – something that Mimikatz, an attacker’s favorite tool successfully exploits.

In the figure below you can see how Mimikatz successfully extracts the plain text password from an unpatched Windows 2008R2 server.

No WDigest patch or registry key

Unfortunately, even after installing the patch, the clear text password is still in memory – Microsoft presumably did not want to change the default behavior for WDigest. The problem is that many administrators missed that the registry key needs to be added – as I mentioned previously, in (too) many internal penetration tests I find Windows 2008R2 servers which are fully patched, but miss this registry key. Once an attacker gets administrator privileges, on such a system, he can run Mimikatz and dump plain text password.

Additionally, after applying the patch, you also need to reboot the server for the patch to finally take effect – until the server has been rebooted the passwords are still available in memory. Once this has been finally done, plain text passwords will not be available in the memory, as shown in the figure below:

After the patch and registry key added

If you are still running Windows 2008R2 servers, make sure that both the patch and registry key have been successfully applied. Additionally, make sure that you monitor this registry key and any potential changes on servers: an attacker could possibly change the value of the registry key to any other value (i.e. 1) and wait for the server to reboot; once rebooted the server will again start keeping plain text passwords in memory. Something to watch for.

--
Bojan
@bojanz
INFIGO IS

I will be teaching next: Web App Penetration Testing and Ethical Hacking - SANS London February 2019

Bojan

375 Posts
ISC Handler
Thank you for bringing this to my attention! Can I get more information/clarification on the registry key that needs to be modified to disable this? Thanks.
Anonymous
Thank you for the great write up. I wanted to clarify the registry setting. Is there one registry change required by AV software just to be presented with the Microsoft update and a second registry change required along with the Microsoft update for vulnerability mitigation. Or is there just one required registry change?
Anonymous
He is referring to this registry key

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest
•If the UseLogonCredential value is set to 0, WDigest will not store credentials in memory.
•If the UseLogonCredential value is set to 1, WDigest will store credentials in memory.
Anonymous
Thanks for the comments everyone!

So, regarding the Meltdown/Spectre patches, the registry change that needs to be introduced is described in the support page linked above.
Specifically, it's this registry key:

Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" Value="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD”
Data="0x00000000”

Generally, your AV should set this automatically if it supports the patches (if it has not set this registry key check with your AV vendor why - there are legitimate cases when the AV will not set this).

For the WDigest issue, I see that another ISC reader posted this already - thank you!

Bojan
Bojan

375 Posts
ISC Handler
Just so I understand correctly, what does it mean if I do not have this registry key at all? Do I need to manually enter it before (or after) applying the patch, or does the patch create the registry entry (meaning, if I do not have the key, then I have not applied the patch)?
Anonymous
It's not only that compatibility flag you have to worry about. On the Windows Server OSs additional registry keys need to be configured to turn on speculative execution mitigations. Without this configuration the patches will have no effect. See this Microsoft KB for more info on that. https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution
Anonymous
Regarding this for Server 2008R2

--------------------
He is referring to this registry key

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest
•If the UseLogonCredential value is set to 0, WDigest will not store credentials in memory.
•If the UseLogonCredential value is set to 1, WDigest will store credentials in memory.
--------------------

What if there is no UseLogonCredential value present at all under the WDigest Key?

I have checked 2 of my 2008R2 servers...(1 virtual/1 physical).... and that value is not present on either of them...
K-Dee

65 Posts
The registry key UseLogonCredential by default will not exist on a Windows Server 2008R2 machine, not even after the patch has been installed.

So you will have to create it manually in order for Windows to stop caching the plain-text password in memory.
Once you do that (you can use DWORD 32-bit) make sure that all users fully log out or you restart the server in order to clear previously cached plain-text passwords in memory.
Bojan

375 Posts
ISC Handler

Sign Up for Free or Log In to start participating in the conversation!