CVE-2022-21350分析

    渗透测试 lz520520 9个月前 (03-19) 284次浏览

    漏洞介绍

    反序列化利用链,JNDI注入

    漏洞评级

    影响范围

    10.3.6.0.0

    12.1.3.0.0

    12.2.1.3.0

    12.2.1.4.0

    安全版本

    漏洞分析

    12.2.1.4.0

    测试版本12.2.1.4.0

    之前有师傅的文章已经分析过了,给出调用堆栈

    从这里调用链能看出,他基本都是JDK或weblogic一个包的,没有像2555/2883那样还需要依赖coherence,能大大提高不同版本的利用兼容性。

    目前测试下来12.1.3/12.2.1.3/12.2.1.4用一个包就能打

    这里记录下自己的调试记录吧,方便后续查阅

    入口点还是之前的javax.management.BadAttributeValueExpException.readObject

    从val变量里取出对象,这里变量是FileSessionData对象,然后调用他的toString()

    CVE-2022-21350分析

    FileSessionData是继承SessionData,这里的toString没被重写,所以调用的是父类的,进而调用this.isDebuggingSession()

    CVE-2022-21350分析

    registry.isProductionMode()没法在本地反序列化测试,因为里面涉及到一些变量需要weblogic运行时初始化,所以这里没法本地调试。

    接着会调用this.getAttribute获取wl_debug_session

    CVE-2022-21350分析

    这里getSecurityModuleAttribute返回是null,因为他是name="weblogic.formauth.targeturl"才有值。所以调用this.getAttributeInternal

    CVE-2022-21350分析

    this.attributes是一个Map,实现类是ConcurrentHashMap,获取wl_debug_session的value,这里是AttributeWrapper对象

    接着调用AttributeWrapperUtils.unwrapObject解封装。

    CVE-2022-21350分析

    AttributeWrapper对象封装的是BusinessHandlerImpl类,解封装后,还需要判断wrapper.isEJBObjectWrapped()是否为true,才能继续调用unwrapEJBObjects

    CVE-2022-21350分析

    所以需要手动setEJBObjectWrapped(true)

    CVE-2022-21350分析

    unwrapEJBObjects里有四个分支,如果是BusinessHandle的实现类,才能调用getBusinessObject()

    CVE-2022-21350分析

    PS: 这个部分,其实BusinessHandle、HomeHandle和Handle三个都能触发,任选其一。

    this.homeHandleHomeHandleImpl类,然后调用getEJBHome()

    CVE-2022-21350分析

    最终到了sink点,ctx.lookup,这里有两个变量要设置,this.serverURL和this.jndiName,就是JNDI请求那一套。

    CVE-2022-21350分析

    10.3.6

    这个版本有些不同

    SessionData.getAttributeInternal里,原本是先调用AttributeWrapperUtils.unwrapObject,然后才是判断unwrappedObject属于哪个接口,进行转换。

    10.3.6跳过中间步骤,直接判断。

    但这里多了一个var3 instanceof EJBAttributeWrapper 判断,原来payload里是直接用AttributeWrapper

    CVE-2022-21350分析

    EJBAttributeWrapper也是AttributeWrapper继承类,但注意这个类是私有类,只能通过反射来实例化。

    CVE-2022-21350分析

    所以该部分注释原来的,调整如下

    CVE-2022-21350分析

    但注意因为SeesionData的不同,会导致suid不同,所以在打不同版本需要调用不同版本的jar包,这玩意大得很,要优化就是筛选出有用的Class来类加载,回头优化再说吧。

    PS: 新版本没有EJBAttributeWrapper类了。

    JNDI注入部分问题

    漏洞利用的最后阶段,这里会发起JNDI请求,一般来说我们习惯用LDAP或RMI,但这里做了限制。

    java.naming.provider.url这个值其实不太影响。

    我们利用的通常是ctx.lookup指定向我们的ldap/rmi发起请求,但这里this.jndiName是Name接口,而不是一个String。

    CVE-2022-21350分析

    该方法存在重载

    CVE-2022-21350分析

    那么就有两种思路

    1. url设置成我们server,那么后面jndiName就不影响了。
    2. url任意指定,只要连接server成功,jndiName构造转换成和传入String一样的效果,也能实现。

    第一种方法

    因为weblogic.jndi.WLInitialContextFactory,url的scheme在weblogic我们是用T3/IIOP。

    这里注册了其他协议,但实际也只能用t3/iiop,所以要有恶意的T3/IIOP server才能利用成功,也就是攻击T3/IIOP client,这里目前来说没找到有用的资料和实现。

    CVE-2022-21350分析

    备注:

    所以第一种方法放弃。

    第二种方法

    既然url只能设置成iiop/t3,那就直接指向本地,如iiop://127.0.0.1:7001

    而this.jndiName就需要构造了

    先看了下传入String的情况,解析name的协议,根据scheme来获取对应协议context

    CVE-2022-21350分析

    如ldap,获取到的就是com.sun.jndi.url.ldap.ldapURLContext,然后调用ldapURLContext.lookup

    CVE-2022-21350分析

    再看下getURLOrDefaultInitCtx(Name name),这里多了一步从name.get(0)里获取url来解析,后续都一样

    CVE-2022-21350分析

    然后看看ldapURLContext.lookup,重载的方法基本没区别,也是get(0)

    这里注意url里不要有?,否则会抛异常

    CVE-2022-21350分析

    父类的lookup,传入Name接口的,只要解析长度为1,进而会调用String的lookup,后面流程就一样了。

    CVE-2022-21350分析

    所以现在只需要有一个Name的实现类,解析我们构造的字符串后,解析长度为1,get(0) => "ldap://x.x.x.x:1389/xxx"即可

    如下实现类均在JDK里

    CVE-2022-21350分析

    经过测试

    DnsName: 以.分割字符串,传入www.baidu.com会变为["www","baidu", "com"],不可用

    LdapName:会以,分割,并判断是否有=,能正常解析的格式是dc=example,dc=com,不可用

    CompositeName: 会以/分割,所以传入ldap://x.x.x.x,会被分割成["ldap","","x.x.x.x"],不可用

    CompoundName: 这个和CompositeName相似,但分割符可以自定义,那么就可以找个特殊符号,就不会被分割了。

    网上的一个例子,这样就会以@分割, 其他属性可参考javax.naming.NameImpl.recordNamingConvention()

    当然,如果不设置属性,就默认为null,不做解析

    CVE-2022-21350分析

    CVE-2022-21350分析

    CVE-2022-21350分析

    所以对应payload修改如下,serverURL就指向server本地,让连接正常通过即可,jndiName就通过CompoundName构造。

    CVE-2022-21350分析

    其他注意事项


    Security , 版权所有丨如未注明 , 均为原创丨
    转载请注明原文链接:CVE-2022-21350分析
    喜欢 (1)