CVE-2024-37287: Elastic Kibana RCE Vulnerability

CVE-2024-37287 Overview

A critical prototype pollution vulnerability was discovered in Elastic Kibana that allows arbitrary code execution. An attacker with access to Machine Learning (ML) and Alerting connector features, combined with write access to internal ML indices, can exploit this flaw to trigger prototype pollution, ultimately achieving arbitrary code execution on the affected system.

Critical Impact

This vulnerability enables authenticated attackers with specific Kibana privileges to execute arbitrary code on the server, potentially compromising the entire Elastic Stack deployment and underlying infrastructure.

Affected Products

• Elastic Kibana versions prior to 8.14.2
• Elastic Kibana versions prior to 7.17.23
• Elastic Kibana deployments with ML and Alerting features enabled

Discovery Timeline

• 2024-08-13 - CVE-2024-37287 published to NVD
• 2024-08-22 - Last updated in NVD database

Technical Details for CVE-2024-37287

Vulnerability Analysis

This vulnerability combines two dangerous weakness categories: Code Injection (CWE-94) and Prototype Pollution (CWE-1321). Prototype pollution is a JavaScript-specific vulnerability where an attacker can modify the prototype of base objects, allowing them to inject malicious properties that propagate to all objects inheriting from the affected prototype.

In the context of Kibana, the vulnerability exists within the ML and Alerting connector features. When an attacker with appropriate privileges writes crafted data to internal ML indices, they can manipulate JavaScript object prototypes. This manipulation allows the attacker to alter application behavior in unexpected ways, ultimately leading to arbitrary code execution on the Kibana server.

The attack requires authenticated access with specific privileges, including access to ML features, Alerting connector features, and write permissions to internal ML indices. While this limits the attack surface to authenticated users with elevated privileges, organizations with compromised credentials or malicious insiders face significant risk.

Root Cause

The root cause lies in insufficient input validation and improper handling of object properties within Kibana's ML and Alerting connector functionality. When processing data written to internal ML indices, Kibana fails to adequately sanitize or validate the structure of incoming objects, allowing specially crafted payloads to pollute JavaScript prototypes. This prototype pollution then creates a pathway for code injection, as polluted properties can influence code execution paths within the application.

Attack Vector

The attack is network-based and requires authenticated access to a Kibana instance. An attacker must possess specific privileges to exploit this vulnerability:

1. Access to Machine Learning features
2. Access to Alerting connector features
3. Write access to internal ML indices

The attacker crafts a malicious payload containing prototype pollution vectors and writes it to the internal ML indices. When Kibana processes this data, the prototype pollution occurs, modifying the behavior of base JavaScript objects. The attacker then leverages this pollution to inject and execute arbitrary code on the server.

The vulnerability mechanism involves injecting properties like __proto__ or constructor.prototype into objects that are processed by Kibana's ML subsystem. These properties propagate through the JavaScript prototype chain, allowing the attacker to override methods or inject new properties that are subsequently used in code execution contexts.

Detection Methods for CVE-2024-37287

Indicators of Compromise

• Unexpected modifications to internal ML indices (.ml-* Elasticsearch indices)
• Unusual API calls to Kibana ML or Alerting connector endpoints from unexpected users
• Presence of suspicious properties such as __proto__, constructor, or prototype in ML data
• Unexpected process spawning or network connections originating from the Kibana process

Detection Strategies

• Monitor Kibana audit logs for write operations to internal ML indices by users who do not typically perform ML tasks
• Implement anomaly detection on Kibana API endpoints, specifically targeting ML and Alerting connector features
• Review Elasticsearch security logs for unauthorized access attempts to .ml-* indices
• Deploy SentinelOne Singularity to detect and block code execution attempts originating from the Kibana process

Monitoring Recommendations

• Enable comprehensive audit logging in Kibana and Elasticsearch for all ML-related operations
• Configure alerts for any modifications to internal ML indices outside of normal operational patterns
• Implement user behavior analytics to detect privilege abuse or lateral movement attempts
• Monitor for JavaScript prototype pollution indicators in application logs and data streams

How to Mitigate CVE-2024-37287

Immediate Actions Required

• Upgrade Elastic Kibana to version 8.14.2 or later for 8.x deployments
• Upgrade Elastic Kibana to version 7.17.23 or later for 7.x deployments
• Review and restrict ML and Alerting connector feature access to only necessary users
• Audit write permissions to internal ML indices and apply principle of least privilege

Patch Information

Elastic has released security updates that address this vulnerability. Organizations should update to the following patched versions:

• Kibana 8.x: Upgrade to version 8.14.2 or later
• Kibana 7.x: Upgrade to version 7.17.23 or later

For detailed patch information and upgrade instructions, refer to the Elastic Security Advisory ESA-2024-22.

Workarounds

• Temporarily disable ML and Alerting connector features if not business-critical until patching is complete
• Restrict network access to Kibana instances to trusted IP ranges only
• Implement additional authentication controls such as multi-factor authentication for Kibana access
• Review and revoke unnecessary write permissions to internal ML indices

# Review ML index permissions in Elasticsearch
# List current role mappings for ML indices
GET /_security/role/ml_admin

# Restrict write access to ML indices by modifying roles
PUT /_security/role/ml_readonly
{
  "indices": [
    {
      "names": [".ml-*"],
      "privileges": ["read"]
    }
  ]
}