Runtime Protection for Secrets Management

Hashicorp Vault is one of the most popular secrets-management solutions. It helps manage secret parameters, cryptographic keys and authentication tokens and credentials centrally, providing visibility and control over access policies and tokens. While it solves the operational nightmare for DevOps teams, it is a high-value target for attackers. Instead of lateral movement within the organization and taking control over hosts one-by-one, gaining access to the host that runs the secrets-management solution could provide access to the whole infrastructure. While organizations invest much energy and resources into securing the hosts that run secrets-management solutions like Vault, it still doesn’t solve the runtime security problem. Hardening the host via traditional means would not protect the application from zero-day privilege escalation attacks, from an insider threat, or an untrusted infrastructure provider.

IN-MEMORY PROTECTION OF THE MASTER SECRET KEY

Vault encrypts the contents of its storage backend (whether it is memory, filesystem, Consul, etc.) using a Master Secret Key, which is not present on the host until Vault is unsealed. Unsealing is the process of providing this Master Secret Key to Vault, whether it is reconstructed from Shamir secret-shares, retrieved from a KMS service or from a HSM (Hardware Security Module), after which Vault becomes operational and can serve client requests. This Master Key is essentially the entry ticket to the goldmine of secrets, cryptographic keys and authentication credentials managed by Vault.

However, from this moment on, the Master Secret Key resides in memory and is vulnerable to memory scanning attacks (similar to what the Mimikatz does with Windows passwords). Once the Master Key is retrieved from memory, it can be used to decrypt the stored secrets. This is not specific to Vault, but rather a general problem with runtime security for any secrets-management solution or sensitive application.

Anjuna closes this gap with its Runtime Protection for Vault. By executing the Vault server inside a secure enclave, it eliminates the possibility of scraping Vault’s memory even when the attacker has root access or physical access to the machine’s memory.

PROTECTING THE AUTO-UNSEAL PROCESS

Vault starts in a sealed state, where the storage backend is protected via encryption and secrets are inaccessible. In order to become operational, Vault needs to be unsealed. It can either be done manually, by inputing the unseal tokens which are essentially Shamir secret-shares of the Master Key used to encrypt the key-value store, or automatically, by connecting to an HSM (Hardware Security Module) or a Cloud KMS (Key Management System). This automatic unsealing of Vault is called the auto-unseal feature, and is useful in automated environments where manual unsealing is prohibitive to operations. In addition, manual input of the unseal token can be subject to key-logging attacks, or memory scraping such as the one described in the previous section.
However, to initiate auto-unsealing, Vault needs to authenticate itself to the HSM using a secret such as a PIN-code. That PIN-code becomes the secret zero on which security relies. It is often stored in plaintext in a Vault configuration file (.hcl), and we end up with a having the Master Key secured using a costly HSM infrastructure, while the access to that HSM is unprotected.

Anjuna solves this secret-zero problem by sealing the Vault configuration such that it is only accessible to an instance of Vault running in a secure enclave, prohibiting even an attacker with root-access to obtain the authentication credentials.

We released the Secure Unseal solution for Vault as a free tool. Please contact Anjuna for more information.

APPLICATION IDENTITY PROTECTION

Application identity traditionally relies on the security of the host, the VM or the container where the application is running. Privileged (admin/root) access to the machine allows an attacker to assume the application’s identity and interact with clients on its behalf, posing as the authentic service. For instance, Vault can (and should) be configured to use TLS. To that end, it uses a private key (.key) and a certificate (.cert) stored on the disk in order to authenticate itself to connecting clients.
An attacker that is able to access files on the storage is able to get ahold of the private key file (.key) and spin-up a malicious Vault server instance. Unsuspecting clients will interact with it and send the attacker sensitive data such as unseal tokens, secrets, cryptographic keys and tokens and so on.

Anjuna solves this by encrypting the key files with a seal key that is only accessible to a Vault instance running inside a secure enclave. The private key is protected at-rest and at runtime, eliminating any possibility to steal it and maliciously assume Vault’s identity.