Oracle Access Manager Pre-Auth RCE（CVE-2021–35587 分析）

如您所知，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 ”：

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

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

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

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

从PBLFlowManager。handleBaseEvent()，请求流分为两部分：

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

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

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

然后，它将调用getServiceHandler()参数“ serviceId ”（可以完全操纵）：

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

在这种情况下，我们专注于SessionRequestHandler：

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

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

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

此时，我们的请求数据如下所示：

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

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

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

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

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

这是unmarshal()方法的内容：

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

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

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

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

事实：

在 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