Kerberos V5 attacks

1. Introduction

Kerberos V5 is a credential-based network authentication protocol, designed ¹ to provide strong authentication for client/server applications using symmetric (secret) key cryptography [1]. This protocol relies on a trusted third party, known as the Key Distribution Center (KDC), to negotiate shared session keys between clients and services, thereby facilitating mutual authentication.

On the 5th Jun 2023, was released version 1.21 of Kerberos 5 (krb5-1.21)². Beginning with release 1.20, the Key Distribution Center (KDC) started including minimal PACs ³ in tickets instead of AD-SIGNEDPATH authdata ⁴. This change was made to improve the security and efficiency of the protocol. S4U requests ⁵ (protocol transition and constrained delegation) must now contain valid PACs in the incoming tickets.

Beginning with release 1.21, service ticket PACs will contain a new KDC checksum buffer ⁶. This change was implemented to mitigate a hash collision attack against the old KDC checksum, enhancing the security of the protocol. However, this update has implications for mixed environments: if only some KDCs in a realm have been upgraded to versions 1.20 or 1.21, the upgraded KDCs will reject S4U requests containing tickets from non-upgraded KDCs and vice versa. This could potentially disrupt service in environments where not all KDCs are upgraded simultaneously [2].

Kerberos is widely used to authenticate service requests between trusted hosts across untrusted networks, such as the internet. It ensures that both the client and server verify each other’s identity before transmitting application data. The client must specify the principal name of the server, and the server’s identity must match that principal name exactly. If there’s a mismatch or if the client specifies NULL for the server’s principal name, the authentication process fails, preventing unauthorized access [1].

Kerberos is a computer network security protocol that authenticates service requests between two or more trusted hosts across an untrusted network, like the internet. It uses secret-key cryptography and a trusted third party for authenticating client-server applications and verifying users’ identities [3].

The Kerberos V5 protocol provides a mechanism for mutual authentication between a client and a server before application data is transmitted between them [4]. The Kerberos protocol requires mutual authentication and supports it remotely. The client must specify the principal name of the server, and the server’s identity must match that principal name exactly. If the client specifies NULL for the server’s principal name or if the principal name doesn’t match the server, the call will fail [5].

2. PKINIT

PKINIT ⁷ is an acronym for Public Key Cryptography for Initial Authentication in Kerberos. It is a set of protocol extensions for Kerberos⁸ that seamlessly integrates public key cryptography into the initial authentication exchange. This integration is achieved by utilizing asymmetric-key signature and/or encryption algorithms in pre-authentication data fields [6].

The primary motivation behind the development of PKINIT was to overcome the limitations of the traditional Kerberos protocol, which relied heavily on symmetric key cryptography. While symmetric key cryptography offers advantages in terms of computational efficiency, it suffers from key distribution problems. In a large network with numerous clients and services, securely distributing and managing symmetric keys can become a significant challenge.

PKINIT addresses this challenge by leveraging the strengths of public key cryptography. In PKINIT, a client proves its identity to the Key Distribution Center (KDC) by signing a timestamp with its private key. The KDC, which has a copy of the client’s public key, can verify the signature to authenticate the client. This eliminates the need for the client and KDC to share a symmetric key in advance.

Furthermore, PKINIT enhances the security of the Kerberos protocol by providing stronger resistance against password guessing attacks. In the traditional Kerberos protocol, an attacker could potentially compromise a client’s password by capturing the client’s authentication traffic and performing an offline dictionary attack. With PKINIT, this attack is no longer feasible because the client’s private key is never transmitted over the network.

However, it’s important to note that while PKINIT improves the security and scalability of Kerberos, it also introduces new challenges. For instance, the KDC must now manage a database of public keys or certificates, which can be a complex task in a large network. Additionally, the use of public key cryptography introduces additional computational overhead, which can impact the performance of the Kerberos protocol.

3. PAC and vulnerabilities

The PAC stands for Privilege Attribute Certificate. It’s a Microsoft extension to the Kerberos protocol. The PAC contains various types of authorization data, including the user’s group membership data and other information. When the KDC issues a ticket, it includes the PAC in the ticket. This means that when a client presents a ticket to a server, the server can extract the PAC from the ticket and use it to determine the client’s access rights.

There have been some known attacks on the Kerberos protocol after 2022. In November 8, 2022, Windows released updates to address security bypass and elevation of privilege vulnerabilities with Privilege Attribute Certificate (PAC) signatures. This security update addresses Kerberos vulnerabilities where an attacker could digitally alter PAC signatures, raising their privileges [7]. Another vulnerability addressed by the November 8, 2022 Windows updates is related to Authentication Negotiation by using weak RC4-HMAC negotiation [8] (refer to CVE-2022-37967 [7] and CVE-2022-37966 [8]).

4. Linux implementations of Kerberos

On Linux, the krb5-pkinit package contains the PKINIT plugin, which allows clients to obtain initial credentials from a Key Distribution Center (KDC) using a private key and a certificate [9]. This package is part of the larger Kerberos V5 software suite available for Linux systems, which provides a comprehensive implementation of the Kerberos protocol.

The Kerberos V5 software suite includes libraries for Kerberos 5, utilities for managing Kerberos databases, user and administrative utilities, and a PAM (Pluggable Authentication Modules) module for integrating Kerberos authentication with other system services [9]. The suite also includes the KDC itself, which can be run as a service on a Linux server to provide authentication services for a network of clients.

The implementation of Kerberos in Linux is highly configurable, allowing for a wide range of deployment scenarios. For example, the krb5.conf configuration file allows administrators to specify the default realm, the locations of KDCs and admin servers, logging settings, and many other options [10]. The kadmin utility provides a command-line interface for managing the Kerberos database, including adding and deleting principals, changing passwords, and modifying policy settings [11].

In addition to the standard Kerberos V5 software suite, there are also several other Kerberos-related packages available for Linux. These include krb5-user, which provides basic user programs such as kinit, klist, and kdestroy; krb5-doc, which provides the Kerberos V5 Installation Guide and other documentation; and krb5-kdc-ldap, which allows the KDC to use an LDAP directory as its database backend [12].

Despite the robustness of the Kerberos implementation in Linux, it is not without its challenges. For example, integrating Kerberos with other authentication systems can be complex, and managing Kerberos tickets can be difficult for end users. However, with careful planning and configuration, Kerberos can provide a powerful and secure authentication solution for Linux environments.

5. Implementations for wireless systems

Wang et al. (2010) [13] proposed a new key establishment scheme for wireless sensor networks. They employed LU Composition techniques ⁹ for mutual authenticated pairwise key establishment and integrated LU Matrix with Elliptic Curve Diffie-Hellman for anonymous pathkey establishment. This scheme was found to be efficient in achieving group key agreement and management [13].

Kerberos authentication has been studied and implemented in wireless systems also, particularly in wireless sensor networks. Siddique (2012) [14] proposed an authentication mechanism in wireless sensor networks using the Kerberos authentication scheme. This scheme provides a centralized authentication server, known as the Key Distribution Center (KDC), which authenticates users by providing them with a ticket to grant requests to the base station [14].

In another study, Pak Song-Ho et al. (2016) [15] proposed a PKINIT_AS Kerberos V5 authentication system that uses public key cryptography. They also discussed a method to implement the gssapi_krb authentication method and secure Internet service using it in IPSec VPN [15].

6. Simplified sequence Diagram and Golden Ticket attack

The simplified flow to get a service ticket with a focus on the PKINIT portion is as below :

 

6.1. Golden ticket attack

A “Golden Ticket” attack is a type of attack on the Kerberos protocol where an attacker with domain admin rights can compromise the KRBTGT account¹⁰. Using the KRBTGT account, a malicieous actor can create a Kerberos ticket granting ticket (TGT) that provides authorization to any resource and set the ticket expiration to any arbitrary time. This fake TGT is called a “Golden Ticket” and allows attackers to achieve network persistence [16] [17] [18] [19].

 

 

A threat actor with a valid KRBTGT account hash can create a forged Golden Ticket using an open-source tool such as Mimikatz. Actors may also use DCSync, a Mimikatz feature, to obtain the security identifier (SID) of the KRBTGT account and NTLM hash using the. Threat actors then use these hashes to create their Golden Ticket and potentially run a Pass the Ticket (PtT) attack [20], moving laterally within an organization’s AD environment.

A Golden Ticket attack and a Silver Ticket attack are two different types of attacks that exploit the Kerberos authentication system :

1. Golden Ticket Attack: This attack involves the creation of a Kerberos Ticket Granting Ticket (TGT) by an attacker who has gained access to the Key Distribution Center Service Account (KRBTGT) hash. The attacker can create a TGT with any user privileges, including domain administrator rights, and set the ticket’s lifetime to an arbitrary length. This allows the attacker to maintain persistence in the network and access any resource in the domain.

2. Silver Ticket Attack: This attack [21] is more targeted and involves the creation of a Kerberos service ticket (TGS) by an attacker who has gained access to a service account’s NTLM hash. The attacker can create a service ticket with any user privileges for a specific service on a specific server. While this attack is more limited in scope compared to the Golden Ticket attack, it is also harder to detect because the forged ticket does not need to be validated by the domain controller.

In both cases, the attacks exploit the trust that the Kerberos protocol places in its tickets, allowing attackers to impersonate any user and gain unauthorized access to resources.

 

7. Implementation of Kerberos protocol in Mermaid language

In mermaid code we have below a simplified version of kerberos protocol :

participant C as Client 
participant AS as Authentication Server 
participant TGS as Ticket Granting Server 
participant S as Server 
C->>AS: Request TGT 
AS-->>C: TGT and Session Key 
C->>TGS: Request Service Ticket 
TGS-->>C: Service Ticket 
C->>S: Request Service 
S-->>C: Provide Service

8. Kerberos V4 and V5: history

Version 4 of Kerberos protocol was primarily designed by Steve Miller and Clifford Neuman [1] and ended in 2006 due to various vulnerabilities ^11 12. Clifford Neuman and John Kohl published [22] version 5 in 1993 with the intention of overcoming existing limitations and security problems.

Let’s review the sequence diagram of the original V4 version : K is the key and Kc,s the ticket. Once the authentication is established, the client and server share a common session key Kc,s, which has never been transmitted over the network without being encrypted. In version 4, the 5 steps to get a tickets were :

Version 5 appeared as RFC 1510 ¹³, which was then made obsoleted by RFC 4120 ¹⁴ in 2005.

9. Kerberoasting

Kerberoasting [23] [24] [25] is a technique used by attackers to crack the passwords of service accounts in a Windows domain. In a typical Kerberos setup, a Ticket Granting Service (TGS) ticket is used to authenticate to services in a domain. When a user requests access to a service, the Key Distribution Center (KDC) issues a TGS ticket, which is encrypted with the service account’s password.

In a Kerberoasting attack ¹⁵, an attacker with access to a valid Kerberos ticket (even a low-privileged user) can request a TGS ticket for any service. Since the TGS ticket is encrypted with the service account’s password, the attacker can then take this ticket and attempt to crack it offline, without any risk of detection. If the service account’s password is weak, the attacker can crack the password and gain unauthorized access to the service :

References