CVE-2024-45341

What it actually does

A flaw in the certificate validation logic allows a specially crafted X.509 certificate to bypass URI name constraints. If a certificate's Subject Alternative Name (SAN) contains a URI with an IPv6 address that includes a zone ID, the validation process may incorrectly accept the certificate, even if it violates the defined name constraint. This leads to a partial authentication bypass, as a malicious certificate can be mistaken for a legitimate one within a restricted namespace.

Why it matters to the business

This vulnerability can allow an attacker to impersonate trusted services or users within private enterprise networks that use Public Key Infrastructure (PKI) with URI name constraints for access control. This could lead to unauthorized access to sensitive internal applications and data, undermining network segmentation and trust boundaries. The impact is confined to organizations with private PKIs that utilize this specific, non-standard certificate feature.

How an attack unfolds

An attacker first identifies a target organization that relies on a private PKI and uses URI name constraints to secure internal services. The attacker then crafts a malicious X.509 certificate containing a URI with an IPv6 address and a zone ID (e.g., `https://[fe80::1%eth0]/resource`). After getting this certificate signed by a CA trusted within the target's environment, the attacker presents it to a vulnerable client or server. The flawed validation logic incorrectly accepts the certificate, bypassing the name constraint and granting the attacker the same level of access as the legitimate service they are impersonating.

How to fix it

Upgrade affected systems to a patched version that correctly validates certificate name constraints involving IPv6 addresses with zone IDs. For the specified Red Hat products, update to version `0:4.3.19-20211013.0.el7_9` or a later release. As a preventative measure, organizations should review their internal CA policies and consider disallowing the issuance of certificates that contain URIs with IPv6 zone IDs.

How to confirm the fix worked

To confirm remediation, verify that all affected components have been upgraded to the fixed versions or later. To test for the vulnerability in a safe environment, create a test certificate containing a URI with an IPv6 address and zone ID. Configure a service with a name constraint that should explicitly reject this certificate. If the connection attempt using the test certificate is correctly denied, the system is not vulnerable. If the connection is allowed, the system remains vulnerable.

Typical attack path

1. The attacker identifies a target using a private PKI with URI name constraints for authentication.
2. The attacker crafts a malicious certificate containing a URI with an IPv6 address and a zone ID in the Subject Alternative Name field.
3. The attacker obtains a signature for this certificate from a Certificate Authority that is trusted by the target system.
4. The attacker positions themselves to present the certificate, for example by setting up a malicious server or performing a Man-in-the-Middle attack.
5. A user or automated system connects, and the vulnerable application attempts to validate the malicious certificate.
6. The application's flawed validation logic incorrectly accepts the certificate, bypassing the URI name constraint.
7. The attacker successfully impersonates a legitimate internal service and gains unauthorized access.

How to detect it

To detect potential exploitation, security teams should monitor certificate validation logs and network traffic for anomalies. Look for successful TLS handshakes involving certificates that contain a URI with an IPv6 address and a zone ID (e.g., `...%eth0`). If your organization maintains a Certificate Transparency log for your internal PKI, search it for issued certificates matching this pattern. Successful authentications from unexpected sources using certificates with these non-standard URIs should be investigated as potential indicators of compromise.

• pcre:/subjectAlternativeName:URI:.*//\[[a-fA-F0-9:]+%[a-zA-Z0-9_.-]+\]/

What your security team should do

• Immediately patch all vulnerable systems, prioritizing those that are part of a private PKI and use URI name constraints for access control.
• Audit your internal Certificate Authority infrastructure to determine if URI name constraints are in use and if any certificates with IPv6 zone IDs have been issued.
• Update certificate issuance policies to prohibit or flag certificates containing URIs with IPv6 zone IDs in the Subject Alternative Name field.