Bulletin ID: HCSEC-2020-17
Affected Products / Versions: Vault and Vault Enterprise 0.8.3 and newer; fixed in 1.2.5, 1.3.8, 1.4.4 and 1.5.1.
Publication Date: 18 August, 2020
Summary
A vulnerability was identified in Vault and Vault Enterprise (“Vault”) such that, with the GCP Auth Method configured and under certain circumstances, the values relied upon by Vault to validate Google Compute Engine (GCE) VMs may be manipulated and authentication bypassed. This vulnerability, CVE-2020-16251, affects Vault and Vault Enterprise versions 0.8.3 and newer, and is fixed in 1.2.5, 1.3.8, 1.4.4 and 1.5.1.
Background
Vault can be integrated with third-party authentication systems through the use of Auth Methods, components that perform authentication and are responsible for assigning identity and a set of policies to a user. The GCP Auth Method integrates Vault authentication into either GCP’s IAM service, or GCE service. This vulnerability only impacts the GCE method.
When using the GCE auth method, Vault can assign a role to a specific subset of GCE VMs, generally bound to certain attributes, such as projects or regions. The GCE auth method can also restrict access to VMs running under a specific service account. However, this is explicitly called out as optional in the documentation.
When a client authenticates to Vault with the GCE auth type it is expected to run on an authorized GCE VM, fetching a JWT token from the GCP instance metadata server that is signed by Google. Alternatively, in the IAM auth type the JWT may be signed by a GCP service-account private key that is under the control of the end-user, and may contain arbitrary additional claims.
Details
It was reported that the Vault GCP Auth Method does not enforce that JWTs signed by a service account do not contain GCE compute_engine claims, and can be used when the Auth Method is configured in the GCE auth method. This allows for arbitrary service accounts to sign crafted JWTs that include arbitrary bound attributes.
If the Vault GCP GCE role is configured with a bound project, but not with an explicit bound service account, then a crafted JWT with a matching bound project will pass the checks and will return a legitimate Vault token. The service account claim can’t be forged with a service account.
Conditions:
- Vault is configured with the GCP Auth Method via GCE (not IAM).
- The associated role is configured with bound_zones, bound_regions, bound_instance_groups, or bound_labels, but not bound_service_accounts.
- An attacker knows what attributes are bound to the GCP Auth Method Role and their expected values.
Remediation
As described above, this is a vulnerability with conditions existing only in a subset of Vault deployments and use-cases. Vault deployments that do not use the GCP Auth Method with GCE are not affected.
If deemed necessary, based on deployment / use case and conditions described above, operators should upgrade to Vault 1.2.5, 1.3.8, 1.4.4 and 1.5.1 or newer. These releases include changes to the GCP Auth Method to address this vulnerability.
The external vulnerability reporter plans to publish their findings on October 6, 2020. Affected Vault deployments should evaluate exposure and consider adopting one of these new releases prior to that date.
Please refer to Upgrading Vault for general guidance and version-specific upgrade notes.
Acknowledgement
This issue was identified by Felix Wilhelm of Google Project Zero.
We deeply appreciate any effort to discover and disclose security vulnerabilities responsibly. For information about security at HashiCorp and the reporting of security vulnerabilities, please see https://hashicorp.com/security.