=================================================================== CERT-Renater Note d'Information No. 2023/VULN139 _____________________________________________________________________ DATE : 04/04/2023 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running HashiCorp Vault versions prior to 1.13.1, 1.12.5, 1.11.9. ====================================================================https://discuss.hashicorp.com/t/hcsec-2023-12-vault-s-microsoft-sql-database-storage-backend-vulnerable-to-sql-injection-via-configuration-file/52080 https://discuss.hashicorp.com/t/hcsec-2023-11-vault-s-pki-issuer-endpoint-did-not-correctly-authorize-access-to-issuer-metadata/52079 https://discuss.hashicorp.com/t/hcsec-2023-10-vault-vulnerable-to-cache-timing-attacks-during-seal-and-unseal-operations/52078 _____________________________________________________________________ HCSEC-2023-12 - Vault’s Microsoft SQL Database Storage Backend Vulnerable to SQL Injection Via Configuration File Security security-vault jfinnigan March 30, 2023, 12:10am 1 Bulletin ID: HCSEC-2023-12 Affected Products / Versions: Vault up to 1.13.0, 1.12.4, and 1.11.8; fixed in 1.13.1, 1.12.5, 1.11.9. Publication Date: March 29, 2023 Summary When using Vault’s community-supported Microsoft SQL (MSSQL) database storage backend, a privileged attacker with the ability to write arbitrary data to Vault’s configuration may be able to perform arbitrary SQL commands on the underlying database server through Vault. This vulnerability, CVE-2023-0620, is fixed in Vault 1.13.1, 1.12.5, and 1.11.9. Background Vault allows for the configuration of various storage backends. Storage backends act as a place for durable storage during Vault operations. Vault supports internal (e.g., Integrated Storage) as well as external storage backends (e.g., Consul, MSSQL, and others. Configuration is set using the storage stanza within Vault’s configuration file. Details When configuring MSSQL as a storage backend, a number of parameters are required to establish a connection to the target database, such as username, password, schema, database, and table. When establishing a connection between Vault and the database server, Vault passes these parameters set in Vault’s configuration directly to the database. Vault considers these values to be trusted and does not sanitize the values for schema, database, and table, resulting in a malicious user being able to include malicious SQL code that will execute when the Vault configuration is applied. It is important to note that only highly privileged users or administrators can apply Vault configurations. An attacker would also require access to the configuration file or know the username and password to the target database, in which case an attacker may be able to execute SQL commands through reading the configuration. Remediation Customers who use the MSSQL storage backend should evaluate the risk associated with this issue and consider upgrading to Vault 1.13.1, 1.12.5, and 1.11.9, or newer. Please refer to Upgrading Vault for general guidance and version-specific upgrade notes. As noted in a recent clarification to the Vault security model, Vault operators should ensure that Vault configuration files and storage backends are appropriately secured, as described in Vault’s production hardening guidelines. Furthermore, we generally recommend the usage of HashiCorp-supported and highly-available storage backends such as integrated storage or Consul for production use. Acknowledgement This issue was identified by Yuval Ostrovsky, Gal Goldshtein, and Daniel Abeles of Oxeye. 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. _____________________________________________________________________ HCSEC-2023-11 - Vault’s PKI Issuer Endpoint Did Not Correctly Authorize Access to Issuer Metadata Security security-vault jfinnigan March 30, 2023, 12:08am 1 Bulletin ID: HCSEC-2023-11 Affected Products / Versions: Vault and Vault Enterprise since 1.11.0; fixed in 1.13.1, 1.12.5, and 1.11.9. Publication Date: March 29, 2023 Summary Vault’s PKI mount issuer endpoints did not correctly authorize access to remove an issuer or modify issuer metadata, potentially resulting in denial of service of the PKI mount. This bug did not affect public or private key material, trust chains or certificate issuance. This vulnerability, CVE-2023-0665, is fixed in Vault 1.13.1, 1.12.5, and 1.11.9. Background Vault’s PKI engine allows users to generate dynamic X.509 certificates, without going through the usual manual process of generating a private key and CSR, submitting to a CA, and waiting for a verification and signing process to complete. Vault’s built-in authentication and authorization mechanisms provide the verification functionality. More information about the PKI secrets engine can be found in https://developer.hashicorp.com/vault/docs/secrets/pki. Vault 1.11.0 introduced the ability to share a PKI mount with several issuers (Certificate Authorities) on a single mount, to provide users with more management flexibility. More information is available in https://developer.hashicorp.com/vault/tutorials/secrets-management/pki-engine#notice-about-multi-issuer-functionality. Details During internal testing, we discovered that several unauthenticated endpoints did not correctly authorize inbound requests and allowed for modification or deletion of certain metadata fields. An attacker may have been able to modify or delete some authority information fields for existing issuers, including crl_distribution_points and oscp_server, potentially resulting in denial of service for a given PKI mount. This issue affects a subset of issuer endpoints (/issuer/:ref/{json,der,pem}). The primary /issuer/:ref endpoint is not affected by this bug and remains properly authenticated. Any issuer CA certificates which were deleted may be safely re-imported as the integrity and availability of all key material and certificates are unaffected, and this only affects metadata associated with the certificate and managed by Vault. Remediation Customers should evaluate the risk associated with this issue and consider upgrading to Vault Enterprise 1.13.1, 1.12.5, and 1.11.9, or newer. Please refer to Upgrading Vault for general guidance and version-specific upgrade notes. The Vault team maintains documentation and best practices around the use of the PKI secrets engine in https://developer.hashicorp.com/vault/docs/secrets/pki/considerations. Acknowledgement This issue was identified by the Vault engineering team. 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. _____________________________________________________________________ HCSEC-2023-10 - Vault Vulnerable to Cache-Timing Attacks During Seal and Unseal Operations Security security-vault jfinnigan March 30, 2023, 12:02am 1 Bulletin ID: HCSEC-2023-10 Affected Products / Versions: Vault and Vault Enterprise up to 1.13.0, 1.12.4, and 1.11.8; fixed in 1.13.1, 1.12.5, 1.11.9. Publication Date: March 29, 2023 Summary HashiCorp Vault’s implementation of Shamir’s secret sharing used precomputed table lookups, and was vulnerable to cache-timing attacks. An attacker with access to, and the ability to observe a large number of unseal operations on the host through a side channel may reduce the search space of a brute force effort to recover the Shamir shares. This vulnerability, CVE-2023-25000, is fixed in Vault 1.13.1, 1.12.5, and 1.11.9. Background One component of Vault’s security model is the concept and implementation of sealed and unsealed states. By default, unseal keys use Shamir’s Secret Sharing to split the key into shares instead of distributing the unseal key as a single key. A certain threshold of shares is required to reconstruct the unseal key, which is then used to decrypt the root key. Details Vault’s Shamir implementation uses Go’s crypto/subtle package and constant time functions to help prevent timing attacks. Within these functions, mult and div, are two operations used to compute the difference between two precomputed Galois Field log tables. The CPU will load these tables into its cache so that concurrent lookups will not have to read from memory. The way these lookup tables are loaded into the cache leads to cache-timing leaks. By performing a cache-timing attack, an attacker may, through a side channel, be able to monitor the cache as it empties and reloads. Observations of a large amount of seal operations may reduce the search space of a brute force effort to recover the Shamir shares, which if successful, result in retrieval of sensitive data, such as the unseal or root key. It is unclear how practical such an attack is, but the mult and div functions used in Vault’s Shamir implementation have been modified to remove table lookups and negate this attack. Remediation Customers should evaluate the risk associated with this issue and consider upgrading to Vault Enterprise 1.13.1, 1.12.5, 1.11.9, or newer. Please refer to Upgrading Vault for general guidance and version-specific upgrade notes. Acknowledgement This issue was identified by Giuseppe Cocomazzi. 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. ========================================================+ CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =======================================================