The Kerfuffle with Kerberos

Kerberos may be considered the old-timer of authentication protocols, but Active Directory still relies heavily on it. That’s why Microsoft is now using a new strategy to address vulnerabilities. IT Pro's may operate the same way they did before but might not get the same results as they once did.

I feel that Active Directory admins need to get onboard with the registry changes that truly address the vulnerabilities. They can do this proactively and stay ahead of the curve. Their Domain Controllers will run smoothly without interruptions, because all the hard work of testing was done when there was ample time to do so.

Let me show you.

Active Directory Today

They say it’s not easy to change a tire on a riding car. I guess it’s also not easy to change the configuration of a service that is at the heart of networking infrastructures of millions of organizations worldwide. That’s precisely what Microsoft is doing these days with Active Directory.

Active Directory is at the heart of over 90 percent of networking infrastructures worldwide. It provides identity and access management capabilities through various networking protocols; LDAP, NTLM and Kerberos which is why proper Active Directory monitoring and management is a critical component for any IT admin. 

These protocols have all been around for decades, long before the Internet was available in our homes. They were designed for trusted networks. However, anyone who has ever experienced a NotPetya ransomware attack has learned that there is no such thing as a network one can trust.

Kerberos Improvements

In recent years, Microsoft has made significant changes in its Kerberos implementation. Since Windows Server 2000 – the Windows Server release that included the initial release of Active Directory – the product team has added measures to the existing protocol to restrict unwanted uses and prohibit unsafe actions.

The First Wave

Improvements like Kerberos Armoring (Windows Server 2012) and the Protected Users group (Windows Server 2012 R2) can be considered late parts of the first wave of Kerberos improvements. Admins who had eradicated previous versions of Windows and Windows Server, could enable these features centrally and benefit.

However, the sobering reality is that many organizations didn’t pay attention to these basic improvements. Most organizations still have Windows 7-based devices around, even though Microsoft has stopped the support of these operating systems (with some paid exceptions). Even when they were moving fast and furiously and got rid of all the legacy blocking these features, they didn’t enable them…

Of course, Microsoft certifications paid attention to these measures. The questions with these technology names and feature names in their answers were the easiest to answer: these answers were the right ones, because they represented new technology. We can conclude the theory is there, at least while crammed into short-term memory, but in practice it’s not implemented.

The results of many Active Directory health and risk assessments show that most AD admins manage their AD environments like it’s 2003. I think that’s a shame, because implementing the above two features correctly removes the ability to Kerberoast and use Mimikatz on admin accounts. These attacks are getting increasingly common to pop Domain Controllers.

The Second Wave

Of course, some organizations have implemented these changes. Attacks against these organizations, and their supply chains, had to get more sophisticated. Researchers have picked all the low-hanging fruit, so you can imagine today’s vulnerabilities are harder to address.

Addressing today’s vulnerabilities in Kerberos and LDAP requires admins to actively prohibit the use of legacy clients, legacy technologies, and legacy cryptography.

A second wave of fixes is needed. In my mind, Microsoft’s answer to the ZeroLogon vulnerability (CVE-2020-1472) immediately stands out as a solution that is part of the second wave. As does Microsoft’s approach to enforce LDAP channel binding and LDAP signing (CVE-2017-8563) and the way Microsoft addressed the Kerberos Security Feature Bypass vulnerability known as CVE-2020-16996.

LDAP Channel Binding and Signing

As part of the July 2017 Patch Tuesday series of updates, Microsoft introduced functionality to enable mitigations for an elevation of privilege vulnerability that exists when Kerberos falls back to NT LAN Manager (NTLM) as the default authentication protocol.

After installing the update, to effectively thwart these LDAP relay attacks, AD admins needed to perform two additional steps:

Microsoft automatically rolled out these registry changes with the March 2020 Patch Tuesday. These settings are now enforced and any application, service, or system that doesn’t adhere to the new security standards fails.

ZeroLogon

During the August 2020 Patch Tuesday (August 11^th, 2020), Microsoft used the same playbook to address two vulnerabilities. The vulnerability dubbed ‘ZeroLogon’ (CVE-2020-1472) poses the more serious problem. CVE-2020-16996 is the other Kerberos-related patch that was part of this Patch Tuesday.

The recipe is the same: Install the patch and edit the registry. Except that for ZeroLogon, Microsoft made a Group Policy setting available: The Domain controller: Allow vulnerable Netlogon secure channel connections group policy setting. Fancy… until you realize Group Policy settings are mere registry settings anyway.

The registry settings are to be automatically applied with the February 2021 Patch Tuesday (February 9^th, 2021). After installing the February 2021 cumulative update, applications, services, and systems that don’t support the use of secure RPC for the Netlogon secure channel, are blocked, fail, and trigger Event ID 5829 on Domain Controllers.

Timelines

When we put the above updates on a timeline, the following picture emerges, based on Microsoft Patch Tuesdays. The left edge of a block depicts the release of an update, and the red part depicts the mounting urgency towards (automatic) enforcing new security standards:

Figure 1: Examples of the second wave of identity-related security updates

Now, it gets interesting because the Kerberos KDC vulnerability known as CVE-2020-17049
comes into view. This Kerberos update is interesting, because Microsoft Security Response Center (MSRC)’s security update guide provided troublesome data for the corresponding PerformTicketSignature registry value, initially. Organizations who applied the update lost functionality between domains in multi-domain Active Directory implementations. The security update guide was revised soon after.

A New Strategy Calls for a New Approach

Zooming out, we can make out a new strategy from Microsoft when it comes to securing Active Directory and Kerberos. Microsoft changed its ways to address the security kerfuffle that is intrinsic to today’s Kerberos implementations and uses.

It’s clear something needs to be done to secure the on-premises protocols to preserve them as golden oldies for our networking needs.

I think there are three approaches admins can use to deal with the ‘new normal’ in Kerberos:

1. Don’t patch
   This approach is commonly referred to as the way of the dodo. In my opinion, this strategy only suits organizations with pirated software and admins who like to deliberately endanger others. This is neither a long-term strategy to cope with new ways environments are attacked, nor a viable short-term strategy to get other things done. Even if you’re not a high-profile target, you might still get pwned, as Maersk and other organizations showed us.
   
   
2. Patch diligently
   Installing Windows Updates on Domain Controllers can be an adventure. This can blow up in the face of AD admins in two distinct ways:
   • By not making the required registry changes, you end up in the same sorry and vulnerable state for the time between release of the patch and enforcement of the settings.
   • Installing updates on one Domain Controller to see how it holds up, and then installing the updates on other Domain Controllers, might not prove to be a worthwhile way to minimize the risk of rogue updates – updates that break functionality. The update descriptions don’t mention any of the changed functionality, because the changes were mentioned six months ago...
     
     
3. Patch and address proactively
   Admins who know what a Windows Update brings may use this knowledge to stay ahead of the curve. Using Active Directory sites, certain domain-joined devices can be pointed to a specific set of Domain Controllers and configured with the new registry settings that accompany Windows Updates. This way, problems can be detected before the enforcement date. These problems can be limited to some workstations, a department, a district school, or a country your organization operates in. For each change, a different yet representative part of your network can be the guinea pig, to keep things fair.

What Will Your Approach Be?

I’ll be the first to acknowledge that the third approach requires more time each month. It requires reading through Microsoft Security Response Center (MSRC)’s security update guide. It requires knowledge on how your organization uses certain technologies. It requires time, but it delivers something that holds true value. When this approach is embedded into current processes, IT can provide guarantees on the integrity and availability of applications, services, and systems. This earns them good nights filled with sleep and goodwill in the organization.

However, I don’t think you should throw away your process of installing Windows Updates in pre-production environments. Looking at CVE-2020-17049, it also still makes sense to deploy Windows Updates to a separate, yet representative pre-production environment.

Some might argue that AD admins could wait a week before implementing updates, but if every admin performed their job this way, we would only know of problems weeks after Patch Tuesdays…

Let Us Know

What will your approach to Active Directory monitoring and management be going forward? Join the conversation on Twitter.

Active Directory Monitoring with ENow

Active Directory is the foundation of your network, and the structure that controls access to some of the most critical resources in your organization. ENow uncovers cracks in your Active Directory that can cause a security breach or poor end user experience. In particular, ENow enables you to:

- Report on highly privileged groups (domain admins)
- AD replication errors
- Identify Expensive LDAP queries
- DNS and name resolution problems
- Troubleshoot poor Exchange performance caused by Active Directory

 Don’t take our word for it. Start your free trial today!