在一次外部渗透测试中，我偶然发现了一个可见的 Solr 管理面板。我专注于这个特定的应用程序来测试隐藏在下面的东西。

（Solr的主页）

Apache Solr 的版本是 8.3.1，运行在 Windows 上。请注意，这次渗透测试是在 2020 年进行的，远早于log4j的发现。在此特定版本下，应用程序应该容易受到CVE-2019-17558的攻击：

当 Solr 处理文本查询时，可以添加使用查询结果处理的自定义 Apache Velocity 模板。问题是无需身份验证即可激活此功能。借助此启用的服务器端模板注入，使用 Velocity 语言的内置功能可以非常简单地执行代码。

Solr 在 8.3.1 和 8.4.0 中通过默认禁用此自定义查询的 Velocity 模板渲染解决了这个问题。此外，无法再从 API 端点修改配置。但是，如果满足某些特定条件，版本 8.3.1 仍然容易受到攻击。

然后，我从 Solr 官方网站下载了完全相同的版本，并开始在我的 Windows VM 中探索该应用程序。

0x01 初步发现

在主页面上，会显示大量系统信息，比如服务器上的不同路径，以及Solr的版本等。在以下屏幕截图的左侧，没有可用的cores。

（Solr 的索引页披露有趣的信息）

Apache Solr 基于Cores。每个core都是一个独立的数据库，可以从网络界面查询和删除。也可以创建新的cores，但用户必须事先手动将配置文件上传到服务器。

从服务器的文件目录来看，每个core在{Base Dir}/server/solr/{Core name}里面都有一个命名目录。在同一级别，还有一个名为 configsets 的默认目录，其中包含 Solr 核心示例及其所需文件。我很快发现可以使用此目录中存在的默认配置文件来创建虚拟核心。这种创建是可能的，因为没有限制 InstanceDir 变量的路径。因此，即使在全新的 Solr 安装上，也可以访问至少一个核心及其功能。参数 instanceDir 和 dataDir 可以设置为任何绝对或相对路径，这可以简化攻击。

（instanceDir 设置为 configsets 目录的路径）

（新core已创建）

对于 Solr 的以前 CVE（例如 CVE-2019-17558），这也是一个很好的工具，因为它们中的大多数都需要至少有一个内核才能被利用。

在测试 CVE-2019-17558 时，文档指出，如果 Velocity 或 XSLT 文件存在于特定目录中，则查询可以被处理。记住这一点总是一件好事，因为任意 XSLT 文件上传通常意味着在服务器上执行任意代码（如果它们被解释）。

以下是到目前为止发现的内容的摘要：

》如发现可以使用任意文件上传来执行任意代码。

》无需将文件上传到服务器即可创建核心。

》如果节点创建失败，则可能会在磁盘上的任何位置创建空目录。

》可以通过核心创建模块接口返回的不同错误来发现计算机上是否存在文件。

》Solr 的大部分参数都容易受到路径遍历的影响。

0x02 上传文件

在core中，可以上传文件和发送数据以供后端处理。使用 Solr 提供的测试文件，应用程序对其进行处理，但不会将它们保存在服务器上。但是，当文件的大小超过阈值时，服务器会将完整内容保存在服务器目录 {Base Dir}/server/tmp/ 中的 .tmp 文件中。

(Web UI 中启用文件上传的页面)

临时文件以以下名称存储：upload_{UUID}_{iterator}.tmp

UUID 是一个常量值，在每次重新启动 Solr 服务器时设置。对于第一个上传的文件，迭代器设置为 000000000。如果将新的 .tmp 文件添加到文件夹，则它会增加。在 /tmp 文件夹中，文件在 1 小时后被删除，这为我们的开发留出了足够的时间。

我没有找到其他可能泄露 UUID 的地方，但由于服务器运行在 Windows 上，因此可以使用 Windows 短文件名的技巧：

在 Windows 上，文件可以有一个更简单的名称，由 6 个字母数字字符后跟一个平铺字符和一个数字组成。使用 Windows 命令 dir /X 可以轻松找到这些名称。例如，名为 

upload_2c59709f_b0df_400b_ad3b_668e1f02e340_00000000.tmp 的文件的简称为 UPLOAD~1.tmp。以下上传的文件将具有短名称 UPLOAD~i.tmp，其中 i = 2,3,4。之后名称变为 UP{4 字母数字哈希}~1.tmp，因为短文件名是如何由 Windows 实现的。

现在，可以在{Base Dir}/server/tmp/ 目录中上传任意文件，并且可以猜测文件名。下一步是上传 XSLT 文件并使用查询触发它：

http://localhost:8983/solr/new_core/select?q=:&wt=xslt&tr=../../../../../tmp/UPLOAD~1.tmp&rows=1000

Error 500: [Redacted] Caused by: java.io.IOException: File C:\Solr\solr-8.3.1\server\tmp\UPLOAD~1.tmp is outside resource loader dir C:\Solr\solr-8.3.1\server\solr\configsets_default\conf; set -Dsolr.allow.unsafe.resourceloading=true to allow unsafe loading

即使我们的路径遍历成功，也会存在额外的安全检查。XSLT 文件必须位于与core相同的文件夹中，才能被视为安全以允许执行。

0x03 将core带入我们的文件上传

这个想法很简单。/tmp 目录下可以上传任意文件。如果存在配置文件，则可以在任意路径创建核心。因此，可以利用临时目录来创建核心。然后，如果 XSLT 文件存在于临时目录中，则该核心将认为它们是安全的。

要创建核心，应用程序至少需要 2 个文件：solrconfig.xml 和 schema.xml。在真正的核心创建中，文件引用其他文件来加载，例如语言包。为了降低复杂性，这 2 个文件被修剪到最低限度。

(使用 tmp 目录中的 2 个上传文件创建核心)

0x04 来自 XSLT 文件的 RCE

在 /tmp 目录中创建核心后，可以上传 XSLT 文件并安全触发。使用 PayloadAllTheThings 中可用的有效负载，获得任意命令执行非常简单。

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:dyn="http://exslt.org/dynamic" extension-element-prefixes="dyn" xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime" xmlns:sys="http://xml.apache.org/xalan/java/java.lang.System" xmlns:ob="http://xml.apache.org/xalan/java/java.lang.Object"><xsl:output media-type="text/xml" method="xml" indent="yes"/><xsl:template match='/'><add><xsl:variable name="rtobject" select="rt:getRuntime()"/><xsl:variable name="process" select="rt:exec($rtobject,'calc.exe')"/><xsl:variable name="processString" select="ob:toString($process)"/><xsl:value-of select="$processString"/></add></xsl:template>[REDACTED]</xsl:stylesheet><!-- comments used to make the file bigger than 20kb AAAAAAAAAAAAAA[REDACTED]AAAAAAAAA-->

它将运行著名的 calc.exe。最后一次从以下 URL 触发 XSLT：

http://localhost:8983/solr/new_core_tmp/select?q=*:*&wt=xslt&tr=../UPLOAD~1.tmp

0x05 关于临时文件的注意事项

即使必须猜测上传文件的短名称，此漏洞也非常可靠，因为：

1、/tmp目录下的临时文件每小时删除一次。

2. 当在/tmp 目录中创建恶意核心时，它会自动删除所有其他.tmp 文件。这是此漏洞利用的一个很好的功能，因为之后上传 XSLT 意味着它肯定可以通过 Windows 短名称 UPLOAD~1.tmp 访问。

0x06 综述

从暴露的 Solr 接口，可以在服务器上获得 RCE。Windows 上的 8.3.2 版之前存在此弱点。在较新的版本中，实施了以下限制：

》.tmp 文件不再存储为普通文件

》无法在 /tmp 文件夹中创建新核心

》大多数路径遍历都被阻止或列入白名单

对于linux，如果有办法泄露UUID，这个漏洞就不需要Windows的短文件名机制，就可以在Unix服务器上进行RCE。

0x07 当前对 Solr 的利用

》Solr 过去有很多漏洞，可以找到至少一个可靠的 RCE。此存储库中列出了其 PoC 的良好资源：(2020 年之前的 CVE)

https://github.com/veracode-research/solr-injection

》发现Solr 8.8.1之前版本存在任意文件上传漏洞。使用此上传 XSLT 可能会导致类似的 RCE。

》著名的log4shell存在于8.11.1之前的所有Solr版本中。

》Google Dork：

intitle:”Solr Admin” “Solr Query Syntax”

0x08 关于管理 API 的注意事项

据我所知，Solr 的基本安装不使用任何类型的安全措施，例如密码保护或帐户管理。提高安全性由用户通过安装附加插件或防火墙配置手动完成。依靠普通用户来保护应用程序是非常危险的，特别是如果管理员界面默认对每个人都可见（并且易受攻击）。

0x09 PoC

POC可在此处获得：

https://github.com/scrt/Apache-Solr-8.3.1-RCE

文章来源：信安百科