Enterprise Certificate Authority - Revision history

Tom: /* Elevation of Privilege */

2023-02-09T01:32:57Z

‎Elevation of Privilege

Tom: /* Problems */

2023-02-09T01:31:50Z

‎Problems

Tom: /* Problems */

2023-02-09T01:23:50Z

‎Problems

Tom: /* Spoofing attacks */

2023-02-09T00:37:31Z

‎Spoofing attacks

Tom: /* Spoofing attacks */

2023-02-09T00:31:26Z

‎Spoofing attacks

Tom: /* Spoofing attacks */

2023-02-09T00:29:49Z

‎Spoofing attacks

Tom: /* Solutions */

2023-02-09T00:27:01Z

‎Solutions

Tom: /* Spoofing attacks */

2023-02-09T00:26:20Z

‎Spoofing attacks

Tom: /* Solutions */

2023-02-09T00:17:38Z

‎Solutions

Tom: /* Problems */

2023-02-09T00:14:28Z

‎Problems

@@ Line 32: / Line 32: @@
 These attacks depend on the privilege level of the network facing code.
 * If the functionality of the network facing code is limited to simply terminating the link, the extent of damage will be limited.
 ==References==
 [[Category: Trust]]

@@ Line 15: / Line 15: @@
 * [https://nvd.nist.gov/vuln/detail/CVE-2023-24576 CVE-2023-24576] EMC NetWorker may potentially be vulnerable to an unauthenticated remote code execution vulnerability in the Networker Client execution service
 * [https://nvd.nist.gov/vuln/detail/CVE-2022-23538 CVE-2022-23538] Leakage of client certs when github uses an intermediate server.
+* If a malicious client can call into a server using the client authentication certificate for the user it will have full access to the server's resources. This cannot be stopped by a trustworthy client in an unmanaged phone.
 ==Solutions==

@@ Line 14: / Line 14: @@
 Other attacks are direct against the network facing code such as these:
 * [https://nvd.nist.gov/vuln/detail/CVE-2023-24576 CVE-2023-24576] EMC NetWorker may potentially be vulnerable to an unauthenticated remote code execution vulnerability in the Networker Client execution service
+* [https://nvd.nist.gov/vuln/detail/CVE-2022-23538 CVE-2022-23538] Leakage of client certs when github uses an intermediate server.
+*

@@ Line 22: / Line 22: @@
 In general, the solutions are to more securely tie the [[MTLS]] authentication process to the principal ID that is used to grant access to specific enterprise resources.
 * [https://social.technet.microsoft.com/wiki/contents/articles/53249.active-directory-certificate-services-enterprise-ca-architecture.aspx Active Directory Certificate Services: Enterprise CA Architecture]
-Enterprise Certificate Authorities (CA) will start adding a new non-critical extension with Object Identifier (OID) (1.3.6.1.4.1.311.25.2) by default in all the certificates issued against online templates after you install the May 10, 2022 Windows update. You can stop the addition of this extension by setting the 0x00080000 bit in the msPKI-Enrollment-Flag value of the corresponding template.
+Enterprise Certificate Authorities (CA) will start adding a new non-critical extension with Object Identifier (OID) (1.3.6.1.4.1.311.25.2) by default in all the certificates issued against online templates after you install the May 10, 2022 Windows update. You can stop the addition of this extension by setting the 0x00080000 bit in the msPKI-Enrollment-Flag value of the corresponding template. This is above and beyond OID 1.3.6.1.4.1.311.25.1 szOID_NTDS_REPLICATION and is Microsoft specific.  Not clear how this solution might apply to Unix based servers.
 * [https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16 KB5014754:] Certificate-based authentication changes on Windows domain controllers
 When a server application requires client authentication, Schannel automatically attempts to map the certificate that the TLS client supplies to a user account. You can authenticate users who sign in with a client certificate by creating mappings that relate the certificate information to a Windows user account. After you create and enable a certificate mapping, each time a client presents a client certificate, your server application automatically associates that user with the appropriate Windows user account.

@@ Line 22: / Line 22: @@
 In general, the solutions are to more securely tie the [[MTLS]] authentication process to the principal ID that is used to grant access to specific enterprise resources.
 * [https://social.technet.microsoft.com/wiki/contents/articles/53249.active-directory-certificate-services-enterprise-ca-architecture.aspx Active Directory Certificate Services: Enterprise CA Architecture]
 * [https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16 KB5014754:] Certificate-based authentication changes on Windows domain controllers
 When a server application requires client authentication, Schannel automatically attempts to map the certificate that the TLS client supplies to a user account. You can authenticate users who sign in with a client certificate by creating mappings that relate the certificate information to a Windows user account. After you create and enable a certificate mapping, each time a client presents a client certificate, your server application automatically associates that user with the appropriate Windows user account.

@@ Line 12: / Line 12: @@
 * [https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26931 CVE-2022-26931] Successful exploitation of this vulnerability requires an attacker to prepare the target environment to improve exploit reliability.
 * [https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26923 CVE-2022-26923] A system is vulnerable only if both the Active Directory Certificate Services role and the Active Directory Domain Services role are installed on a server in the network. Note that they would not necessarily need to be on the same server.
 ==Solutions==