介绍

2023 年 1 月 10 日，ManageEngine 发布了针对 CVE-2022-47966 的安全通报。该漏洞是通过发出包含恶意 SAML 响应的 HTTP POST 请求来获得远程执行代码。此漏洞是由于使用老版本的 Apache Santuario 进行 XML 签名验证而导致的。

POC:https://github.com/horizon3ai/CVE-2022-47966

补丁分析

通过分析 ServiceDesk Plus 版本 14003 和版本 14004 之间的差异来找漏洞位置和原因。

默认情况下，Service Desk 安装在C:Program FilesManageEngineServiceDesk 中。我安装了两个版本并提取了 jar 文件进行比较。

虽然有很多 jar 文件已更新，但我们注意到有一个 jar 文件已完全更改。Apache Santuario 的libxmlsec 已从 1.4.1 更新到 2.2.3。要知道版本 1.4.1 已有十多年历史了。对比如下：

这是一个较大的版本跨越，我们从 1.4.2 发行说明（https://santuario.apache.org/java142releasenotes.html）里分析，我们会发现一个重要变化：

• 切换 XML 签名验证步骤的顺序。请参阅问题 44629。

问题 44629 可在此处找到 。它描述了切换 XML 签名验证步骤的顺序以及安全影响。

XML 签名验证介绍

XML 签名验证是一个复杂的问题，但可以简化为以下两个步骤：

• Reference验证 – 验证元素中的每个 <Reference> 元素是否具有有效的摘要值。<SignedInfo>

• 签名验证 – 以加密方式验证 <SignedInfo> 元素。用于确保<SignedInfo>元素未被篡改。

虽然官方 XML 签名验证规范列出了Reference验证，然后是签名验证，但这两个步骤可以按任意顺序执行。由于Reference验证步骤可能涉及处理攻击者控制的 XMLTransforms，因此应该始终首先执行签名验证步骤，保证转换来自可信源。

SAML信息流介绍

支持单点登录的应用程序通常使用 SAML 等授权解决方案。当用户登录远程服务时，该服务会将身份验证请求转发到 SAML 身份提供程序。然后，SAML 身份提供商将验证用户凭据是否正确以及他们是否有权访问指定的服务。最后，身份提供者向客户端返回响应，该响应被转发给服务提供者。

通过 SAML 的登录请求的信息流如下图。关键之一是了解信息流使用客户端浏览器在服务提供商 (SP) 和身份提供商 (IDP) 之间中继所有信息。在本漏洞攻击中，我是将包含恶意 SAML XML 的请求直接发送到服务提供商的断言消费者 (ACS) URL。

漏洞分析

漏洞成分 1：SAML 验证命令

介绍了SAML信息流允许攻击者引入或修改传输中的 SAML 数据， 也证明了Apache Santuario 更新现在在Reference验证之前执行签名验证很重要。这漏洞将利用验证顺序作为利用的第一步。可以参考了解 v1.4.1 和 v.1.4.2 之间的差异。（在 v1.4.1 中，Reference验证发生在代码块顶部附近，并调用 si.verify()。在 v1.4.2 中，对 si.verify() 的调用在 中的签名验证之后移至函数末尾sa.verify(sigBytes).）

漏洞成分2：XSLT注入

每个 <Reference> 元素可以包含一个 <Transform> 元素，负责描述如何在计算其数据之前修改元素。转换允许通过使用XSL 转换 (XSLT) 进行任意复杂的操作。

这些转换在 src/org/apache/xml/security/signature/Reference.java 中执行，最终从上面调用si.verify()。

XSLT 是一种完善的语言，在 ManageEngine 环境中，它能够执行任意 Java 代码。我们可以提供以下代码片段来执行任意系统命令：

<ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime" xmlns:ob="http://xml.apache.org/xalan/java/java.lang.Object">        <xsl:template match="/">            <xsl:variable name="rtobject" select="rt:getRuntime()"/>            <xsl:variable name="process" select="rt:exec($rtobject,'{command}')"/>            <xsl:variable name="processString" select="ob:toString($process)"/>            <xsl:value-of select="$processString"/>        </xsl:template>    </xsl:stylesheet></ds:Transform>

通过利用 Apache Santuario v1.4.1 中的 SAML 验证顺序和提供运行任意 Java 类访问权限的 Java XSLT 库，我们可以利用 ManageEngine 产品中的此漏洞来获得远程代码执行。

SAML 单点登录配置

安全断言标记语言 (SAML) 是一种在应用程序或服务提供商与身份提供商之间共享身份验证和授权信息的规范。具有单点登录功能的 SAML 让用户方便维护他们使用的所有应用程序的凭据，并且为 IT 管理员提供了一个集中的用户管理位置。

SAML 使用 XML 签名验证来确保服务提供商和身份提供商之间传递的消息的安全传输。

我们可以通过导航到 Admin -> Users & Permissions -> SAML Single Sign On 来启用 SAML SSO，我们可以在其中输入我们的身份提供商信息。正确配置后，我们将在登录页面上看到“使用 SAML 单点登录登录”：

POC

POC地址在文章最开始部分，配置 SAML 后，断言使用者 URL 现在将在 https://<hostname>:8080/SamlResponseServlet 处处于活动状态，我们可以发送恶意 SAML 响应。

python3 CVE-2022-47966.py --url https://10.0.40.90:8443/samlLogin/<guid> --issuer https://sts.windows.net/<guid>/ --command notepad.exe

由于 ServiceDesk 作为服务运行，因此没有桌面可以显示 GUInotepad.exe，因此我们使用 ProcessExplorer 来检查漏洞利用是否成功，如下成功运行了：

这POC还针对 Endpoint Central 进行了测试， POC 无需修改即可在许多与 ServiceDesk Plus 或 EndpointCentral 共享部分代码库的 ManageEngine 产品上运行。

还有，AD 相关产品（AdManager 等）对必须通过的 SAML 响应进行了额外检查。会执行检查以验证 SAML 响应是否来自预期的身份提供商。 POC 有一个可选的 --issuer 参数来提供用于 <Issuer> 元素的信息。此外，AD 相关产品具有不同的包含 guid 的 SAML 登录端点 URL。

python3 CVE-2022-47966.py --url https://10.0.40.90:8443/samlLogin/<guid> --issuer https://sts.windows.net/<guid>/ --command notepad.exe

结论

总之，当 Apache Santuario <= v1.4.1 时，该漏洞很容易被利用，并且可以通过以下几个条件实现：

• Reference验证在签名验证之前执行，从而允许执行恶意 XSLT 转换。

• 执行 XSLT 转换允许攻击者执行任意 Java 代码。

Apache Santuario 处于 v1.4.1 和 v2.2.3 之间（当时某些受影响的 ManageEngine 产品（例如 Password Manager Pro），此漏洞仍然可以被利用。Khoadha 大神的博客记录了他们在研究中进一步绕过验证的情况，也绝对值得一读。https://blog.viettelcybersecurity.com/saml-show-stopper/

原文始发于微信公众号（军机故阁）：CVE-2022-47966 ManageEngine RCE