Increased Elasticsearch Recognizance Scans, (Tue, Aug 19th)
文章指出近期针对 Elasticsearch 实例的扫描活动增加,攻击者通过访问 `/ _cluster/settings` 接口确认目标存在。尽管该接口返回的信息有限,但暴露的 Elasticsearch 实例仍可能成为后续攻击的目标。同时提到近期关于 Elastic EDR 零日漏洞的报道引发关注。 2025-8-19 18:16:29 Author: isc.sans.edu(查看原文) 阅读量:8 收藏

I noticed an increase in scans that appear to try to identify Elasticsearch instances. Elasticsearch is not a new target. Its ability to easily store and manage JSON data, combined with a simple HTTP API, makes it a convenient tool to store data that is directly accessible from the browser via JavaScript. Elasticsearch has, in particular, been popular for consolidating log data, and the "ELK" (Elasticsearch, Logstash, Kibana) platform has been a very successful standard for open source log management.

Call me old fashioned, but the idea of exposing my database directly to the user has always been a bit "frightening" to me. But the kids like to do dangerous things, and as a result we have plenty of exposed Elasticsearch instances. No surprise that attackers are looking for them.

The particular query I have been seeing these last couple days is "/_cluster/settings ". Running this against my own Elasticsearch instance:

$ curl -isku $ELASTIC_USERNAME:$ELASTIC_PASSWORD https://localhost:9200/_cluster/settings/
HTTP/1.1 200 OK
X-elastic-product: Elasticsearch
content-type: application/json
content-length: 32

{"persistent":{},"transient":{}}

does not really retrieve any concerning details, but it easily proves that we have a running Elasticsearch instance. 

Without authentication, a 401 error is returned, but again, there are no details about what version I am running. It is, however, possible that the formatting or the details of the error message can be used for fingerprinting.

 curl -isk https://localhost:9200/_cluster/settings/
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="security", charset="UTF-8"
WWW-Authenticate: Bearer realm="security"
WWW-Authenticate: ApiKey
content-type: application/json
content-length: 497

{"error":{"root_cause":[{"type":"security_exception","reason":"missing authentication credentials for REST request [/_cluster/settings/]","header":{"WWW-Authenticate":["Basic realm=\"security\", charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}}],"type":"security_exception","reason":"missing authentication credentials for REST request [/_cluster/settings/]","header":{"WWW-Authenticate":["Basic realm=\"security\", charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}},"status":401}

My best guess is that this actor is just looking for possible instances of Elasticsearch to come back later for details. Elasticsearch is always somewhat scanned for, but the request for /_cluster/settings/ is new. The graph below compares all requests for Elasticsearch with requests for /_clustser/settings

graph of elasticsearch related requests over the last 30 days

This weekend, a blog post by cyberNK regarding an "Elastic EDR Zero-Day" made headlines [1]. I do not think these requests are related, and Elastic disputed the blog post [2].

[1] https://infosecilluminati.medium.com/elastic-edr-zero-day-bypass-detection-execute-malware-and-trigger-bsod-what-happened-and-how-to-363ca11062b9
[2] https://discuss.elastic.co/t/elastic-response-to-blog-edr-0-day-vulnerability/381093

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|


文章来源: https://isc.sans.edu/diary/rss/32212
如有侵权请联系:admin#unsafe.sh