HashiCorp Vault is trusted by big companies and organizations to protect their most sensitive secrets. But what if we told you that in versions 1.13. and 1.13.1, when using an HSM (Hardware Security Module) backed by certain encryption methods, users were at risk of their entire Vault’s root key being compromised due to a padding oracle vulnerability? That’s exactly what CVE-2023-2197 exposes. Let’s break down what this means, how it could be exploited, and what was done to fix it.

What Is CVE-2023-2197?

In some cloud-native security setups, Vault uses an HSM for key storage and encrypts data using AES in CBC mode (CKM_AES_CBC_PAD or CKM_AES_CBC). Due to how encryption and padding errors were handled, attackers with the right privileges could perform a “padding oracle” attack: by carefully crafting and modifying ciphertext blocks, and observing system responses (errors or success) after each change, they could eventually recover the plaintext data, including the Vault’s root key.

Affected versions:

Only when using an HSM with CKM_AES_CBC_PAD or CKM_AES_CBC mechanisms

Patched version:

Why Is This Dangerous?

The root key in Vault is like the master password that can unlock any secret stored in Vault. If an attacker can get the root key, they have total control. This bug allowed someone with access to manipulate encrypted storage (and the ability to restart Vault) to conduct a padding oracle attack and slowly recover that key.

The Basics: What Is a Padding Oracle Attack?

AES-CBC encryption (“Cipher Block Chaining” with Advanced Encryption Standard) splits data into blocks, but data doesn’t always fit perfectly into blocks. To pad out the last block, special bytes are added. Upon decrypting, Vault checks if padding is correct. If wrong, it throws a padding error.

A padding oracle is an “oracle” (a system) that tells you if your guess at the data led to a correct padding – even if it doesn’t show you the decrypted data.

Example:

Here's a basic (python) conceptual example (not a real exploit for Vault)

def is_padding_valid(ciphertext):
    try:
        plaintext = decrypt(ciphertext)
        # Assume PKCS7 padding
        plaintext.decode('utf-8') # Throws if padding is bad
        return True
    except PaddingError:
        return False

# The attacker doesn't need decrypt(), just this oracle function.

Vault was, in effect, acting as this “oracle.”

Restart Vault:

Vault reads the data and tries to decrypt. If padding is invalid, Vault returns an error. If it's valid, the error doesn't show.

Oracle Queries:

After each tweak, the attacker sees if Vault gave a padding error. This forms an "oracle" they can repeatedly query.

Byte-by-Byte Recovery:

Over enough tries, the attacker can reveal one byte at a time, recreating the plaintext, and eventually the root key.

Ciphertext Block “C” with IV (Initialization Vector) “IV” is stored in disk.

2. Attacker tweaks the IV or last bytes of previous block (since AES-CBC xor’s previous block with current plaintext).

On Vault restart, it tries to decrypt and unpad.

4. If the tweak produced correct padding, Vault starts up; if not, it emits a padding error (visible to attacker).

Why Does This Only Happen With HSM + CKM_AES_CBC_PAD or CKM_AES_CBC?

With an HSM, padding errors could be surfaced directly to Vault, instead of being hidden or handled in non-descriptive ways. The combination of implementation flaws and how errors were handled in these modes enabled the oracle.

Official References

- HashiCorp Security Advisory: Vault Enterprise Padding Oracle
- CVE Record at NVD

Patch & Fixes

Vault Enterprise 1.13.2:  
The vulnerability was fixed by ensuring that decryption errors do NOT leak information – all errors are handled in a way that's indistinguishable, and does not allow an attacker to deduce padding correctness.

Official Upgrade Guide:  
Users must upgrade to Vault Enterprise 1.13.2 or higher where the issue is remediated. There’s no workaround except disabling use of vulnerable HSMs or AES-CBC mechanisms (which might not be possible for some users).

Summary Table

| Version         | Vulnerable? | Fixed? |  
|-----------------|-------------|--------|  
| 1.13., 1.13.1  | Yes         | No     |  
| 1.13.2+         | No          | Yes    |  

If you are running Vault Enterprise 1.13. or 1.13.1 with HSM-backed keys using AES-CBC (CKM_AES_CBC_PAD or CKM_AES_CBC), immediately upgrade and check audit logs for abnormal restarts or data tampering.


TL;DR:  
CVE-2023-2197 lets a privileged attacker run a padding oracle attack on HashiCorp Vault Enterprise using specific HSMs—potentially leaking the root key. Upgrade to 1.13.2 and review your configurations now!


*This post was written to explain CVE-2023-2197 in clear, simple terms. For more on padding oracle attacks, check out Wikipedia’s page: Padding oracle attack. If you’re a Vault admin, double-check your versions today!*

Timeline

Published on: 05/01/2023 20:15:00 UTC
Last modified on: 05/06/2023 03:12:00 UTC