Difference between revisions of "Enterprise Certificate Authority"
(→Context) |
(→Elevation of Privilege) |
||
| (18 intermediate revisions by the same user not shown) | |||
| Line 6: | Line 6: | ||
* The most common form of [[Authentication]] is via [[Client Certificate]]s that bind the [[Entity]] [[Identifier]] with a [[Client Certificate]] that is used in a TCP connection using [[Mutual Authentication]] to carry the proof of possession, not only of the key of the server, but also of the key of the Client. | * The most common form of [[Authentication]] is via [[Client Certificate]]s that bind the [[Entity]] [[Identifier]] with a [[Client Certificate]] that is used in a TCP connection using [[Mutual Authentication]] to carry the proof of possession, not only of the key of the server, but also of the key of the Client. | ||
* The most common form of [[Mutual Authentication]] uses [[MTLS]] or mutual transportation layer security. | * The most common form of [[Mutual Authentication]] uses [[MTLS]] or mutual transportation layer security. | ||
| + | |||
| + | ==Problems== | ||
| + | In general, the problems are created by a mismatch between the [[MTLS]] authentication result and the identity of the principle in the enterprise network. There have been multiple vulnerabilities reported to the US Government the top three in 2022 are for Microsoft AD. | ||
| + | * [https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-34691 CVE-2022-34691] An authenticated user could manipulate attributes on computer accounts they own or manage, and acquire a certificate from Active Directory Certificate Services that would allow elevation of privilege to System. | ||
| + | * [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. | ||
| + | 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. | ||
| + | * 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== | ||
| + | |||
| + | ===Spoofing attacks=== | ||
| + | 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. 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. | ||
| + | |||
| + | Schannel will try to map each certificate mapping method you have enabled until one succeeds. Schannel tries to map the Service-For-User-To-Self (S4U2Self) mappings first. The Subject/Issuer, Issuer, and UPN certificate mappings are now considered weak and have been disabled by default. The bitmasked sum of the selected options determines the list of certificate mapping methods that are available. | ||
| + | |||
| + | ===Elevation of Privilege=== | ||
| + | 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. | ||
| + | * For Unmanaged remote computers the server must assure that the client code is trustworthy. | ||
==References== | ==References== | ||
[[Category: Trust]] | [[Category: Trust]] | ||
Latest revision as of 17:32, 8 February 2023
Contents
Full Title or Meme
Any Certificate Authority that is designed to apply to people, natural or otherwise, that are known to the Enterprise.
Context
- Typically, an Enterprise Certificate Authority operates via Client Certificates that are issued to a digital Identifier that is issued to an Entity that has some means to control access to a protected Private Key that is used for Authentication.
- The most common form of Authentication is via Client Certificates that bind the Entity Identifier with a Client Certificate that is used in a TCP connection using Mutual Authentication to carry the proof of possession, not only of the key of the server, but also of the key of the Client.
- The most common form of Mutual Authentication uses MTLS or mutual transportation layer security.
Problems
In general, the problems are created by a mismatch between the MTLS authentication result and the identity of the principle in the enterprise network. There have been multiple vulnerabilities reported to the US Government the top three in 2022 are for Microsoft AD.
- CVE-2022-34691 An authenticated user could manipulate attributes on computer accounts they own or manage, and acquire a certificate from Active Directory Certificate Services that would allow elevation of privilege to System.
- CVE-2022-26931 Successful exploitation of this vulnerability requires an attacker to prepare the target environment to improve exploit reliability.
- 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.
Other attacks are direct against the network facing code such as these:
- CVE-2023-24576 EMC NetWorker may potentially be vulnerable to an unauthenticated remote code execution vulnerability in the Networker Client execution service
- 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
Spoofing attacks
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.
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.
- 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.
Schannel will try to map each certificate mapping method you have enabled until one succeeds. Schannel tries to map the Service-For-User-To-Self (S4U2Self) mappings first. The Subject/Issuer, Issuer, and UPN certificate mappings are now considered weak and have been disabled by default. The bitmasked sum of the selected options determines the list of certificate mapping methods that are available.
Elevation of Privilege
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.
- For Unmanaged remote computers the server must assure that the client code is trustworthy.
