黑客攻击 Apple - SQL 注入到远程代码执行

介绍

在我们的上一篇博客文章中，我们深入研究了 Lucee 的内部工作原理，并查看了 Masa/Mura CMS 的源代码，潜在攻击面的巨大性让我们震惊。很明显，投入时间理解代码是有回报的。经过一周的探索，我们偶然发现了几个漏洞利用入口点，其中包括我们能够在 Apple Book Travel 门户中利用的一个关键 SQL 注入漏洞。

在这篇博文中，我们的目标是分享我们的见解和经验，详细介绍我们如何识别漏洞接收器、将其链接回其源头，以及如何利用 SQL 注入来实现远程代码执行 (RCE)。

寻找水槽

通过使用 Masa/Mura CMS，我们了解了我们的攻击面 - 主要是 Apple 环境中可访问的攻击面。我们的主要关注点是 JSON API，因为它公开了一些可在 Apple 环境中访问的方法。我们发现的任何可能存在漏洞的接收器都应该在 JSON API 中找到其来源。

我们考虑优化我们的方法来简化我们的源代码审查流程。我们探索了静态分析器或 CFM 解析器的可用性，这些分析器或 CFM 解析器能够遍历代码，同时忽略清理程序。

例如，这是通过基于标签的 CFM 编写安全参数化 SQL 查询的方式：

<cfquery>select * from table where column=<cfqueryparam cfsqltype="cf_sql_varchar" value="#arguments.user_input#"></cfquery>

这就是不安全 SQL 查询的编写方式：

<cfquery>select * from table where column=#arguments.user_input#</cfquery>

cfquery如果我们能够解析和遍历代码，并且只打印具有未经净化的输入的标签，无论是否包含标签，那就太好了cfqueryparam。我们发现https://github.com/foundeo/cfmlparser可以让我们做到这一点。

以下是我们针对 SQL 注入接收器检测的方式：

• 解析每个 CFM/CFC 文件。

• 浏览每个语句，如果它是标签且名称为 ，则选择该语句cfquery。

• 删除 cfquery 代码块内的所有标签（如 cfqueryparam），如果它仍然存在arguments于代码块中，则输入不会参数化，并且在没有其他验证到位的情况下，查询容易受到 SQL 注入的影响。

• 打印此查询。

<cfscript>    targetDirectory = "../mura-cms/";    files = DirectoryList(targetDirectory, true, "query");for (file in files) {if (FindNoCase(".cfc", file.name) or FindNoCase(".cfm", file.name)) {            fname = file.directory & "/" & file.name;if (file.name != "dbUtility.cfc" && file.name != "configBean.cfc" && !FindNoCase("admin", file.directory) && !FindNoCase("dbUpdates", file.directory)) {                filez = new cfmlparser.File(fname);                statements = filez.getStatements();                info = [];for (s in statements) {if (s.isTag() && s.getName() == "cfquery" && FindNoCase("arguments", s.getStrippedInnerContent(true, true))) {                        WriteOutput("Filename: <b>#fname#</b>");                        WriteOutput("<br><br>" & s.getStrippedInnerContent(true, true));                        WriteOutput("<br><br><br><br>");                    }                }            }        }    }</cfscript>

我们开始检查结果时考虑了一些事情，例如忽略输入，siteid因为 JSON API 会提前验证它。

有两个其他输入的查询之一是这样的：

跟踪接收器到源

查看具有此查询的函数得出的结论是，只有一个可利用的参数，即ContentHistID.该参数columnid是数字，并且siteid默认情况下经过验证。

<cffunction name="getObjects" output="false">  <cfargument name="columnID" required="yes" type="numeric" >  <cfargument name="ContentHistID" required="yes" type="string" >  <cfargument name="siteID" required="yes" type="string" >  <cfset var rsObjects=""/>  <cfquery attributeCollection="#variables.configBean.getReadOnlyQRYAttrs(name='rsObjects')#">select tcontentobjects.object,tcontentobjects.name,tcontentobjects.objectid, tcontentobjects.orderno, tcontentobjects.params, tplugindisplayobjects.configuratorInit from tcontentobjects    inner join tcontent On(    tcontentobjects.contenthistid=tcontent.contenthistid    and tcontentobjects.siteid=tcontent.siteid)    left join tplugindisplayobjects on (tcontentobjects.object='plugin'                      and tcontentobjects.objectID=tplugindisplayobjects.objectID)where tcontent.siteid='#arguments.siteid#'    and tcontent.contenthistid ='#arguments.contentHistID#'    and tcontentobjects.columnid=#arguments.columnID#    order by tcontentobjects.orderno  </cfquery>  <cfreturn rsObjects></cffunction>

该函数在 core/mura/content/contentRendererUtility.cfc 组件中的函数getObjects内调用。dspObjects

调用堆栈为：

JSON API -> processAsyncObject -> 对象情况：displayregion -> dspobjects() -> getobjects()。

触发和利用 SQL 注入

默认情况下，Lucee 在作为输入传递时通过在单引号前添加反斜杠来转义单引号。这可以通过使用反斜杠转义单引号之一来管理

这应该会触发 SQL 注入：

/_api/json/v1/default/?method=processAsyncObject&object=displayregion&contenthistid=x%5c'

然而，事实并非如此。重新访问源代码后，我们发现了dspObjects函数中的一个关键条件。在调用 之前getObjects，if必须满足一个条件：isOnDisplay必须在 Mura servlet 事件处理程序中将该属性设置为 true。最初，我们假设事件处理程序上的任何属性都可以通过将属性名称及其值作为参数传递来简单地设置。这个假设是基于我们在代码库中的调试会话。

我们尝试isOnDisplay以这种方式设置属性的尝试没有成功。看来在代码中的某个地方，这个属性被覆盖了。

在进行一些 grep 搜索后，我们偶然发现了JSON APIstandardSetIsOnDisplayHandler中的函数调用。processAsyncObjects

看起来，通过简单地传递previewID具有任何值的参数，我们可以设置该previewID属性，这反过来又将该isOnDisplay属性设置为 true。

/_api/json/v1/default/?method=processAsyncObject&object=displayregion&contenthistid=x%5c'&previewID=x

它起作用了：

由于这是一个基于错误的 SQL 注入，我们可以很容易地利用它来实现远程代码执行 (RCE)。在本地，我们通过以下步骤成功执行了 RCE：

1. 重置管理员用户的密码。

2. 通过SQL注入获取重置令牌和用户ID。

3. 使用带有泄露信息的密码重置端点。

4. 利用插件安装上传 CFM 文件。

然而，在Apple的环境中，我们只遇到了一个Unhandled Exception错误，没有任何查询相关的信息，这就变成了盲SQL注入。幸运的是，令牌和用户 ID 是 UUID，因此泄露它们相对简单。通过一些脚本，我们能够完成这项任务。

我们立即向 Apple 提交了报告，包括演示登录帐户的概念验证 (PoC)，同时理论上向他们提供了 RCE 详细信息。

结论

总之，我们对 Masa/Mura CMS 的探索是一次有益的旅程，揭示了关键漏洞。代码审查过程首先关注易受攻击的 SQL 注入代码模式，然后利用CFM/CFC 解析器在代码库中搜索特定模式，这与 Semgrep 的方法类似。一旦识别出潜在的接收器，我们就将其追溯到源头，在本例中是 Mura/Masa CMS 的 JSON API。

我们负责任地向 Apple 以及 Masa 和 Mura CMS 团队披露了这些发现。

苹果的回应：

Apple 在收到初步报告后 2 小时内做出了回应并实施了修复，迅速解决了所报告的问题。一如既往，与 Apple 的合作一直很好。

Mura CMS：

Masa 是 Mura CMS 的开源分支，他们非常透明，并发布了带有修复程序的新版本 Masa CMS。7.4.6、7.3.13 和 7.2.8 版本具有最新的安全补丁，包括另一个分配了 CVE ( CVE-2024-32640 ) 的关键预身份验证 SQL 注入。

Mura CMS：

尽管我们多次尝试就这些漏洞与 Mura 团队联系，但我们通过多个沟通渠道都没有收到任何回复。随着 90 天的标准期限过去，我们现在发布这篇博文，详细介绍了所报告的漏洞。