The Kerberos protocol is a computer network protocol based on a third-party trusted host. It allows two entities to prove their identity in a secure way in an insecure network environment (which may be eavesdropped or replayed).
Simply put, there is a secret between A and B, and A needs to prove to B that he is A.
The direct way is that A uses the secret as the secret key to encrypt the text to generate the ciphertext, sends the ciphertext and the text together to B, and then B uses the secret to decrypt the plaintext, and compares the plaintext with the text. If they are consistent, it proves to be A.
But in the network, ciphertext and text are likely to be stolen. As long as there is enough time, the secret key can always be cracked. Therefore, such long-term valid secret keys cannot be used.
Change to a short-term temporary key. Then this temporary key needs to be provided by a third-party trusted organization (KDC).
At this point, the three dog heads of kerberbos have arrived, Client, Server, and KDC.
We just said that because in the network, it is necessary to use a temporary secret key to replace the long-term valid secret key. There are two concepts here.
Long-term Key/Master Key
Some keys that remain unchanged for a long time, such as your password and NTLM-Hash stored in the computer. Such a Key is called a Long-term Key, also called a Master Key. Such a Key should not be transmitted on the network because it is easily intercepted and decrypted.
Short-term Key/Session Key
A short-term temporary Key replaces the Master Key. This Key is called a Short-term Key or Session Key. Use Session Key to encrypt data that needs to be transmitted over the network. Because this key is only valid for a period of time, even if the encrypted data packet is cracked by a hacker, when he calculates the key, the key has already expired.
Below we introduce several concepts through a picture.
Domain Controller (DC), referred to as DC, is a computer that realizes the unified management of users and computers.
KeyDistribution Center (KDC for short) is installed in the domain controller by default.
Authentication Service, referred to as AS, is used for KDC to authenticate Clients.
Ticket Grantng Service, TGS for short, is used by KDC to distribute Session Key to Client and Server.
Active Directory (AD for short) is used to store information about users, user groups, and domains.
Client Client refers to the user.
Server server, it may be a computer or a service.
We start to look at the pictures and talk, first walk through this process roughly. From Figure 1, we can see that it is roughly divided into 6 steps.
First, the Client requests the DC to access the Server, and the DC determines whether the Client is trustworthy. How to judge? Go to AD to find and distinguish Client in turn. This is the work done by the AS service.
After passing the authentication, the TGT is returned to the Client, and the Client gets the TGT (Ticket Granting Ticket).
The client continues to request the DC to access the server with the TGT, and the TGS judges whether the client has the access authority through the TGT in the client message.
If so, give the Client permission to access the Server ticket, also called ST (Service Ticket).
The client gets the ticket and then visits the server, and the ticket is only for this server.
Server and Client establish communication.
To access the server, the client first goes to the AS to authenticate its identity. After passing the authentication, the AS returns a TGT to the Client. The Client then holds the TGT and judges in the TGS whether it has permission to access the Server. If there is permission, TGT exchanges into Ticket, which is used by Client to communicate with Server.
We briefly walked through the kerberos authentication process. Below we are divided into three-step authentication (Authentication) detailed interpretation.
Client and AS authentication, we carefully analyze the following figure.
First, the Client must send its own information to request a TGT ticket from the AS.
This request is called KRB_AS_REQ: the client’s hash value NTLM-hash encrypts the data (timestamp, client-info, server-info).
After the client sends the identity information to the AS, the AS will first request the AD to ask if there is such a user. If so, it will take out its NTLM hash, and then generate a random key called Session-Key as (temporary secret Session-Key). And use Client NTLM-hash to encrypt Session-key as as part of the content.
Another part of the content is TGT: Use the NTLM-hash of a specific account of KDC to encrypt Session-key as, timestamp, and Client-info. This specific account is krbtgt (automatically generated when the domain controller is created).
Then reply these two parts to the Client. I.e. KRB_AS_REP
At this point, the first step of kerberos request is completed.
Client and TGS certification, we carefully analyze the following figure.
Client receives the reply KRB_AS_REP, first decrypts it with its Client NTLM-hash to get Session-Key as, and uses Session-Key as to encrypt data (timestamp, Client-info, Server-info) as part.
The TGT is encrypted with the NTLM of the krbtgt account, and the Client cannot decrypt it, so the TGT will continue to be sent to TGS as another part.
The two parts are KRB_TGS_REQ.
TGS receives the request, uses krbtgt NTLM-hash to decrypt the TGT first to obtain Session-key as, timestamp, Client-info, and Server-info. Then use Session-key as to decrypt the first part of the content to get Client-info and timestamp.
Compare the timestamps obtained in the two parts. If the timestamp is too long from the current time, re-authentication is required.
TGS will also compare the information of this Client with the Client information in TGT. If the two are equal, it will continue to determine whether the Client has permission to access the Server. If there is no problem, the authentication is successful and return ST (also called Ticket) to Client.
After the authentication is passed, TGS will generate a random secret key (Session-Key tgs). Reply to the client with two parts of KRB_TGS_REP.
Part: Session-key as encrypted Session-key tgs
Part of ST (ticket): Server NTLM-hash encrypted data (Session-key tgs, timestamp, Client-info)
Note that Session-key tgs is mainly used for the communication between Client and Server.
At this point, the communication between the Client and KDC is over, and then the communication with the Server is carried out.
Client and Servre certification, we carefully analyze the following figure.
Client receives KRB_TGS_REP and decrypts Session tgs first. Then use Session tgs to encrypt Client-info and timestamp as part of the content. ST cannot decrypt it because it uses Server NTLM-hash encryption. Send it to the Server intact. The two parts are sent to the server as KRB_AP_REQ.
Server receives the request, decrypts ST with its own Server NTLM, gets Session tgs, and decrypts Client-info and timestamp. Then compare with ST’s Client-info and timestamp. The timestamp is generally 8 hours. After the verification is passed, reply KRB_AP_REP to establish communication.
So far. The kerberos authentication process ends.
If the NTLM Hash of krbtgt is leaked, the TGT can be decrypted or even forged. The fake TGT is called a gold ticket.
ST (Ticket) is encrypted by the NTLM Hash of the Server. If the Hash is leaked, the Ticket can be decrypted or even forged. The counterfeit ticket is called a silver ticket.
Privilege Attribute Certificate (PAC for short), in order to increase the authority certification in the certification process. The PAC will be placed in the TGT and sent to the Client, and then sent to the TGS by the Client.
The ms14-068 vulnerability is an error based on PAC authentication, which allows ordinary users in the domain to forge credentials and raise their rights to administrator privileges.