The ElasticSearch vulnerability is numbered cve-2015-1427, affecting version 1.3.0-1.3.7 and 1.4.0-1.4.2, the cause of the vulnerability see:http://drops.wooyun.org/papers/5107, this article specifically discusses the exploit.
The 1.2.0 version disables script execution by default, and if you want to use this feature, set the script.disable_dynamic:true in Elasticsearch.yml .
In the 1.3.0 version, we started using groovy and sandbox for scripting, which used the white-list mechanism, Restricts the classes and methods that can be called, and so on.
However, because of the reflection mechanism in Java, we can get to Runtime by the class in the whitelist , which makesthe remote code execution vulnerability very powerful.
Needless to say, the python client using es is tested:
Note here that you need to specify the type of script as groovy. This is because in the 1.3 version,mvel is still the default language and the effect is as follows:
Since it is remote code execution, the attack surface is too broad, this acid cool.
(1) Denial of service attacks
Call exit .
(2)Getshell
Test results, successfully returned a rebound shell:
If Linux, many servers are running with root privileges, the right to save ~ ~
(3) Arbitrary file read
ReadLine can get echo after getting to the input stream.
here no longer writes Span style= "Font-family:times New Roman" >exp program because it's relatively simple, not applicable es python api es server. A query Corresponds to an attack method.
In bulk use, sweep the IP segment of the 9200 and then attack the code on the line, I hope you have fun.
ElasticSearch Groovy Remote code Execution POC and EXP