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.
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
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|
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Leave A Reply