0


安全研究所 | JNDI注入的一种新攻击面-CVE-2024-20931分析

在Oracle官方最新发布的January 2024补丁中,修复了一个基于Weblogic T3\IIOP协议的远程命令执行漏洞CVE-2024-20931,该漏洞由亿格云安全研究员Glassy在2023年10月提交给Oracle,从原理上属于CVE-2023-21839补丁的绕过,其中涉及到一个JNDI的新攻击面,在这里分享出来。

漏洞分析

01

CVE-2023-21839概述

当Weblogic通过T3\IIOP进行绑定的远程对象实现了OpaqueReference接口,那么在对该对象进行lookup时,会调用这个对象的getReferent函数进行查询。

图片

而碰巧有一个名为ForeignOpaqueReference的对象,它的getReferent函数在进行远程对象查询的时候,会再次发起JNDI查询,从而造成了JNDI注入。

图片

利用步骤大致分为三步

(关键步骤均用红框进行了标记)

Step1

建立一个恶意ForeignOpaqueReference对象,并将remoteJNDIName设置为远程恶意JNDI服务。

Step2

通过T3\IIOP协议在WLS上绑定该恶意对象。

Step3

通过lookup查询该恶意对象,触发

ForeignOpaqueReference.getReferent的调用,从而造成恶意JNDI注入。

图片

02

CVE-2023-21839补丁分析

Oracle官方于January 2023对该漏洞进行了修复,补丁内容分为两部分:

第一部分,限制了绑定ForeignOpaqueReference对象时对jndiEnvironment中providerURL的设置。

图片

第二部分对loopup的JNDI链接的协议也做了比较严格的限制。

图片

直观上去看,想继续通过ForeignOpaqueReference去做JNDI注入的路已经被堵死了。

03

CVE-2024-20931的挖掘

经过一定的分析,可以感觉到,现在有三条路是可能走的通的:

第一条路

寻找别的实现OpaqueReference接口的类的getReferent寻求突破(比较有意思的是ForeignOpaqueReference在两个package链接下都有,且代码有一些细微的差别)。

这条路有一定的可行性,但是要分析的类太多了,所以我没有做太深入的分享。

第二条路

尝试绕过补丁中的JNDIUtils.isValidJndiScheme函数。

图片

做了一定的努力,最终未能成功。

第三条路

如果在java.naming.provider.url为空的情况下,寻求一下代码执行的可能性。

图片

因为别的env还是可以控制的,所以或许能在指定java.naming.factory.initial进行初始化的时候,创造可能性,非常幸运的是,WLS提供了不少的InitialContextFactory,而恰恰就有一个AQjmsInitialContextFactory在初始化的时候,需要通过JNDI去获取远程的DataSource。

图片

通过AQjmsInitialContextFactory初始化发起的JNDI注入,就成功达成一种二次JNDI注入,实现了远程的RCE。

总结

这个漏洞相比于之前的JNDI注入,不是在lookup这个JNDI注入的关键函数上寻求突破,而是把关注点侧重于Context的初始化阶段,从而绕过了上一个漏洞的补丁,个人感觉还是比较有意思的一个漏洞,Oracle在后续的补丁中又对java.naming.factory.initial的设置做了验签处理,毫无疑问,还是有一些jndiEnvironment可以进行设置的,至于能不能去找到新的绕过,则需要更深一步的研究。

图片


本文转载自: https://blog.csdn.net/Eaglecloud/article/details/136174131
版权归原作者 亿格云安全Lab 所有, 如有侵权,请联系我们删除。

“安全研究所 | JNDI注入的一种新攻击面-CVE-2024-20931分析”的评论:

还没有评论