CVE-2020-17049: Kerberos Bronze Bit Attack – Explained and Exploited

Overview

In this presentation, NetSPI’s Senior Technical Architect Jake Karnes explains the inner workings of CVE-2020-17049: The Kerberos Bronze Bit Attack. Jake discovered this vulnerability and responsibly disclosed it to Microsoft which provided patches in November and December of 2020. Once the patches became available, Jake shared the exploit which allows an attacker to bypass security features and escalate privileges within an Active Directory domain. 

The presentation provides an introduction to the Kerberos protocol and Microsoft’s use of Kerberos Delegation. If a better understanding of Kerberos has been on your “to-do” list, here’s a great opportunity to dive in and learn more. After covering Kerberos, the vulnerability and its exploit are explained, including its potential impact in a compromised environment. The presentation also includes a demonstration of the exploit in action. In the demonstration, we see how an attacker can escalate privileges from a compromised user account to gain access to additional sensitive systems. 

Key highlights:

• 2:28 – The Kerberos protocol 
• 4:48 – How a user proves their identity to the KDC  
• 15:00 – Kerberos “Authentication Delegation” and Microsoft S4U extension 
• 29:38 – The vulnerability and what it bypasses 
• 34:14 – Demonstration of the exploit 
• 57:00 – Microsoft patches

The Kerberos protocol  

To get started, having a high-level understanding of the Kerberos protocol is important.

Here’s a brief overview: 

• The Kerberos protocol is a ticket-based authentication protocol, which means it’s used to prove users are who they say they are to other entities in their environment. For example, if a user wants to connect to a service, like a file share, or a database or a web application, they can use Kerberos to authenticate themselves.  
• The protocol was originally developed at MIT and for the purpose of this webinar, we’re going to focus on how it’s used in a Windows environment.  
• Kerberos uses symmetric key cryptography to avoid risks associated with private and public keys. Each user has their own secret key and diagram, making it easy to see how the user has their red secret key and the service has its own secret key in green. The secret key is the entity’s password hash and because each user is the only one with their password, they should be the only one able to make that hash. In other words, if a user has the secret, they can prove their identity. 
• Kerberos has a central authority called the key distribution center (KDC). In a Windows environment, this is the domain controller. The KDC also holds a copy of everyone’s secret key, along with its own secret key, the service’s green secret key and any other entities in the environment, it has a copy of their secret key as well. A user can prove to the KDC that they control the secret key. And if the KDC accepts this proof, it will return a ticket and these tickets are used as proof to authenticate themselves to other services. 

How a user proves their identity to the KDC

The next piece is understanding how a user proves their identity to the KDC to get the ticket. The name of this process is the authentication service exchange. Here’s how the process works:

• The user authenticates themselves to the KDC 
• An encrypted timestamp proves they have access to the secret key (their hashed password) 
• If successful, the KDC returns with an AS_REP message granting the TGT 

Once a user is authenticated by the KDC, it’s easier to access other services within the environment, such as a file share or database through a ticket-granting service exchange. The steps in this process include:

• User requests a ticket for a service from the KDC 
• Encrypted timestamp proves they have access to the previously shared logon session key 
• The TGT contains the logon session for the KDC (since the KDC doesn’t save it)  
• If successful, the KDC returns with a TGS_REP message and produces a service ticket  

After the user receives the TGT and the service ticket, the third step in the process is the client/server exchange. The steps involved in this process are:  

• User sends encrypted timestamp with service session key 
• The service decrypts the service ticket using its long-term key (proving the service ticket came from the KDC) 
• The service extracts the service session key and checks the encrypted timestamp 
• The service checks the signature in the PAC with its long-term key  
  • This supplies the user’s authentication data upfront 
  • Optionally, the PAC is sent to the KDC to confirm its signature is valid too 
• From there, authenticated communication can proceed 

Kerberos delegation 

The Kerberos protocol covers one user connecting to one service. But it gets more complicated when it comes to different services connecting to one another, such as a web application connecting to a database.  

For this type of connection, the Kerberos delegation is used. The delegation enables one service to impersonate a user when connecting to another server, meaning the service authenticates as a user and is authorized as a user. Using the web application example above, some ways this may be done include for a web application writing to a database or reading from a file share.  

Types of Kerberos delegation include:

• Unconstrained delegation 
  • “Trust the computer for delegation to any service (Kerberos only)” 
  • The user’s TGT is embedded into the service ticket 
  • This type of delegation is not recommended and if you find it within your environment, it’s important to turn it off  
• “Classic” constrained delegation 
  • While unconstrained delegation means this service can delegate authentication to any service, constrained delegation means this service can delegate authentication to only these services  
  • With protocol transition 
  • Without protocol transition 
• Resource-based constrained delegation  

With constrained delegation, one service can get a ticket to another service impersonating a user in the S4U2Proxy exchange. Here are the steps in the process:

• One service obtains a service ticket to another service as a user, without needing that user’s TGT 
• The first service presents the user’s service ticket as evidence, along with the services’ own TGT 
• This is done “without protocol transition” because it assumes the user authenticated to the first service using Kerberos 

If the user hasn’t authenticated to the first service in the first place, they can delegate authentication through the S4U2Self exchange. Here’s what this process looks like:

• Obtains a service ticket to itself as a user, without needing that user’s service ticket 
• Required when the user authenticates to the first service through another protocol  
  • NTLM v2 
• Slight modification of the ticket-granting exchange 
• With the newly obtained service ticket, the first service can perform the S4U2Proxy exchange 

Because it’s pretty powerful functionality to be able to get another service ticket on behalf of another user and protections are in place within constrained delegation. Protections include:

• Allowing and disallowing protocol transition 
  • If you trust the service to perform the protocol transition, you trust it to impersonate users who never connected to the service  
  • “TrustedToAuthForDelegation” in Active Directory 
• Protected users and sensitive accounts 
  • Accounts can be protected from delegation entirely 
  • Protected users groups  
  • “Account is sensitive and can’t be delegated” 
• Enforcing constrained delegation lists 
  • It’s constrained delegation for a reason  

Here’s a simplified overview and recap of Kerberos delegation:

• Service1 sends an authentication service request with a timestamp encrypted with Service1’s hash to obtain a TGT 
• The KDC sends a ticket-granting ticket for Service1 
• Service1 sends a S4U2Self request for the target user, sending Service1’s TGT 
• Service user for the target user sent to Service1 by the KDC 
• Service1 sends a S4U2Proxy request for the user for Service2, sending the service ticket 
• KDC sends the service ticket as the target user for Service2 
• Request is sent to Service2 using the service ticket to impersonate the target user 

The vulnerability and what it bypasses 

An example of a vulnerability in the Kerberos protocol is when the service ticket is encrypted with the service’s own key. All the protections can be bypassed because the service always has its own secret key.  

Here’s an overview of what the attack would look like:

• The attacker sends an authentication service request with a timestamp encrypted with Service1’s hash to obtain a TGT 
• The KDC sends a ticket-granting ticket for Service1 to the attacker 
• The attackers sends a S4U2Self request for the target user, sending Service1’s TGT 
• The KDC sends a non-forwardable service ticket for the target user to Service1 
• The attacker decrypts the service ticket, sets the forwardable flag, and re-encrypts the service ticket 
• The attacker then sends a S4U2Proxy request for the user for Service2, sending the modified service ticket 
• The KDC observes that the ticket is forwardable and checks if there is a constrained delegation trust relationship between Service1 and Service2 and the check succeeds 
• The KDC sends the service ticket as the target user for the victim service 
• The attacker sends a request to the victim service to impersonate the target user 
• The victim service processes the request under the protected user’s authorization  

In this type of attack, the protections bypassed include:

• Bypassed TrustToAuthForDelegation 
  • Even if protocol transition is disallowed (i.e. Service1 is configured with “- Use Kerberos only”), they can still impersonate users 
  • No user needs to connect to Service1 to impersonate them  
• Impersonating “protected” and “sensitive” users 
  • Any user in the domain can be impersonated  

Microsoft patches 

Microsoft has implemented several fixes for this Kerberos vulnerability, including:

• November 10, 2020 
  • Microsoft publicly announces CVE-2020-17049 
  • Initial patch enables “ticket signatures” in the PAC 
• December 8, 2020 
  • The “ticket signatures” patch ported to Windows Server 2008 SP2 and Windows Server 2008 R2 
  • NetSPI blogs published 
  • Exploitt published as addition to Impacket 
• February 9, 2021 
  • “Enforcement mode” of ticket signatures is enabled 

Learn more about CVE-2020-17049: Kerberos Bronze Bit Attack 

If you’re interested in learning more about CVE-2020-17049: Kerberos Bronze Bit Attack, the risks associated, and how to protect your business, NetSPI has published several articles on the topic, linked below.

• CVE-2020-17049: Kerberos Bronze Bit Attack – Theory 
• CVE-2020-17049: Kerberos Bronze Bit Attack – Overview 
• CVE-2020-17049: Kerberos Bronze Bit Attack – Practical Exploitation