首页 >> 网络安全 >>漏洞利用 >> Oracle Access Manager Pre-Auth RCE(CVE-2021–35587 分析)
详细内容

Oracle Access Manager Pre-Auth RCE(CVE-2021–35587 分析)

时间:2022-03-15     【转载】   阅读

如您所知,Oracle Access Manager (OAM) 是许多大公司使用的流行 SSO 产品,例如 Oracle、VMware、华为、高通……

这个漏洞是我偶然发现的


而我们正在为另一个 mega-0day 分析和构建 PoC(现在还没有修复;))。

访问入口点并利用漏洞非常容易,因此建议立即应用补丁!它可以让攻击者访问 OAM 服务器,创建任何具有任何权限的用户,或者只是在受害者的服务器中执行代码。


#细节

我们使用这些指南来设置实验室:

https://k21academy.com/oracle-accesss-manager/oracle-access-manager-12c-12-2-1-3-0-download-installation-part/

https://k21academy.com/oracle-accesss-manager/oracle-access-manager-12c-rcu-configure-domain-12-2-1-3-0-part2/


设置部分很麻烦,我们花了一个月的时间来设置一个功能齐全的实验室(╯‵□′)╯︵┻━┻。经过两周的尝试,我们几乎放弃了!

到目前为止,我们已经完全忘记了这一切,所以如果您遇到任何设置问题,我们将无能为力ˉ\_(ツ)_/ˉ。

在这篇文章中,我将详细介绍 OAM 12c 版本中的漏洞。使用 OAM 11g 版本,将需要更复杂的“东西”来获得 RCE。(事实:大多数公共目标仍在使用 OAM 11g 而不是 12c;))。

让我们首先看一下由“ oracle.security.am.pbl.transport.http.AMServlet ”类处理的URL 端点“ /oam/server/opensso/sessionservice ”:

1.png

“ AMServlet .doPost() ”并没有做太多的工作,它只是调用了handleRequest()然后是 PBLFlowManager。processRequest()处理传入的请求:2.png

在PBLFlowManager .processRequest ()中,我们传入的 URI“ /oam/server/opensso/sessionservice ”被映射到一个名为“ OPENSSO_CHECK_VALID_SESSION”的事件名称:

3.png

接下来,从给定的eventName创建一个EventHint,然后使用该eventHint从映射中获取requestHandler:

4.png

在这种情况下,requestHandler 是AgentRequestHandler 的一个实例,还有一个更大的这些处理程序端点映射的列表,但我不记得它在哪里:

5.png

从PBLFlowManager。handleBaseEvent(),请求流分为两部分:

  • 第一部分:调用requestHandler。process()解析、验证传入的 XML 数据

  • 第二部分:调用PBLFlowManager。delegateToMasterController()处理当前请求的逻辑特征

在第一部分,AgentRequestHandler。process()将调用handleXMLRequest()将传入的数据解析为 XML 数据:

6.png

在成功将数据解析为 XML 请求后,该方法继续跳转到AgentRequestHandler。处理请求()

7.png

要通过 isValid() 方法,传入的请求必须遵循以下形式:

image.png

8.png

然后,它将调用getServiceHandler()参数“ serviceId ”(可以完全操纵):

9.png

基于 4 个 svcid 的 serviceHandler 有 4 种类型:

  • 带有svcid的命名服务:com.iplanet.am.naming

  • 带有svcid的 AuthXMLHandler:auth

  • 带有svcid的 SessionRequestHandler:会话

  • 带有svcid的 PolicyXMLHandler:策略

在这种情况下,我们专注于SessionRequestHandler:

10.png

成功确定 sessionHandler 后,AgentRequestHandler。handleRequest()将继续调用我们给定的 sessionHandler.process(),现在是SessionRequestHandler。进程()。

在SessionRequestHandler中。process(),它将从名为“ Request ”的 xml 标签中获取数据,并将该数据再次解析为 XML 数据:

11.png

请注意SessionRequestParser。parseXML(),如果传入的xml请求包含一个名为“ requester ”的属性,那么它的数据将被base64解码并设置为一个名为“ Requester ”的属性:

12.png

此时,我们的请求数据如下所示:

13.png

看这个文档听起来很直接,但是你应该自己尝试一下,完成这些数据并不容易!

成功解析传入的 XML 数据后,我们继续第二部分PBLFlowManager。handleBaseEvent()将继续调用delegateToMasterController() -> MasterController。进程() ->主控制器。processRequest() -> OpenssoEngineController .processEvent (),这里是调用框架:

14.png

* OpenssoEngineController由上面提到的给定 EventHint 确定。

在OpenssoEngineController中。processEvent(),有一个 switch case 语句来处理每种事件类型,在我们的例子中,它是OPENSSO_CHECK_VALID_SESSION:

15.png

按照这个分支,我们将看到对OpenssoEngineController的调用。具有给定“请求者”属性的unmarshal()方法:

16.png

这是unmarshal()方法的内容:

17.png

我们可以很快看出,如果“ requester ”属性的形式是“ object :<base64 data> ”,那么这个数据会直接反序列化,不做任何过滤。

这就是这个漏洞的接收器,长期来说,请求如下所示:

18.png

幸运的是,OAM 建立在 weblogic 之上,OAM 的类加载器也包含 weblogic 的库。所以是的,我们可以使用一些 weblogic gadgetchain 来获取 RCE。

在尝试了许多旧的gadgetchain之后,我们发现CVE-2020-14644 gadgetchain仍然没有被全局序列化过滤器阻止。而我们最终的 PoC 也使用了这个gadgetchain来获得RCE!

19.png

事实:

在 OAM 12c 上成功演示 PoC 后,我们尝试为这个 OAM 实例应用最新的补丁,猜猜看,我们的 PoC 不再可利用(╯°□°)╯︵ ┻━┻。

起初,我们认为 Oracle 已经知道这个漏洞并设法修补它。在查看了补丁并检查了旧版本之后,我们知道他们没有。


原因是:在最近的 OAM 12c 补丁中,他们放弃了对 OpenSSO 的支持,因此入口点“ /oam/server/opensso/sessionservice”也被意外删除了。但不适用于 OAM 11g ;),我们发现易受攻击的入口点仍然存在于完全更新的 OAM 11g 中。


在 OAM 11g 中,CVE-2020–14644 的小工具链不存在,因此需要更多的工作来构建一个有效的小工具链。在 OAM 11g 上获得 RCE 的旅程是另一个有趣的故事,所以我们决定稍后再谈!


想知道另一个事实吗?

Weblogic 10.3.6 和 OAM 11g 已经停产,2022 年 1 月 1 日之后没有针对它们的补丁。

这意味着:此 Pre-Auth RCE 没有补丁ˉ\_(ツ)_/ˉ


翻译自:https://testbnull.medium.com/oracle-access-manager-pre-auth-rce-cve-2021-35587-analysis-1302a4542316

技术支持: 建站ABC | 管理登录