Pierluigi Paganini December 10, 2020

The proof-of-concept exploit code for the Kerberos Bronze Bit attack was published online, it allows intruders to bypass authentication and access sensitive network services

The proof-of-concept exploit code for the Kerberos Bronze Bit attack, tracked as CVE-2020-17049, was published online this week. The hacking technique could be exploited by attackers to bypass the Kerberos authentication protocol in Windows environments and access sensitive network-connected services.

Microsoft initially addressed the flaw for Bronze Bit attacks in the November 2020 Patch Tuesday, but some Windows 10 users started reporting Kerberos authentication issues.

“After installing KB4586786 on domain controllers (DCs) and read-only domain controllers (RODCs) in your environment, you might encounter Kerberos authentication issues,” reported Microsoft.  

This week, after Microsoft delivered the final patches for the security issue, the security expert Jake Karnes from NetSPI, published technical details of the vulnerability

Karnes explained that the Bronze Bit attack is a variation of the Golden Ticket attack discovered by Benjamin Delpy. and Silver Ticket attacks to bypass Kerberos authentication.

Unlike Golden Ticket, Silver Ticket, the Bronze Bit attack targets the Service for User to Self (S4U2self) and Service for User to Proxy (S4U2proxy) protocols that Microsoft added as extensions to the Kerberos protocol.

The attack scenario sees the intruders initially compromise one system on the targeted network and

An attacker who infected at least one system on a network and extracted password hashes can use the hashes to bypass and forge credentials to access other systems on the same network bypassing the Kerberos authentication protocol.

Using the service’s password hash, the attack leverages the S4U2self protocol to obtain a service ticket for a targeted user to the compromised service.

The service ticket is manipulated by flipping the “Forwardable” bit to 1, then it is used in the S4U2proxy protocol to obtain a service ticket for the targeted user to the targeted service.

The root caused of the attack is that the component of the Kerberos service ticket containing the Forwardable flag is not signed, and the Kerberos process is not able to detect service ticket manipulation.

“Look closely at where the Forwardable flag is located in the response. The service ticket’s Forwardable flag is encrypted with Service1’s long-term. The Forwardable flag is not in the signed PAC. Service1 is free to decrypt, set the Forwardable flag’s value to 1, and re-encrypt the service ticket. Because it’s not in the signed PAC, the KDC is unable to detect that the value has been tampered with.” reads the post published by Karnes.

Below the conclusions published by the expert:

“By flipping the forwardable bit, we’re bypassing two of the three protections:

1. We’ve bypassed the protection for TrustedToAuthForDelegation and the “Trust this computer for delegation to specified services only – Use Kerberos only” configuration. This protection is enforced by ensuring that any service ticket received in the S4U2self exchange is non-forwardable, unless the requesting service is TrustedToAuthForDelegation. By setting the forwardable flag ourselves, we’ve effectively removed this distinction and enabled the service to perform the protocol transition, as if the service were configured with the “Trust this computer for delegation to specified services only – Use any authentication protocol” option.
2. We’ve also bypassed the protection for accounts which do not allow delegation. Again, this is enforced by ensuring that any service ticket received in the S4U2self exchange on behalf of a protected account is non-forwardable. By converting this to a forwardable service ticket, the service can now delegate the account’s authentication as if there was no such protection.

Pierluigi Paganini

(SecurityAffairs – hacking, Kerberos Bronze Bit)

[adrotate banner=”5″]

[adrotate banner=”13″]