Summary of Kerberos KDC domain privilege elevation vulnerability

Summary of Kerberos KDC domain privilege elevation vulnerability

0x00 The origin of the vulnerability

Windows Kerberos has a security vulnerability in the verification process of PAC (Privilege Attribute Certificate) in kerberos tickets. Low-authority certified remote attackers can use this vulnerability to forge a PAC and pass the verification of Kerberos KDC (Key Distribution Center). Success allows attackers to elevate their rights and obtain domain management rights.

0x01 vulnerability description

(1) Simple mutual authentication

When A sends information to B, an Authenticator (authentication code, the data structure = identity information + timestamp) is added to authenticate each other. Before starting verification, A and B already have a key that only two people know)

The following is the workflow:

1. A encrypts [Information + Authenticator (identity information + timestamp)] with the key and sends it to B

2. B decrypts the Authenticator sent by A with the key, and records the timestamp contained in it. B compares this timestamp with his current time. If the time difference is greater than a certain value (the default is 5 minutes under windows), B believes that the information was not sent by A, and refuses subsequent verification. If this time difference is less than the set value, B should check whether there is an Authenticator with an earlier timestamp in the past 5 minutes. If not, B thinks that the information is indeed sent by A. So far, B has verified A

3. B encrypts the timestamp in the Authenticator with a password and sends it back to A to prove that he is indeed B

4. After A received it, decrypted the timestamp, and after his own comparison, confirmed that the other party was indeed B, and thus completed the verification of A to B

(2) Kerberos description

1. User Sue logs in to his client, and the client sends a TGT (Ticket Granting Ticker) request to the authentication server to the KDC service
2. The authentication server confirms the user's access rights and session key. The authentication server uses the user password HASH as the KEY to encrypt the request and then sends it to the client.
3. The client subsequently uses this password to decrypt future messages. After the decryption is successful, the user uses TGT to go to TGS to request a service ticket
4. TGS returns a service ticket
5. User takes service ticket to authenticate
6. Start the client and server session

(3) Vulnerability description

There is a point in the above picture that does not indicate that both the TGT and the service ticket contain a PAC (Privilege Attribute Certificate). The PAC contains two pieces of information, one for the user SID and the other for the user's group.

When a user logs into the KDC verification service, the service verifies the signature in the PAC. If the signature carried by the PAC indicates that "Sue" is a member of the "Domain Control Administrator" security group, then the created login session session will treat Sue as the administrator. There is a problem with such authentication, and an attacker can forge an identity.

(4) Vulnerability hazard

The main hazard of this loophole is that the identity of an ordinary domain user can forge the identity of a domain administrator.
If there is no patch 3011780 on the machine, there may be a vulnerability that can be exploited maliciously.

Involved system:

Windows Server 2003
Windows Vista
Windows Server 2008
Windows 7
Windows Server 2008 R2
Windows 8 and Windows 8.1
Windows Server 2012 and Windows Server 2012 R2
Server Core installation option

0x02 Vulnerability Principle

(1) PAC principle

After the Server receives the TGS sent by the Client, it should check the domain group where the Client declares in the TGS and the ACL on the Server, and then decide what resource access permissions to grant to the Client. Microsoft uses PAC to represent the domain group declared by Client in TGS. PAC (Privilege Attribute Certificate), privilege attribute certificate.

PAC contains Client's User SID and Group's SID. The PAC determines the Client ’s group attributes, which determines the Client ’s authority. The PAC also contains 2 signatures, NTLM with a key of krbtgt in order to ensure its own legitimacy. The content of the signature is in addition to the User SID and Group SID, and other parts of the PAC As part of the TGT, it is encrypted. The NTLM with the key krbtgt as the Client initiates an authentication request to the AS module of the KDC. When the AS returns to the TGT, it will generate a PAC based on the group of the Client, including the User SID and Group SID of the Client. And 2 signatures to ensure that the PAC is not tampered with

(2) The cause of the vulnerability

When the Client initiates an authentication request, by setting include-PAC to False, it returns that the TGT will not contain the PAC

When KDC verifies the PAC, although the signature algorithm at the tail of the PAC is required to be a signature algorithm with a Key in principle, Microsoft implements any signature algorithm, as long as the client specifies any signature algorithm, KDC The server will use the specified algorithm for signature verification. Therefore, any forged content can be legal, just add the MD5 value of the content as a signature (the first reason)

The PAC is not placed in the TGT, but elsewhere. The KDC can still correctly parse the PAC information that is not placed in the TGT. The PAC must be ciphertext. The KDC encrypted by the Key will take it from the Authenticator to subkey, decrypt the PAC information and verify the signature using the signature algorithm set by the client The second reason)

After the KDC verifies that the TGT lacking the PAC is successful, it then verifies the legality of the PAC that is not in the TGT. If both are successfully verified, the KDC takes out the User SID and Group SID in the PAC and re-uses the signature. The signature algorithm and key are exactly the same as when the inclue-pac flag is set to TRUE. Add the newly generated PAC to the decrypted TGT, and then re-encrypt to make a new TGT and send it to the Client, not TGS (the third reason)

0x03 exploit

When doing domain penetration testing, when we got an account of a common domain member, we wanted to continue to penetrate the domain and get domain control server permissions. If the domain control server has the MS14-068 vulnerability and is not patched, then we can use MS14-068 to quickly obtain domain control server permissions.

MS14-068 number CVE-2014-6324, patch is 3011780, if self-test can use command detection on the domain controller, if the return result is empty, it means the server has MS14-068

The following topology maps exist:

The domain user hack has logged in on the domain member host A. The administrator of the domain member host A obtained the user name, password, SID and other values ​​of the domain user hack through mimikatz, and the domain control has an MS14-068 vulnerability. Want to access domain control through the MS14-068 vulnerability.

1. Generate TGT

(1) Use the net config workstation command to view the name of the work domain

(2) Use ms14-068.exe to generate bills

The use of ms14-068 tools is as follows:

where -u domain member name @ domain name

     -s 域成员SID

     -d 域控制器地址

     -p 域成员密码

The only thing I do n’t know so far is the SID value of the domain member. Use the whoami -all command to view the SID value of the domain member:

so use the following command to generate a ticket:

2. Inject TGT

(1) On the domain member machine, first use the klist command to view your ticket information

(2) If there is a ticket, use the klist purge command to clean it up, otherwise it may lead to unsuccessful

(3) Use mimikatz for injection

(4) Check if the ticket is successfully injected

(5) Try to access the domain server

Successfully read the domain server C drive file and obtain domain control authority.

note:

1. When injecting bills, the machine cannot be 03 or xp, because mimikatz does not support the injection of these two machines
2. When obtaining domain users, domain user SIDs, passwords, and machines that can access the domain controller, the machine does not need to be in the domain (such as an attacker dialing into the intranet through a VPN, etc.), but it needs to point dns to the domain controller To resolve
3. When accessing the domain controller, you need to use the host name, not the IP