HCSEC-2024-02 - Boundary Vulnerable to Session Hijacking Through TLS Certificate Tampering

jfinnigan · February 5, 2024, 6:49pm

Bulletin ID: HCSEC-2024-02
Affected Products / Versions: Boundary and Boundary Enterprise since 0.8.0; fixed in 0.15.0.
Publication Date: February 5, 2024

Summary
Boundary and Boundary Enterprise (“Boundary”) is vulnerable to session hijacking through TLS certificate tampering. An attacker with privileges to enumerate active or pending sessions, obtain a private key pertaining to a session, and obtain a valid trust on first use (TOFU) token may craft a TLS certificate to hijack an active session and gain access to the underlying service or application. This vulnerability, CVE-2024-1052, is fixed in Boundary 0.15.0

Background
When starting a session, Boundary generates TLS certificates dynamically to support mutual authentication between the client and worker. The lifetime of the generated certificates is tied to the lifetime of the session. For more information about sessions and how Boundary uses TLS to secure connections see TLS in Boundary and Sessions.

When a session is created, a custom per-session TLS certificate and private key are generated. This certificate contains the randomly-generated session ID of the intended target as one of its DNS Subject Alternative Names (SAN) values. During TLS verification, when a Boundary client connects to a Boundary server, the original session ID, carried via the TLS NextProtos extension, is used to find the correct TLS parameters for verification by the server.

Details
During scheduled security testing, a session hijacking exposure via TLS certificate tampering was discovered. Two attack scenarios were identified:

For active sessions, where at least one connection has been made through a target session S, the attacker can craft a TLS certificate containing the ID of S in the certificate’s DNS Subject Alternative Names that allows them to make a connection successfully to the endpoint of S. This requires the attacker to be in possession of 3 factors: the knowledge of the ID of S; a private key valid for any currently active Boundary session (but not necessarily the private key associated with session S); and the TOFU token used by the original client that activated the session.
For a non-activated session S (one in “pending” state, prior to the first connection sent through a client), the attacker requires just 2 factors; the knowledge of the ID of S; and a private key valid for any currently active Boundary session (but not necessarily the private key associated with session S).

A high level of access would be needed for exploitation. An attacker who wants to list sessions and retrieve valid private keys or TOFU tokens requires privileged permissions that are not part of a default deployment. Additionally, the attacker would need to have a currently-valid private key, requiring them to either have a high degree of privilege on the underlying client or server systems or be a user authorized to connect to other targets within Boundary.

Complexity of the attack is also high. The ability to look up session IDs not associated with a particular user is not a part of Boundary’s default permissions, and Boundary’s default clients make their first connection to an endpoint immediately after the session is authorized. As such, when using default Boundary clients, this method requires a very small window of timing where the attacker must learn of the ID of S, craft a custom TLS certificate, and make a connection to Boundary with a custom TOFU token, all before the original client reads the session authorization response and makes its first connection to Boundary. Additionally, the attacker would need to have a currently-valid private key, requiring them to either have a high degree of privilege on the underlying client or server systems or be a user authorized to connect to other targets within Boundary. Finally, this method would cause the original user to receive an error indicating a TOFU token mismatch, which can trigger immediate discovery of the attack.

This is fixed in Boundary 0.15.0 or newer by requiring that the certificate presented by the client during TLS negotiation is a byte-for-byte match to the certificate created for the session at session authorization time. Any custom certificate will thus be rejected.

Remediation
Customers should evaluate the risk associated with this issue and consider upgrading to Boundary 0.15.0, or newer. Please refer to Upgrading Boundary for general guidance and version-specific upgrade notes.

Customers may also consider searching their Boundary logs for possible exploitation attempts, Boundary logs attempts to use invalid TOFU tokens, which may be an indicator of an attacker attempting to hijack a session, with WARNING: mismatched tofu token.

Acknowledgement
This issue was identified during scheduled external security assessment.

We deeply appreciate any effort to coordinate disclosure of security vulnerabilities. For information about security at HashiCorp and the reporting of security vulnerabilities, please see https://hashicorp.com/security.