.jpg)
Preface: On May 2022 Security Updates from Microsoft by introducing a new Object ID (OID) in new certificates to further fingerprint the user. This is done by embedding the user’s objectSid (SID) within the new szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2) OID. Certificate Templates with the new CT_FLAG_NO_SECURITY_EXTENSION (0x80000) flag set in the msPKI-Enrollment-Flag attribute will not embed the new szOID_NTDS_CA_SECURITY_EXT OID, perhaps those templates still have design weakness.
Background: Since Windows 2000, Microsoft has used the Kerberos protocol as the default authentication method in Windows, and it is an integral part of the Windows Active Directory (AD) service. However Kerberos Authentication has risks associated with the older NTLM protocol.
Beginning with Windows Server 2016, KDCs support a way of public key mapping. If the public key is provisioned for an account, then the KDC supports Kerberos PKInit explicitly using that key. Since there is no certificate validation, self-signed certificates are supported and authentication mechanism assurance is not supported.
*PKINIT is a preauthentication mechanism for Kerberos 5 which uses X.509 certificates to authenticate the KDC to clients and vice versa.
Vulnerability details: Microsoft Windows Kerberos could allow a remote authenticated attacker to gain elevated privileges on the system.
By default, domain users can enroll in the User certificate template, and domain computers can enroll in the Machine certificate template. Both certificate templates allow for client authentication. This means that the issued certificate can be used for authentication against the KDC via the PKINIT Kerberos extension.
When we use the certificate for authentication, the KDC tries to map the UPN from the certificate to a user. However, computer accounts do not have a UPN.Therefore, specify an alternative to SubjectAltRequireDns (CT_FLAG_SUBJECT_ALT_REQUIRE_DNS) instead.
According to non-patch version design, authorized low priviliges user had the “Validated write to DNS host name” permission.
If authorized user modify the dNSHostName property value from itself to other (UPN to another user’s UPN). The servicePrincipalName property value of low priviliges user will update to reflect new “dNSHostName” value.
So if attacker want to update the servicePrincipalName of low priviliges user, the updated values must also be compliant with the dNSHostName property. When attacker use his low priviliges account delete the “servicePrincipalName” vlaues that contain the “dNSHostName”. And update the DNSHostName property value of low priviliges user to domain controller (example: DC.xxx.local). So it will triggers the priviliges escalation.
Since vendor do not announce the details, however I beleive the design weakness of this kerberbos which shown in vulnerability was patched as part of the May 2022 Security Updates from Microsoft.