HashiCorp Vault Unauthenticated Memory Secrets Extraction

Proof of concept to extract Active Directory LDAP from an unsealed Hashicorp Vault.

Disclaimer:

This exploitation and/or abuse of HashiCorp Vault has been reported. Nevertheless, they didn’t considered this condition as a “Vulnerability” due to their Threat Model, which stipulates the following: “Protecting against memory analysis of a running Vault. If an attacker is able to inspect the memory state of a running Vault instance, then the confidentiality of data may be compromised.”

HashiCorp Vault and its multiple usages

• HashiCorp Vault represents an open-source solution designed to securely store and manage sensitive information like passwords, API keys, and other confidential data. It also offers capabilities to oversee PKI-related structures such as VPNs, SSH CAs, and more.

• Vault employs a method known as key splitting to divide the primary encryption key into multiple segments called unseal keys. These unseal keys function as components of the master encryption key and are essential for unlocking the Vault and accessing its contents.

• By default, Vault initializes in a sealed state upon startup. To unlock and access its contents, a specific number of unseal keys must be provided. These keys may be distributed among different individuals or stored in secure locations.

• Upon successful login, Vault issues an access token that operates under predefined access token policies. These policies dictate and enforce access control levels, determining users’ abilities to view, modify, or update content within the HashiCorp Vault.

Caching and Storing Mechanisms

In-memory Data (Non-production environments)

When we refer to the HashiCorp Vault documentation, we observe under which conditions it stores all information in memory:

According to the documentation, it’s strongly advised against using a server in development mode within a production environment, as all information is handled in memory. However, it’s noteworthy that despite this, the information is still encrypted—a crucial aspect preventing unauthorized access to secrets and sensitive data.

Image retrieved from Hashicorp Vault - Starting the Server

On another note, we have the caching topic:

Image retrieved from Hashicorp Vault - Vault Agent Caching

The issue with those Tokens and Leases that are Cached in-memory is that they store sensitive information and secrets (unencrypted) that could be used to compromise other services, for instance, Active Directory Domain Services (LDAP - Auth Method).

Persistent Cache

Vault can create/maintain persistent cache through a file (This setting needs to be specified in the Vault server configuration file):

Image retrieved from Hashicorp Vault - Vault Agent Persistent Caching

Here is a sample configuration for Vault to have persistent cache:

cache {
  persist "kubernetes" {
    path = "/vault/agent-cache"
  }
}

HashiCorp Vault - Unaunthenticated Secrets Extraction

In the following scenario, Vault is set up for a production environment and employs LDAPS as its authentication mechanism.

Next, we have the Vault configuration file:

• Note: Please note in the configuration details that a persistent cache is not implemented at any point.

storage "raft" {
  path    = "./vault/data"
  node_id = "node1"
}

listener "tcp" {
  address     = "127.0.0.1:8200"
  tls_disable = "true"
}

api_addr = "http://127.0.0.1:8200"
cluster_addr = "https://127.0.0.1:8201"
ui = true

LDAP Authentication - Groups and users allowed to authenticate

As shown in the next figures, the VaultAdm group includes the user Tony Stark (tstark), who is granted access to Vault using LDAPS authentication:

LDAP Authentication - Leases

The following leases are the result of multiple successful authentications against Vault:

It’s crucial to emphasize that sensitive information from leases, such as credentials, is never visible. Only informative details, such as TTL, Expiration time, Expires In, and Issue Time, are available.

Vulnerability Exploitation Pt.1:

First of all, we’ll commence a new Vault process in production mode:

A vulnerability was observed wherein, upon Vault unseal, without user authentication, access to Vault’s memory allows for extraction of unencrypted secrets and leases:

1. Upon initiating a new Vault process, it will be sealed by default. We can verify this by using the ‘vault status’ command or by making an HTTP GET request to the ’/sys/seal-status’ API endpoint:

   vault status

   

2. Unsealing the Vault by providing the Keys:

   The ‘vault operator unseal’ command will be repeated a total of three (3) times, which corresponds to the minimum threshold required to unlock Vault:

   vault operator unseal

   

   IMPORTANT: At this point, we’ve merely unsealed Vault, but we haven’t authenticated against Vault. Therefore, we can’t interact with the system (For instance, viewing secret engines, authentication methods, mounting new secret engines, etc.) as we don’t yet possess a valid token (Vault’s core authentication mechanism).

3. Nevertheless, the vulnerability lies in the fact that when a new Vault process starts and is unsealead, it becomes possible to access the process’s memory and retrieve the leases associated with a user. This can lead to the extraction of clear-text credentials, along with relevant information tied to the token:

   As a proof of concept, we can employ an utility (e.g., Process Hacker) that analyzes the virtual memory space of a process and searches for a pattern that provides the sensitive information we seek—in this case, clear-text credentials and information related to a token within the Vault process:

The next step is crucial because it’s where we specify the pattern we’ll search for within the process memory. For instance, we might choose a pattern like auth/ldap/login:

Let’s take one of the leases and copy the details it retains:

Here are the details of one of the obtained tstark’s leases:

0xc0032ba000 (1175): {“lease_id”:“auth/ldap/login/tstark/h8cf7ce4b822d86169284e492c489cf2d3c4e8c39c8a4711ca1831c838185f362”,“client_token”:“hvs.yWGUR4575KFItXCa9wDTtLpH”,“token_type”:0,“path”:“auth/ldap/login/tstark”,“data”:null,“secret”:null,“auth”:{“lease”:2764800000000000,“max_ttl”:0,“renewable”:true,“internal_data”:{“password”:“password123!”},“display_name”:“ldap-tstark”,“policies”:[“vaultpol”],“token_policies”:[“default”,“vaultpol”],“identity_policies”:null,“external_namespace_policies”:null,“no_default_policy”:false,“metadata”:{“username”:“tstark”},“client_token”:“hvs.yWGUR4575KFItXCa9wDTtLpH”,“accessor”:“nr4U43e8fcNRszPktlTYWhyW”,“period”:0,“explicit_max_ttl”:0,“num_uses”:0,“entity_id”:“25d9c5bf-9e9a-1d22-ba18-547fc70a743c”,“alias”:{“mount_type”:“ldap”,“mount_accessor”:“auth_ldap_f7989ea9”,“name”:“tstark”,“metadata”:{“name”:“tstark”}},“group_aliases”:null,“bound_cidrs”:null,“creation_path”:"",“token_type”:1,“orphan”:true,“policy_results”:null,“mfa_requirement”:null,“entity_created”:false},“issue_time”:“2023-12-20T05:54:03.4148106-08:00”,“expire_time”:“2024-01-21T05:54:03.4148106-08:00”,“last_renewal_time”:“0001-01-01T00:00:00Z”,“login_role”:"",“version”:1,“revokeErr”:""}

Within the information disclosed by the lease, notable details include the client token, plaintext password of the user for authentication against the domain controller (Active Directory Domain Services), token type, token policies, TTL, and more. As a result, an unauthorized actor can access Vault leveraging the client’s token. However, it’s crucial to note that due to this condition/vulnerability, it’s possible to compromise another service, in this case, Active Directory Domain Services, as user credentials are provided in plaintext. This can lead to a complete compromise of the Active Directory environment if the user is an administrator.

It’s important to highlight the following points:

1. All of this was done from the perspective of not being authenticated against Vault.

2. According to calculations and multiple tests conducted against Vault, the attacker has a window of approximately five (5) minutes to exploit this vulnerability and steal the process credentials when Vault is unsealed. However, this time frame provides sufficient leeway to carry out the attack.

Vulnerability Exploitation Pt.2 - Instrumentation and attack path:

To attack Vault and steal the leases’s sensitive information, an attacker may develop a malicious artifact with the following conditions:

1. Constantly check the status of Vault to see if it’s unsealed. This poses no issue as, without authentication, we can check such status as previously mentioned via an HTTP GET Request to ’/sys/seal-status’.

   Knowing that to exploit this condition/vulnerability, the attack vector (AV) is LOCAL, the attacker has multiple alternatives to force the unsealing process:

   1.1. Terminate the Vault process and restart it, thereby waiting for administrators to unseal it.

   1.2. An attacker who has obtained unsealing keys (which is quite possible, as in my experience conducting adversary emulations and penetration tests, many administrators place all keys in insecure locations, for instance, shared SMB folders).

2. Then, once Vault has been unsealed, proceed with reading the memory of the concerned process. Multiple methods can be employed to achieve this goal; here’s a potential procedure (exploiting the vulnerability isn’t limited to this, other functions and techniques can be leveraged):

   • Use OpenProcess to obtain a valid handle for reading Vault’s virtual memory.
   • Use ReadProcessMemory to read Vault’s virtual memory space in chunks.
   • Use NtAccessCheckAndAuditAlarm to determine if a specific memory address is valid or not.