ElasticSearch Groovy script Remote Code Execution Vulnerability (CVE-2015-1427)

ElasticSearch Groovy script Remote Code Execution Vulnerability (CVE-2015-1427)

0x00 Preface

ElasticSearch is a JAVA-developed search and analysis engine. 2014, once exposed a Remote Code Execution Vulnerability (CVE-2014-3120), the vulnerability appeared in the script query module, because the search engine supports the use of script code (MVEL), as a expression for data operations, attackers can execute arbitrary java code through MVEL construction. Later, the script language engine is replaced with Groovy and added to the sandbox for control. Dangerous code will be intercepted, as a result, the sandbox restriction caused Remote Code Execution. Currently, no public poc has been seen on the Internet. After some research, we found the method of utilization, the following describes how a vulnerability is generated.

Groovy is a scripting language running on JVM. Its syntax is similar to that of java. It can also call various objects and methods in java, but Groovy's syntax is simpler.

0x01 details

First, run a script-containing query code:

POST http://127.0.0.1:9200/_search?pretty HTTP/1.1User-Agent: esHost: 127.0.0.1:9200Content-Length: 184{"size":1,    "script_fields": {        "lupin": {            "script": "1 + 6"        }    }}

In the above request, 1 + 6 is the script code we executed, and 7 is the execution result returned below:

Run the following code:

POST http://127.0.0.1:9200/_search?pretty HTTP/1.1User-Agent: esHost: 127.0.0.1:9200Content-Length: 184{"size":1,    "script_fields": {        "lupin": {            "script": "new java.lang.ProcessBuilder(“calc”)"        }    }}

After execution, an error is reported. From the error, we can see that constructing a java. lang. ProcessBuilder object is not allowed:

Next, let's take a look at the Code related to the ElasticSearch sandbox. The Sandbox class is com. elasticsearch. script. groovy. groovySandboxExpressionChecker, which customizes the Groovy sandbox and performs security detection on the expression. However, this sandbox is different from the SecurityManager sandbox in JAVA, from the code, we can see that this sandbox is only based on the blacklist and whitelist. It can be used to determine whether the expression is legal in terms of expression semantics. It can be said that it is a "Shallow" sandbox. Simply put, for example, if the sandbox setting does not allow you to call the shell () method, you can directly call the shell () method. If the shell () string is found in the expression, an illegal call is reported, however, if a method named poc () calls the shell () method (poc () {shell ()}), when the poc () method is called, the shell () method is indirectly called and no error is reported. Specifically, if the isAuthorized (Expression expression) method returns false, it indicates that the Expression is invalid. true indicates that the expression is valid. You can see from the implementation of isAuthorized, it detects both method calls and Object Structures Based on the blacklist and whitelist:

From the preceding whitelist, we can see that classes that allow the construction of objects and method calls are common classes and there is no class we can use, if we want to use reflection to call the Class we want to call, and the method blacklist limits the call of getClass, we cannot get the Class object through the getClass method, however, we can see that the forName method is not restricted in the method whitelist, that is, if we can obtain the Class object, call the forName method to obtain the class we want to access. So how can we get a Class object? First of all, I think of using java. lang. String. class to let JVM return the class Object of the String class through the Class. We can see that the class object is indeed obtained:

Can we call the forName method through this Class object to load the java. lang. Runtime Class we want most? Unfortunately, an error is returned:

The error is caused by java. lang. the String class is not allowed to call methods. Only the class in the defaultReceiverWhiteList whitelist can be called. This control is implemented in the Groovy sandbox class org. codehaus. groovy. control. customizers. judgment Made in secureastmimizer:

Now that we have another idea, we can use the Class in the white list to get the Class object and then call the forName method. Can we break through this restriction? I will use java here. lang. math class. This class is in the recevicer whitelist. You can see that java is successfully obtained. lang. runtime class:

POST http://127.0.0.1:9200/_search?pretty HTTP/1.1User-Agent: esHost: 127.0.0.1:9200Content-Length: 132{"size":1,    "script_fields": {        "lupin": {            "script": "java.lang.Math.class.forName(“java.lang.Runtime”)"        }    }}

With the Runtime class, the subsequent tasks are easy to handle. The methods to be called are not included in the method blacklist. I will not publish the specific POC here. The students who understand the above principles naturally understand: