Kibana arbitrary code execution via prototype pollution (ESA-2024-22)
A flaw allowing arbitrary code execution was discovered in Kibana. An attacker with access to ML and Alerting connector features, as well as write access to internal ML indices can trigger a prototype pollution vulnerability, ultimately leading to arbitrary code execution.
This issue affects self-managed Kibana installations on host Operating Systems.
This issue affects self-managed Kibana instances running the Kibana Docker image, but the RCE is limited within the container. Further exploitation such as container escape is prevented by seccomp-bpf.
This issue affects Kibana instances running on Elastic Cloud but the RCE is limited within the Kibana Docker container. Further exploitation such as container escape is prevented by seccomp-bpf and AppArmor profiles.
This issue affects Kibana instances running on Elastic Cloud Enterprise (ECE) but the code execution is limited within the Kibana Docker container. Further exploitation such as container escape is prevented by seccomp-bpf and AppArmor profiles.
This issue affects Kibana instances running on Elastic Cloud on Kubernetes (ECK) but the code execution is limited within the Kibana Docker container. Further exploitation such as container escape can be prevented by seccomp-bpf when configured and supported (Kubernetes v1.19 and later).
Affected Versions:
Kibana 8.x versions prior to 8.14.2 and Kibana 7.x versions from 7.7.0 prior to 7.17.23
Affected Configurations:
This exploit requires a threat actor to have all of the following priveleges: write access to the .ml-anomalies* hidden indices, read access to the Machine Learning feature, and read access to the Actions & Connectors feature.
Write access to the .ml-anomalies* hidden indices isn't provided by default, is not recommended, nor is it explicitly or implicitly required for any user functionality.
Solutions and Mitigations:
Users should upgrade to version 8.14.2 and 7.17.23.
For Users that cannot upgrade:
If an upgrade is not possible, we advise customers to first ensure Elasticsearch and Kibana user privileges are properly secured. Further mitigations can be applied by disabling Connector Actions and Machine Learning capabilities if this functionality is not required. Details are as follows:
1. Securing Elasticsearch user privileges
Customers are advised to ensure that users have not been granted Elasticsearch index privileges to write ML result indices (.ml-anomalies*). Ensure this has not been explicitly granted.
GET _security/role
Check role definitions for customer-created roles. Ensure index privileges have not been granted to .ml-anomalies* (or equivalent matching wildcard) for any customer role that would allow writing data (all, write, create_doc, create, index, etc).
Note: Users with superuser privileges have full index privileges. Ensure superuser access is controlled.
2. Securing Kibana user privileges
Kibana user privileges can be further secured to limit access to ML and connector action capabilities.
Users that do not require access to ML or manage Kibana Alerting Rules must have either of the following Kibana privileges set to “None”:
Machine Learning: None
Management / Actions and Connectors: None
Note: Users with superuser privileges will still be able to access machine learning capabilities in Kibana. In 7.x, users with manage_ml or monitor_ml Elasticsearch cluster privileges or machine_learning_admin or machine_learning_user built-in roles are able to access machine learning capabilities in Kibana.
Further mitigations can be applied via:
3. Disabling Connector Actions
All email connector actions can be disabled. This will prevent emails from being sent for alerting rule notifications, and an alternate notification action would be required. This must be set on all Kibana nodes and applied after a node restart.
In 7.7+ and 8.x, Connector action can be disabled in kibana.yml. This must be applied to all Kibana nodes. Note: Do not apply this yml setting to clusters of version 7.6 and below - this will prevent Kibana from starting.
A full list of action types is available in the documentation:
https://www.elastic.co/guide/en/kibana/7.17/alert-action-settings-kb.html
https://www.elastic.co/guide/en/kibana/8.15/alert-action-settings-kb.html
// kibana.yml
// To only allow specific named connector actions, supply an named list and exclude email
// Also delete any pre-configured email connectors, if specified
xpack.actions.enabledActionTypes: [ ".server-log", ".index", ".other-tbc" ]
Any existing Alerting Rule that used an email action for its notifications would continue running but would not be able to send email notifications. Errors would be logged due to the disabled email connector. An alternate connector action would be required for notifications.
4. Disabling ML
Machine learning capabilities can be disabled. This will prevent machine learning jobs from running.
In 6.x, 7.x, 8.x, machine learning functionality can be disabled entirely by setting the following in elasticsearch.yml. This must be applied to all Elasticsearch nodes and is applied upon a node restart.
https://www.elastic.co/guide/en/elasticsearch/reference/8.14/ml-settings.html
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/ml-settings.html
https://www.elastic.co/guide/en/elasticsearch/reference/6.8/ml-settings.html
// elasticsearch.yml
xpack.ml.enabled: false
In 6.x and 7.x, machine learning in Kibana functionality can be disabled in Kibana only, by setting the following in kibana.yml. Machine learning functionality will continue to be available in Elasticsearch and accessible via Elasticsearch APIs, and all Kibana ML functionality will be disabled. Choose this option if you want to continue accessing ML functionality via Elasticsearch APIs only. This must be set on all Kibana nodes and is applied upon a node restart.
https://www.elastic.co/guide/en/kibana/7.17/ml-settings-kb.html
https://www.elastic.co/guide/en/kibana/6.8/ml-settings-kb.html
// kibana.yml
xpack.ml.enabled: false
Severity:
CVSSv3.1: 9.1(Critical) - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
***Updated Aug 13, 2024 11:45:01 UTC : CVSS Severity Rating has been updated after re-analysis of the issue. Privileges Required was revised to High from the initial assessment Privileges Required Low.
CVE ID:
CVE-2024-37287