Silverfort Protection Against the Bronze Bit CVE-2020-17049 Exploit – Update

***** By Yiftach Keshet, Director of Product Marketing and Dor Segal, Security Researcher Silverfort   *****

On December 8, the new Bronze Bit exploit of CVE-2020-17049 Kerberos vulnerability was made public, adding another cutting-edge weapon to attackers’ post-compromise arsenal. While the full fix of this vulnerability will not be enforced before February 8 2021, Silverfort’s Unified Identity Protection Platform delivers full protection against the Bronze Bit attack . Through its unique ability to enforce MFA and adaptive access controls on Active Directory authentication protocols, Silverfort introduces a new paradigm on defense against lateral movement attacks in Active Directory environments. A detailed analysis of the delegation types, CVE-2020-17049 and the Microsoft patch was performed by Silverfort’s Security Researcher – Dor Segal and it’s available here.

The Journey Towards Secure Delegation

CVE-2020-17049 enables an attacker to bypass the Resource Constrained Delegation authentication security control.

In general, Delegation refers to the ability of Active Directory account to impersonate, or act on behalf of another account, in order to access resources with the other account’s access privileges. A common example is when a user accesses a web application: While it seems that the user accesses the web application directly, what happens in the backend is that the user account delegates its access privileges to a service account which impersonates the user and accesses the app database on the user’s behalf.

From a security perspective, the concern is what happens if this mechanism is abused by an attacker. The first Delegation mechanism that was offered in AD, also known as Unconstrained Delegation, introduced a significant risk since it enabled the impersonating service to access all the resources the delegating account could access.

This concern led to gradual evolution of delegation over the years as shown in this table:

As can be seen clearly in the table, each generation reduces the risk by materially decreasing the number of delegating accounts, impersonating services and accessible resources. While the scenario of an attacker performing malicious delegation is still possible, its implications in terms of resource access are significantly narrowed.

Resource-Constrained Delegation are the most secure delegation type therefore they are currently the standard that’s used in most Active Directory environments.

Now that we have gained insight into Delegation, we can understand the impact of the Bronze Bit exploit.

The Bronze Bit Attack – Impairing Delegation Security Controls

The Bronze Bit attack makes use of CVE-2020-17049 vulnerability to enable an attacker to perform the following (extracted and edited from its author’s blog):

‘An attacker can impersonate users which are not allowed to be delegated. This includes members of the Protected Users group and any other users explicitly configured as “sensitive and cannot be delegated”

So, this attack takes us back in terms of risk exposure, increasing the attack surface to practically all user account within the environment.

Microsoft CVE-2020-17049 Mitigation Activities

Microsoft released a patch for this vulnerability as part of the November 8th Patch Tuesday. However, due to various Kerberos authentication issues a new patch was made available on December 8th. This patch provides enterprises protection against the exploitation of the vulnerability until the full enforcement of the Kerberos protocol fix, which will take place on February 8, 2021. Given the typical difficulties entailed in server security patching in general and Domain Controllers specifically, it’s likely that despite the availability of the patches, not everyone deploys them immediately. So, there is currently a significant risk exposure for these organizations.

Silverfort Protection against Delegation Based Attacks

Silverfort Unified Identity Protection Platform is the only solution that consolidates monitoring, risk analysis and access policy enforcement for all user and service account authentications across all corporate networks and cloud environments.

Due to it’s innovative agentless proxyless technology, Silverfort can extend MFA to a wide range of resources that couldn’t be protected before. This of course includes any authentication that uses the Kerberos protocol.

And it’s important to note that when setting up a Silverfort policy for a user, the policy’s security controls apply both to direct as well as delegated authentications performed by the user. Let’s see how this applies to the protection of both delegating and non-delegating user accounts.

Protection against the Bronze Bit attack – delegating accounts

In practice, delegating accounts (i.e. accounts that are configured to allow delegation) are already protected by default due to Silverfort’s continuous monitoring of Active Directory authentication protocols, which automatically identifies these accounts and factors the delegation into their risk score.

Thus, the following risk-based policy would trigger an MFA requirement whenever an anomalous authentication attempt will take place:

Whenever such an account’s authentication attempt exceeds medium risk score, an MFA requirement will pop up for the user. If the authentication was made by an attacker performing malicious delegation on behalf of this account, the account owner can block access by confirming that it’s not his request.

Protection against the Bronze Bit attack – non delegating accounts

But how can we protect the user accounts that are not configured for delegation? The risk-based policy won’t do here, since these accounts don’t include the delegation factor, so a different approach is required.

Let’s recap – the scenario we want to mitigate is this: an attacker has compromised a service account – let’s call it account 1. The attacker wants to access a sensitive resource – let’s call it resource 1 – but cannot do it under the access privileges of account 1. With the Bronze Bit exploit the attacker can use account 1 to impersonate a high-privileged account that we will call account 2 that is configured to not allow delegation (for example, any member of the Protected Users group), in order to access resource 1.

Account 1 is impersonating account 2 to access resource 1. Behind the scenes, prior to accessing resource 1, account 2 authenticates to account 1 in order to provide user 1 the ability to act on its behalf. Now, account 1 must be a service that is configured to allow impersonation. Since all the services that are configured to do so are already known (after all they were configured by the domain administration team) all we need is the following policy:

The ‘Non-Delegating Accounts’ stands for all user accounts configured to not delegate, while the ‘Impersonating Service Accounts’ represent all the service accounts that are configured to allow impersonation. Alternatively, If we would want to deny delegation only and still access the resource, they could use the “Source” field to limit only the delegation access.

In this case we recommend to assign ‘Deny’ as the protective action: Since these accounts should never interact with delegating service accounts, no operational disruption should occur.

This protection totally impairs the Bronze Bit attack. Even if the attacker managed to force a high privileged account to attempt delegation, Silverfort will prevent its actual engagement with an impersonating service account.

Silverfort protection against the Bronze Kit exploit demonstrates once again how applying adaptive access control to Active Directory authentication protocols, and specifically to the remote access command line tools attackers would use to launch the Bronze Kit attack, is imperative to deliver sufficient protection against lateral movement attacks.

Learn more about Silverfort here