Improper Authorization in Elastic Cloud Enterprise can lead to Privilege Escalation where the built-in readonly user can call APIs that should not be allowed. The list of APIs that are affected by this issue is: post:/platform/configuration/security/service-accounts delete:/platform/configuration/security/service-accounts/{user_id} patch:/platform/configuration/security/service-accounts/{user_id} post:/platform/configuration/security/service-accounts/{user_id}/keys delete:/platform/configuration/security/service-accounts/{user_id}/keys/{api_key_id} patch:/user post:/users post:/users/auth/keys delete:/users/auth/keys delete:/users/auth/keys/_all delete:/users/auth/keys/{api_key_id} delete:/users/{user_id}/auth/keys delete:/users/{user_id}/auth/keys/{api_key_id} delete:/users/{user_name} patch:/users/{user_name}
elastic_cloud_enterprise
Vendor: elastic
Security Vulnerability Index
Page 1 / 2Improper neutralization of special elements used in a template engine in Elastic Cloud Enterprise (ECE) can lead to a malicious actor with Admin access exfiltrating sensitive information and issuing commands via a specially crafted string where Jinjava variables are evaluated.
It was identified that under certain specific preconditions, an API key that was originally created with a specific privileges could be subsequently used to create new API keys that have elevated privileges.
An issue has been identified with how Elasticsearch handled incoming requests on the HTTP layer. An unauthenticated user could force an Elasticsearch node to exit with an OutOfMemory error by sending a moderate number of malformed HTTP requests. The issue was identified by Elastic Engineering and we have no indication that the issue is known or that it is being exploited in the wild.
A flaw was discovered in ECE before 3.1.1 that could lead to the disclosure of the SAML signing private key used for the RBAC features, in deployment logs in the Logging and Monitoring cluster.
A flaw was discovered in ECE before 3.4.0 that might lead to the disclosure of sensitive information such as user passwords and Elasticsearch keystore settings values in logs such as the audit log or deployment logs in the Logging and Monitoring cluster. The affected APIs are PATCH /api/v1/user and PATCH /deployments/{deployment_id}/elasticsearch/{ref_id}/keystore
In Elastic Cloud Enterprise (ECE) versions prior to 1.1.4 it was discovered that a user could scale out allocators on new hosts with an invalid roles token. An attacker with access to the previous runner ID and IP address of the coordinator-host could add a allocator to an existing ECE install to gain access to other clusters data.
Elastic Cloud Enterprise (ECE) versions prior to 1.1.4 contain an information exposure vulnerability. It was discovered that certain exception conditions would result in encryption keys, passwords, and other security sensitive headers being leaked to the allocator logs. An attacker with access to the logging cluster may obtain leaked credentials and perform authenticated actions using these credentials.
In Elastic Cloud Enterprise (ECE) versions prior to 1.1.4 a default master encryption key is used in the process of granting ZooKeeper access to Elasticsearch clusters. Unless explicitly overwritten, this master key is predictable across all ECE deployments. If an attacker can connect to ZooKeeper directly they would be able to access configuration information of other tenants if their cluster ID is known.