MS14-068 漏洞分析

1 漏洞简介

On 2014.11.18, Microsoft released the MS14-068 patch, fixing a serious vulnerability that affected all versions of Windows servers. Used to resolve a Microsoft Windows Kerberos KDC vulnerability that allows hackers to increase permissions of any normal user to become domain administrators. Attackers can use these elevated permissions to control all computers in the domain, including domain servers.

2 原理分析

2.1 kerberos 认证流程

After the Server receives the TGS sent by the Client, it must compare the domain group that the Client declares in the TGS and compares it with the ACL on the Server, and then decides what kind of resource access permissions to the Client.

Microsoft uses PAC to represent domain groups declared by Client in TGS. PAC (Privilege Attribute Certificate), privilege attribute certificate.

2.2 PAC

PAC contains the SID of the User of the Client and the SID of the Group. PAC determines the group attributes of the Client, that is, determines the permissions of the Client

In order to ensure its own legitimacy, PAC also contains 2 signatures. The Key is krbtgt's NTLM. In addition to User SID and Group SID, the signed content has other parts.

PAC is encrypted as part of TGT with the key krbtgt

Client initiates an authentication request to the AS module of KDC. When AS returns TGT, it generates a PAC based on the group where the Client is located, including the Client's User SID, Group SID, and 2 signatures to ensure that the PAC is not tampered with.

Send the PAC to the Client as part of the TGT.

When the Client uses TGT to initiate access to the Server service to the KDC's TGS module, the KDC's TGS module first decrypts the TGT and verifies the 2 signatures to verify the legitimacy of the PAC.

If verified, the KDC's TGS module replaces the old signature with 2 new signatures to ensure that the PAC is not tampered with. The first signed key isServer 的 NTLMand the second isServer 与 Client 的临时会话密钥（Server Session Key）.

The re-signed PAC is placed in the issued access ticket TGS and is encrypted and protected using the Server's NTLM as the key.

After the Server receives the TGS from the Client, it decrypts the TGS to verify the legitimacy, verifies the 2 signatures in the PAC, confirms the legitimacy of the PAC, and then confirms the access rights of the Client.

2.3 漏洞成因

Client When initiating an authentication request, by setting include-PAC to False, the returned TGT will not include the PAC.

When KDC verifies PAC, although in principle, for the signature algorithm at the tail of the PAC, it is required to be a signature algorithm with a Key, Microsoft allows any signature algorithm in implementation. As long as the client specifies any signature algorithm, the KDC server will use the specified algorithm for signature verification.

Therefore, any forged content can be legal, and the value of the content can be directly added as the signature (the first reason)

The PAC is not placed in the TGT, elsewhere. KDC can still correctly parse PAC information that is not placed in TGT

The PAC must be ciphertext, encrypted by Key

KDC will take out the Session Key from Authenticator, decrypt the PAC information and use the signature algorithm set by the client to verify the signature (the second reason)

After KDC successfully verifying the TGT without PAC, it will verify the legitimacy of the PAC not in the TGT.

If both of the two are successfully verified, KDC takes out the User SID and Group SID in the PAC and reuses it for signature. The signature algorithm and key are exactly the same as when setting the inclue-pac flag to TRUE. Add the newly generated PAC to the decrypted TGT, and then re-encrypt and create a brand new TGT and send it to the Client, not the ST (the third reason)