CVE-2020-13957：Apche Solr 未授权上传漏洞复现

作者： hatjwe&ebounce@Timeline Sec

本文字数：1778

阅读时长：5~6min

声明：请勿用作违法用途，否则后果自负

0x01 简介

0x02 漏洞概述

整个利用链流程：

上传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执行

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

0x05 漏洞复现

1、将

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

2、通过上传API将zip上传

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

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

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

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

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

0x06 漏洞分析

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

org.apache.solr.handler.admin.ConfigSetsHandler

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

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

org.apache.solr.handler.admin.ConfigSetsHandler

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

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

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

随后我们跟进下一步：

同样的道理这里出现关键词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 团队