Kerberos: The Ticket Authentication Protocol
Introduction
Kerberos is a Layer 7 (Application Layer) client-server network authentication protocol. It lets clients securely authenticate to services/resources by using tickets, in an insecure network. It uses the User Datagram Protocol (UDP) as its transport layer protocol.
It was developed in the 1980s by MIT. The protocol was named after the three-headed dog of Hades, Cerberus.
Fun fact: The 3 dogs in the Kerberos logo represent the client, the KDC, and the service to access
With regards to encryption, Kerberos uses symmetric encryption i.e. the same key is used for encrypting and decrypting data. It supports the RC4, DES, AES 256 bit and AES 128-bit ciphers, where RC4 is the oldest and weakest
Kerberos is the default authentication method in Active Directory
The Kerberos server runs on the domain controller and it listens on port 88/UDP. It is also known as the Key Distribution Center (KDC) since it distributes tickets to clients. Since the KDC runs on the domain controller, it can fetch information (NT hash, SID, etc.) from the Active Directory Database.
The KDC consists of 2 parts:
- Authentication Server: Authenticates a client and issues a TGT to it
- Ticket Granting Service (TGS) Server: Verifies a client’s TGT and issues a TGS to it
As mentioned above, Kerberos uses tickets to authenticate clients to services/resources. There are 2 types of tickets:
- Ticket Granting Ticket (TGT): Issued by the Authentication Server to authenticate the client in the domain and to let them ask for a TGS later.
- Ticket Granting Service (TGS): Used to access services in the network. The client presents its TGT to the TGS Server so that it can receive the TGS for a specific service and then access it. Upon receiving a TGS, the client presents it to the service to access it.
By default, these tickets expire after 10 hours. This can be changed in the Group Policy Management Console.
The service account for the KDC is the krbtgt account. This account exists by default on the domain controller and cannot be deleted/modified. Its password is long and complex and is set by the system and changed periodically. The krbtgt account’s NT Hash is used to encrypt the TGTs.
To identify services in the domain, Kerberos uses Service Principal Names (SPNs). These unique identifiers are used to associate a service instance with a service account so that we can authenticate to the instance and manage it.
An example of the format of an SPN is
Hostname/Username.Domain.TLD:Port
Hostname -> Hostname of the computer running that service
Username -> Username of the service account
Port -> The port on which the service is listening
When using Kerberos, a special certificate is added to the TGT and TGS. It is known as the privileged attribute certificate (PAC) and it contains the privilege and information about the user (group memberships, SID, etc.) This is used by the service to confirm that the user is who they say they are. This is optional in Kerberos.
In Kerberos, a realm refers to the domain in which the KDC is used to issue tickets and authenticate users to services/resources.
Versions
Kerberos versions 1–3 were developed and used internally at MIT.
In the late 1980s, Kerberos version 4 was released to the public. The protocol had limited ticket features. It used the weak data encryption standard (DES) cipher. To identify hosts it used IP addresses and used the “receiver-makes-right” encoding system. The lifetime of a ticket had to be specified in units of 5 minutes and it did not support cross-realm authentication.
Kerberos version 5 was published in 1993. It appeared as RFC 1510 but was made obsolete by RFC 4120 in 2005. With regard to tickets, the protocol supports forwarding, renewing, and postdating. For encryption, it uses the advanced encryption standard (AES) cipher. This version supports all types of addresses and uses the ASN.1 encoding system. One can set explicit start and finish times allowing arbitrary lifetimes for tickets. It supports cross-realm authentication.
Authentication Process
- Once the client logs into their computer, it will send a ticket request to the KDC. The user’s computer will send the current time encrypted with the user’s NT Hash (Think of the NT hash as the key), their username, and the service they wish to access which will be krbtgt in this case. (AS_REQ)
- Upon receiving this request, the KDC checks if a user with that username exists in the domain. To do so, it will check the AD database. If it finds the user, it will fetch its NT hash and decrypt the time. If the time is found to be within 5 minutes of the DC’s clock time, it will proceed. This is to prevent replay attacks. The KDC will generate a TGT. This TGT contains the service name (krbtgt), the expiry date, a session key, a PAC, and the client’s username. Everything other than the service name is then encrypted with the NT hash of the krbtgt user. A copy of the session key is then encrypted with the user’s NT hash and these are sent back to the user. (AS_REP)
- The user’s computer will decrypt the copy of the session key using the user’s NT hash. Now to access a service, the client’s computer will send the TGT, the name of the service they wish to access, and an authenticator to the KDC. The authenticator refers to the client’s username and the current time which are encrypted with the session key. This is to prove that the client has the session key which could only be decrypted using their NT hash (TGS_REQ)
- Upon receiving this, the KDC will decrypt the TGT using the NT hash of the krbtgt user. By doing so, it will extract the session key and decrypt the authenticator. If this is successful, it proceeds. The KDC will then try to find the SPN for that service name and when it does, it will get the service account associated with it. It then generates a TGS. This TGS contains the service name, the expiry date, a new session key, the PAC from the TGT, and the client’s username. Everything other than the service name is then encrypted with the NT hash of the service account. A copy of the new session key is then encrypted with the user’s NT hash and these are sent back to the user. (TGS_REP)
- The client’s computer will send the TGS and an authenticator (client’s username and current time) which are encrypted with the new session key to the service instance. A new authenticator is to prove that the client has the new session key which could only be decrypted using their NT hash (AP_REQ)
- The service will decrypt the TGS by using its service account’s NT hash and extract the new session key and PAC. It will then decrypt the authenticator using the new session key. If this is successful, it proceeds
- To verify if this PAC is a legitimate one and has not been forged, the service sends this PAC to the KDC. (VERIFY_PAC)
- Upon receiving the PAC, the KDC checks if it is valid. If it is, the KDC sends a message to the server to let it know that it is valid. (PAC_VERIFY_RESPONSE)
- The service now knows the privileges of the user by reading the PAC and it has verified the user’s identity (The user was able to encrypt the authenticator using the session key which could only be decrypted using their NT hash). The user is now allowed access to the service instance (AP_REP)
All the steps other than AP_REQ and AP_REP, take place over the Kerberos protocol. These 2 steps take place over the protocol which the service instance supports.
Conclusion
Even though Kerberos seems to be more secure compared to NTLM, there are multiple flaws in the protocol that can allow the attacker to gain access to accounts and even take over the entire domain. We’ll talk about 5 attacks in the next writeup :)
Connect with me on LinkedIn 👉 https://www.linkedin.com/in/aravbudhiraja/
