CVE-2024-23444: Elasticsearch Information Disclosure Flaw

CVE-2024-23444 Overview

A sensitive data exposure vulnerability has been identified in Elasticsearch's elasticsearch-certutil CLI tool. When the tool is used with the csr option to create a new Certificate Signing Request (CSR), the associated private key that is generated is stored on disk unencrypted, even when the --pass parameter is explicitly passed in the command invocation. This security flaw was discovered by Elastic engineering during internal security testing.

This vulnerability represents a significant cryptographic security weakness because administrators who believe they are protecting their private keys with password encryption are unknowingly leaving sensitive cryptographic material exposed on the file system. The unencrypted private keys can be read by any user or process with file system access, potentially compromising the entire TLS/SSL certificate infrastructure of an Elasticsearch deployment.

Critical Impact

Private keys generated using elasticsearch-certutil with the CSR option are stored unencrypted on disk regardless of password protection settings, potentially exposing cryptographic credentials to unauthorized access.

Affected Products

• Elastic Elasticsearch versions prior to 8.13.0
• Elastic Elasticsearch versions prior to 7.17.23
• Any Elasticsearch deployment using certificates generated with the vulnerable certutil CSR functionality

Discovery Timeline

• July 31, 2024 - CVE-2024-23444 published to NVD
• April 4, 2025 - Last updated in NVD database

Technical Details for CVE-2024-23444

Vulnerability Analysis

This vulnerability falls under CWE-311 (Missing Encryption of Sensitive Data). The core issue lies in the elasticsearch-certutil command-line tool's handling of the --pass parameter when generating Certificate Signing Requests.

Under normal operation, when an administrator generates certificates or CSRs using elasticsearch-certutil, they can specify a password via the --pass parameter to encrypt the private key at rest. This is a critical security control that ensures private keys remain protected even if an attacker gains read access to the file system.

However, when using the csr option specifically, the tool fails to properly apply the encryption to the generated private key. The private key is written to disk in plaintext PEM format, completely ignoring the password encryption directive. This creates a false sense of security where administrators believe their keys are protected when they are not.

The vulnerability can be exploited by any actor with read access to the file system where the private key is stored. This includes local users, compromised applications running on the same system, or attackers who have gained initial foothold through other means.

Root Cause

The root cause is a logic flaw in the elasticsearch-certutil tool's CSR generation code path. While other certificate generation modes properly honor the --pass parameter and encrypt the private key using PKCS#8 password-based encryption, the CSR generation mode bypasses this encryption step entirely.

The private key is written directly to disk in unencrypted PEM format without checking or applying the password protection that was requested by the user. This appears to be an oversight in the tool's implementation where the CSR code path was not updated to include the same encryption logic used by other certificate generation modes.

Attack Vector

The attack vector is network-based with respect to the overall Elasticsearch deployment, though the actual exploitation requires file system access to retrieve the unencrypted private keys.

An attacker could exploit this vulnerability through several scenarios:

1. Local Privilege Escalation: A low-privileged user on the Elasticsearch host could read unencrypted private keys and use them to impersonate cluster nodes or decrypt TLS traffic.

2. Post-Compromise Credential Harvesting: After initial compromise of an Elasticsearch server, attackers can harvest private keys for persistent access or lateral movement.

3. Insider Threat: System administrators or operators with legitimate file system access could exfiltrate private keys for malicious purposes.

4. Backup Exposure: If file system backups are not properly secured, the unencrypted private keys could be exposed through backup media.

The vulnerability affects the confidentiality of the Elasticsearch deployment's cryptographic infrastructure. Compromised private keys can be used to perform man-in-the-middle attacks, decrypt captured TLS traffic, or forge certificates to impersonate legitimate cluster nodes.

Detection Methods for CVE-2024-23444

Indicators of Compromise

• Presence of unencrypted private key files in directories where elasticsearch-certutil output is stored
• Private key files lacking PKCS#8 encrypted format headers (files starting with -----BEGIN PRIVATE KEY----- instead of -----BEGIN ENCRYPTED PRIVATE KEY-----)
• Evidence of unauthorized access to certificate storage directories
• Suspicious certificate-related file access by non-administrative processes

Detection Strategies

• Audit file system permissions on directories containing Elasticsearch certificates and private keys
• Implement file integrity monitoring (FIM) on certificate storage locations to detect unauthorized access
• Review historical usage of elasticsearch-certutil commands with the csr option to identify potentially compromised keys
• Monitor for anomalous TLS connection patterns that might indicate use of stolen certificates

Monitoring Recommendations

• Enable file access auditing on certificate directories using operating system audit frameworks (auditd on Linux, Windows Security Auditing)
• Configure SentinelOne to monitor for suspicious access to PEM and key files in Elasticsearch directories
• Implement alerting for any process other than Elasticsearch accessing private key files
• Review and monitor certificate usage patterns across the Elasticsearch cluster for anomalies

How to Mitigate CVE-2024-23444

Immediate Actions Required

• Upgrade Elasticsearch to version 8.13.0 or later (for 8.x branch) or version 7.17.23 or later (for 7.x branch)
• Identify any certificates or CSRs generated using the vulnerable elasticsearch-certutil with the csr option
• Regenerate all affected private keys and certificates using the patched version of the tool
• Revoke any certificates associated with potentially compromised private keys
• Review and restrict file system permissions on certificate storage directories

Patch Information

Elastic has released security patches addressing this vulnerability. The fixed versions are:

• Elasticsearch 8.13.0 and later
• Elasticsearch 7.17.23 and later

Administrators should consult the Elastic Security Update ESA-2024-12 for detailed upgrade instructions. Additional information is available in the NetApp Security Advisory NTAP-20250404-0001.

Workarounds

• Manually encrypt private keys after generation using OpenSSL: openssl pkcs8 -topk8 -in unencrypted.key -out encrypted.key -v2 aes256
• Restrict file system permissions to limit access to certificate directories (chmod 700 on certificate directories)
• Avoid using the csr option with elasticsearch-certutil until upgrade is completed; use alternative certificate generation methods
• Store certificates and keys in secure, encrypted storage volumes with strict access controls

# Configuration example
# Manually encrypt an unencrypted private key generated by the vulnerable tool
openssl pkcs8 -topk8 -inform PEM -outform PEM -in /path/to/unencrypted-key.pem -out /path/to/encrypted-key.pem -v2 aes256

# Set restrictive permissions on certificate directories
chmod 700 /etc/elasticsearch/certs
chown -R elasticsearch:elasticsearch /etc/elasticsearch/certs

# Verify if a private key file is encrypted (should show "ENCRYPTED" in header)
head -1 /path/to/private-key.pem
# Encrypted: -----BEGIN ENCRYPTED PRIVATE KEY-----
# Unencrypted: -----BEGIN PRIVATE KEY-----