黑客攻击苹果 - 从SQL注入到远程代码执行 — ProjectDiscovery博客

# 破解苹果——从SQL注入到远程代码执行 — ProjectDiscovery博客 来源：https://projectdiscovery.io/blog/hacking-apple-with-sql-injection ### 引言 在上一篇博客中（https://projectdiscovery.io/blog/hello-lucee-let-us-hack-apple-again/），我们深入探讨了Lucee的内部工作原理，并检查了Masa/Mura CMS的源代码。潜在的攻击面之广阔令我们震惊。很明显，花时间理解代码是值得的。经过一周的探索，我们偶然发现了多个可利用的入口点，包括一个关键的SQL注入漏洞，我们成功在苹果的Book Travel门户中利用了它。在这篇博客中，我们希望分享我们的见解和经验，详细说明我们如何发现漏洞点（sink），将其追溯到源头，并利用SQL注入实现远程代码执行（RCE）。 ### 发现漏洞点 通过使用Masa/Mura CMS，我们了解了我们的攻击面——主要是苹果环境中可访问的攻击面。我们的主要关注点是JSON API，因为它暴露了一些在苹果环境中可用的方法。任何我们发现的潜在漏洞点都应该在JSON API中有其源头。我们讨论了如何优化方法以简化源代码审查过程。我们探索了是否有可用的静态分析器或CFM解析器能够遍历代码同时忽略清理函数。例如，下面是一个通过基于标签的CFM编写的安全参数化SQL查询： ```cfml <cfquery> select * from table where column=<cfqueryparam value="#arguments.user_input#"> </cfquery> ``` 而下面是一个不安全的SQL查询： ```cfml <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注入攻击（前提是没有其他验证）。 - 打印该查询。 ```cfml 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: #fname#"); WriteOutput("<pre>" & s.getStrippedInnerContent(true, true) & "</pre>"); WriteOutput("<br>"); } } } } } ``` 我们开始审查结果，同时牢记一些事项，例如忽略像`siteid`这样的输入，因为JSON API会提前对其进行验证。其中一个包含两个其他输入的查询如下： ### 将漏洞点追溯到源头 查看包含此查询的函数后得出结论，只有一个可利用的参数，即`ContentHistID`。参数`columnid`是数字类型，而`siteid`默认经过验证。 ```cfml <cfquery datasource="#variables.configBean.getDatasource()#" username="#variables.configBean.getDbUsername()#" password="#variables.configBean.getDbPassword()#"> 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> ``` 函数`getObjects`在`core/mura/content/contentRendererUtility.cfc`组件的`dspObjects`函数中被调用。 调用堆栈为：JSON API -> processAsyncObject -> object case: displayregion -> dspobjects() -> getobjects()。 ### 触发与利用SQL注入 默认情况下，Lucee会对通过输入传入的单引号进行转义，在其前面添加反斜杠。这可以通过使用一个反斜杠来转义其中一个单引号来解决。这应该会触发SQL注入：`/_api/json/v1/default/?method=processAsyncObject&object=displayregion&contenthistid=x%5c'` 然而，这并没有触发。重新审查源代码后，我们在`dspObjects`函数中识别出一个关键条件。在调用`getObjects`之前，必须满足一个`if`条件：Mura servlet事件处理程序中的`isOnDisplay`属性必须设置为true。最初，我们假设事件处理程序上的任何属性都可以通过简单地将属性名称作为参数传递并赋值来设置。这个假设基于我们在代码库中的调试会话。我们尝试以这种方式设置`isOnDisplay`属性但失败了。似乎代码中的某处覆盖了这个属性。经过一些grep搜索后，我们在JSON API的`processAsyncObjects`中偶然发现了`standardSetIsOnDisplayHandler`函数调用。 似乎只需传递带有任何值的`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文件。 然而，在苹果环境中，我们只遇到未处理异常错误，没有任何查询相关信息，这使得它变成了盲SQL注入。幸运的是，令牌和用户ID是UUID，因此泄露它们相对简单。通过一些脚本编写，我们完成了这一任务。 我们迅速向苹果提交了报告，包括概念验证（PoC），展示了登录账户，同时理论上提供了RCE的详细信息。 ### 通过Nuclei进行检测 此SQL注入漏洞可通过以下Nuclei模板识别： ```yaml id: CVE-2024-32640 info: name: Mura/Masa CMS - SQL注入 author: iamnoooob,rootxharsh,pdresearch severity: critical description: | Mura/Masa CMS存在SQL注入漏洞。 reference: - https://blog.projectdiscovery.io/mura-masa-cms-pre-auth-sql-injection/ - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-32640 impact: | 成功利用可能导致未授权访问敏感数据。 remediation: | 应用供应商提供的补丁或更新到安全版本。 metadata: verified: true max-request: 3 vendor: masacms product: masacms shodan-query: 'Generator: Masa CMS' tags: cve,cve2022,sqli,cms,masa,masacms http: - raw: - | POST /index.cfm/_api/json/v1/default/?method=processAsyncObject HTTP/1.1 Host: {{Hostname}} Content-Type: application/x-www-form-urlencoded object=displayregion&contenthistid=x\'&previewid=1 matchers: - type: dsl dsl: - 'status_code == 500' - 'contains(header, "application/json")' - 'contains_all(body, "Unhandled Exception")' - 'contains_all(header,"cfid","cftoken")' condition: and ``` ### 结论 总之，我们对Masa/Mura CMS的探索是一次收获颇丰的旅程，揭示了关键漏洞。代码审查过程始于关注易受SQL注入攻击的代码模式，然后利用CFM/CFC解析器（https://github.com/foundeo/cfmlparser）在代码库中搜索特定模式，类似于Semgrep的方法。一旦识别出潜在的漏洞点，我们就将其追溯到源头，在本例中即Mura/Masa CMS的JSON API。我们负责任地将这些发现披露给了苹果以及相应的Masa和Mura CMS团队。 **苹果的回应：** 苹果在初始报告后2小时内响应并实施了修复，迅速解决了报告的问题。与往常一样，与苹果的合作非常愉快。 **Masa CMS：** Masa是Mura CMS的一个开源分支，他们非常透明，发布了带有修复的新版本Masa CMS。版本7.4.6、7.3.13和7.2.8包含了最新的安全补丁，包括另一个关键的预认证SQL注入，已分配CVE（CVE-2024-32640（https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-32640））。 **Mura CMS：** 尽管多次尝试就这些漏洞联系Mura团队，但在多个通信渠道上均未收到回复。在90天的标准期限过后，我们现在发布这篇博客，详细说明报告的漏洞。 通过利用Nuclei并积极参与开源社区，或成为ProjectDiscovery云平台的一部分，公司可以加强其安全措施，主动应对新兴威胁，并构建更安全的数字环境。安全是一项共同的事业，通过合作，我们可以不断适应并面对网络威胁不断演变的挑战。