Solr on 诗与胡说

Apache Solr Velocity模板注入漏洞分析

Tue, 05 Nov 2019 09:40:22 +0000

0x01 概述

10月30日，研究员S00pY在GitHub发布了Apache Solr Velocity模版注入远程命令执行的poc，该漏洞通过设置资源加载属性，利用VelocityResponseWriter插件执行自定义模板，进而进行远程代码执行，危害较大，下面是分析过程。

0x02 环境搭建

选择Solr 8.2.0二进制版本进行分析和复现

下载地址：https://archive.apache.org/dist/lucene/solr/8.2.0/

调试命令

$ cd solr-8.2.0\server
$ java "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9000" -Dsolr.solr.home="../example/example-DIH/solr/" -jar start.jar --module=http

IDEA新建远程调试即可

0x03 前置概念

VelocityResponseWriter(Velocity响应编写器)是 contrib/velocity 目录中可用的可选插件。当使用诸如 “_default”、“techproducts” 和 “example / files” 等配置时，它为浏览用户界面提供动力。

必须添加它的 JAR 和依赖项（通过<lib>或 solr/home lib 包含），并且必须在 solrconfig.xml 注册，默认已经注册

其中有一个属性params.resource.loader.enabled，默认是false，需要手动开启

该参数表示允许加载程序在 Solr 请求参数中指定模板，例如：

http://localhost:8983/solr/gettingstarted/select?q=\*:*&wt=velocity&v.template=xxx&v.template.xxx=CUSTOM%3A%20%23core_name

v.template=xxx表示创建一个名为“xxx”的模板，v.template.xxx则是模板内容

当这个属性设置为true时用户就可以传入任意模板内容进行模板注入，从而执行任意命令

0x04 漏洞分析

设置`params.resource.loader.enabled`属性

在Solr的Web.xml文件中能看到所有的请求都交给org.apache.solr.servlet.SolrDispatchFilter来处理

具体的则是其中的doFilter()方法。在对路由经过初步处理后，进行两个关键操作：

HttpSolrCall call = this.getHttpSolrCall(request, response, retry);
//...
SolrDispatchFilter.Action result = call.call();

初始化一个HttpSolrCall对象后调用它的call()方法，在call()方法中会对路由中具体的组件初始化出对应的handler，再由这个handler去调用这个组件的各个方法

在Solr 8.2.0中具体的路由有37个，每一类都有对应的handler，都在org.apache.solr.handler中定义，例如solr/solr/get对应的hendler为RealTimeGetHandler

而/solr/solr/config 由SolrConfigHandler来分别处理GET和POST请求

SolrConfigHandler.Command command = new SolrConfigHandler.Command(req, rsp, httpMethod);
if ("POST".equals(httpMethod)) {
    if (configEditing_disabled || this.isImmutableConfigSet) {
        String reason = configEditing_disabled ? "due to disable.configEdit" : "because ConfigSet is immutable";
        throw new SolrException(ErrorCode.FORBIDDEN, " solrconfig editing is not enabled " + reason);
    }

    try {
        command.handlePOST();
    } finally {
        RequestHandlerUtils.addExperimentalFormatWarning(rsp);
    }
} else {
    command.handleGET();
}

私有类Command会对当前路由的webapp和path做一个切分，对于POST请求，分别会通过SolrConfigHandler.Command#handlePOST()方法来处理

接着调用SolrConfigHandler.Command#handleCommands()，Solr中Config API对应的实现都是由这个方法来完成的，如set-property、unset-property等

此处主要关注更新配置的参数

从文档可以了解对于responsewriter的操作有下面三个

add-queryresponsewriter
update-queryresponsewriter
delete-queryresponsewriter

代码中也能看到对操作名称按-进行分割提取出对应操作，然后由updateNamedPlugin()方法来完成配置文件的创建/覆盖操作，具体跟入看一下

在updateNamedPlugin()中有个verifyClass的调用，当传入参数没有设置runtimeLib时会去创建class字段指定的类，所以当我们传入VelocityResponseWriter时，会在其初始化的时候写入对应的参数

然后返回到handleCommands()中把配置写入到configoverlay.json文件

因此，通过config api可以重新设置VelocityResponseWriter的属性，为下一步加载模板提供入口

三种命令的区别如下：

add- 命令都会将新配置添加到configoverlay.json，这将覆盖solrconfig.xml组件中的任何其他设置； update- 命令覆盖configoverlay.json中的现有设置； delete-命令从configoverlay.json中删除设置

注入自定义模板

在SolrDispatchFilter中有有一个枚举类Action，定义了每个handler的所属的操作，通过ConfigAPI更新配置时，当前的action是PROCESS，因此会进入HttpSolrCall.call()的PROCESS分支

之后通过QueryResponseWriterUtil.writeQueryResponse()进入VelocityResponseWriter.write，在这个方法中完成Velocity的解析

首先会初始化一个解析模板的引擎VelocityEngine，在创建引擎的过程中会检查是否允许参数资源加载，这也就是第一个请求设置的params.resource.loader.enabled属性值。由于solr.resource.loader.enabled默认是开启的，所以此处只需要设置params的值

之后通过Template.getTemplate()设置自定义模板，然后进入Template.merge()进入AST解析，在解析过程中会调用到ASTMethod.execute()方法，这个流程与之前披露的CVE-2019-11581 JIRA模板注入漏洞是一样的，不再赘述，详细可以参考CVE-2019-11581 ATLASSIAN JIRA 未授权模板注入漏洞分析

回过头看一下Velocity渲染的大致流程：

Velocity 渲染引擎首先磁盘加载模板文件到内存，然后解析模板模板文件为 AST 结构，并对 AST 中每个节点进行初始化，第二次加载同一个模板文件时候如果开启了缓存则直接返回模板资源，通过使用资源缓存节省了从磁盘加载并重新解析为 AST 的开销。

而ASTMethod.execute()方法设计之初是在Velocity parse解析模板的过程中，通过反射调用相关方法完成正常模板渲染动作，例如获取背景颜色、获取 text 内容、获取页面编码等，但当此处攻击者传入精心构造的数据后，利用反射执行了java.lang.Runtime.getRuntime，成功达到命令执行的目的

调用栈

PoC

参考

CVE-2019-0193 Apache Solr远程命令执行漏洞分析

Wed, 07 Aug 2019 10:38:17 +0000

0x01 概述

8月1日，Apache Solr官方发布了CVE-2019-0193漏洞预警，此漏洞存在于可选模块DataImportHandler中，DataImportHandler是用于从数据库或其他源提取数据的常用模块，该模块中所有DIH配置都可以通过外部请求的dataConfig参数来设置，由于DIH配置可以包含脚本，因此该参数存在安全隐患。

参考：https://issues.apache.org/jira/browse/SOLR-13669

0x02 环境搭建

选择Solr 8.1.1二进制版本进行分析和复现

下载地址：https://archive.apache.org/dist/lucene/solr/8.1.1/

调试命令

$ cd solr-8.1.1\server
$ java "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9000" -Dsolr.solr.home="../example/example-DIH/solr/" -jar start.jar --module=http

IDEA新建远程调试即可

0x03 前置概念

solr支持从Dataimport导入自定义数据，dataconfig需要满足一定语法，参考

其中ScriptTransformer可以编写自定义脚本，支持常见的脚本语言如Javascript、JRuby、Jython、Groovy和BeanShell

ScriptTransformer容许用脚本语言如Javascript、JRuby、Jython、Groovy和BeanShell转换，函数应当以行（类型为Map<String,Object>）为参数，可以修改字段。脚本应当写在数据仓库配置文件顶级的script元素内，而转换器属性值为script:函数名。

使用示例：

<dataconfig>
  <script><![CDATA[
    function f2c(row) {
      var tempf, tempc;
      tempf = row.get('temp_f');
      if (tempf != null) {
        tempc = (tempf - 32.0)*5.0/9.0;
        row.put('temp_c', temp_c);
      }
      return row;
    }
    ]]>
  </script>
  <document>

    <entity name="e1" pk="id" transformer="script:f2c" query="select * from X">
    </entity>
  </document>
</dataConfig>

Nashorn引擎

在Solr中解析js脚本使用的是Nashorn引擎，可以通过Java.typeAPI在JavaScript中引用，就像Java的import一样，例如：

var MyJavaClass = Java.type(`my.package.MyJavaClass`);

var result = MyJavaClass.sayHello('Nashorn');
print(result);

0x04 漏洞分析

Solr处理dataimport请求时，首先进入dataimport/DataImportHandler的handleRequestBody方法，当前请求的command为full-import，因此通过maybeReloadConfiguration重新加载配置

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

随后在loadDataConfig中通过readFromXml方法解析提交的配置数据中的各个标签，比如document，script，function，dataSource等，传入的script自定义脚本即在此处被存入script变量，递归解析完所有标签构建出DIHConfiguration对象并返回。

获取到配置信息后通过this.importer.runCmd()方法处理导入过程

this.importer.runCmd(requestParams, sw);

在doFullImport中，首先会创建一个DocBuilder对象，DocBuilder的主要功能是从给定配置中创建Solr文档，同时会记录一些状态信息。随后通过execute()方法会通过遍历Entity的所有元素来解析config结构，最终得到是一个EntityProcessorWrapper对象。EntityProcessorWrapper是一个比较关键的类，继承自EntityProcessor，在整个解析过程中起到重要的作用，可以参考

https://lucene.apache.org/solr/8_1_1/solr-dataimporthandler/org/apache/solr/handler/dataimport/EntityProcessorWrapper.html

在解析完config数据后solr会把最后更新时间记录到配置文件中，这个时间是为了下次进行增量更新的时候用的。接着通过this.dataImporter.getStatus()判断当前数据导入是“全部导入”还是“增量导入”，两个操作对应的方法分别为doDelta()和doFullDump()，此处的操作是full-import，因此调用doFullDump()

在doFullDump()中调用的是DocBuilder.buildDocument()方法，这个方法会为发送的配置数据的每一个processor做解析，当发送的entity中含有Transformers时，会进行相应的转换操作，例如转换成日期格式(DateFormatTransformer)、根据正则表达式转换(RegexTransformer)等，这次出现问题的是ScriptTransformer，可以根据用户自定义的脚本进行数据转换。由于脚本内容完全是用户控制的，当指定的script含有恶意代码时就会被执行，下面看一下Solr中如何执行javascript代码：

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

通过applyTransformer()执行转换，调用的是相应Transformer的transformRow方法

ScriptTransformer允许多种脚本语言调用，如Javascript、JRuby、Jython、Groovy和BeanShell等，transformRow()方法则会根据指定的语言来初始化对应的解析引擎，例如此处初始化的是scriptEngine，用来解析JavaScript脚本

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也并没有对标签内容做限制，导致可以执行任意代码。

调用栈情况

0x05 补充

值得注意的是，官方给出的临时修复方案并不能缓解漏洞，当把相应的index core的配置文件置为空时，dataimport的时候只是获取不到默认的配置，但是依然能够通过这个接口发送PoC，漏洞也依然能够触发，解决办法是把相应配置文件中的dataimport requestHandler全部注释并重启Solr服务器，才能彻底关闭这个接口缓解漏洞。

Solr on 诗与胡说

Apache Solr Velocity模板注入漏洞分析

0x01 概述

0x02 环境搭建

0x03 前置概念

0x04 漏洞分析

设置params.resource.loader.enabled属性

注入自定义模板

CVE-2019-0193 Apache Solr远程命令执行漏洞分析

0x01 概述

0x02 环境搭建

0x03 前置概念

0x04 漏洞分析

0x05 补充

设置`params.resource.loader.enabled`属性