SecureAuth: Impacket Release v0.9.23

In December 2020, another Kerberos authentication vulnerability was made public, the Kerberos Bronze Bit Attack(CVE-2020-17049). Jake Karnes, Managing Consultant at NetSPI revealed his research after Microsoft released a patch to fix it. The Kerberos Bronze Bit attack was named in the spirit of the widely known Golden Ticket and Silver Ticketattacks and exists in the way the Key Distribution Center handles service tickets and determines whether or not they can be used for delegation.

Let’s start with some Kerberos fundamentals. In general terms, delegation refers to the ability of a service account to act on behalf of a user account to access resources with the access privileges of the latter. The most common example is a web application impersonating a user when it accesses a backend database and retrieves some data under the user’s authority.

Microsoft offers two types of delegation: without restrictions, known as Unconstrained Delegation, and restricted to only certain services, which comes in two flavors: Constrained Delegation and Resource-Based Constrained Delegation. The Kerberos protocol, by itself, doesn’t have the ability to restrict delegation to a specific group of services. For this reason, Microsoft implemented two extensions that allow achieving this behavior:  Service for User to Self (S4U2self) and Service for User to Proxy (S4U2proxy).

The Bronze Bit Attack uses both protocols. First, it obtains a service ticket for a targeted user to a compromised service via S4U2self. Then, it tampers this service ticket modifying the forwardable flag. With this tampered ticket, it uses S4U2proxy to obtain a service ticket for the targeted user to the targeted service. Finally, with the last service ticket, the attacker can impersonate the targeted user.

So, surely you are wondering why is this possible? The answer: the forwardable flag is only protected by encrypting the service ticket with the first service’s password hash. If an attacker manages to compromise this service, it’s game over (unless you’re patched). They will be able to decrypt the ticket and flip the flag bit.

@jakekarnes42 used Impacket for the attack implementation and opened the pull request (PR) #1013 that added a new force-forwardable flag to getST.py. Thanks Jake, for using Impacket for this great implementation of the attack!

If you are interested in knowing more details about this, you can check this great series of posts from Jake here: overview, theory and exploitation.

Read the full article here: https://www.secureauth.com/blog/now-available-impacket-release-v0-9-23/