[备份]浅谈加载字节码触发的Java安全问题

0x00 简介

近期在学习JSP免杀相关的知识,遇到了很多加载字节码的情况,所以写一篇文章总结下

加载字节码是Java安全中重要的部分,实现这个功能离不开ClassLoader

本文前半部分将从各个角度对各个ClassLoader的利用方式做解析,并深入分析其原理

后半部分讨论一些Java安全方面的技巧,算是一个炒冷饭,巩固和复习

 

笔者目前本科在读,才疏学浅,错误和不足之处还请大佬指出,十分感谢!

 

0x01 自定义类加载器

这里采用自定义类加载器的JSP Webshell来讨论

首先编写一个用于加载的恶意类

 

将上文的类使用javac编译为字节码。通常在代码中加载字节码的过程会进行Base64编码。于是具体的代码中使用Base64解码后,转为类对象,手动触发该类的构造方法即可实现Webshell的功能

 

实际上自定义ClassLoader这个过程并不简单

注意到ClassLoader是无法直接在运行时加载字节码的,至少需要重写findClass方法和loadClass方法

其中loadClass方法会先查找该类是否已被加载,调用findLoadedClass方法

如果没有找到,则会调用loadClass方法;如果还是没有找到,会调用findClass方法。如果没有重写该方法的情况,默认是抛出异常。如果重写了该方法,则会自定义加载

重写loadClass方法的代码如下,当我们加载的是指定名称的类时,就调用重写后的findClass方法

 

还有一个重点方法defineClass,它可以从byte[]还原出一个Class对象。在findClass中,如果调用defineClass加载指定的恶意字节码,就会达到运行时加载字节码的效果

因此尝试写出如下的findClass代码

 

其实上方的代码是正常执行的,但并不完善,应该调用defineClass的另一个重载

在Java的类加载中,有著名的双亲委派机制

首先会检查该类是否已经被加载,若没有被加载,则会委托父加载器进行装载,只有当父加载器无法加载时,才会调用自身的findClass()方法进行加载。这样避免了子加载器加载一些试图冒名顶替可信任类的不可靠类,也不会让子加载器去实现父加载器实现的加载工作

例如用户使用自定义加载器加载java.lang.Object类,实际上委派给BootstrapClassLoader加载器。如果用户使用自定义类加载器加载java.lang.Exp类,父类无法加载只能交给自定义类加载器。由于同在java.lang包下,所以Exp类可以访问其他类的protected属性,可能涉及到一些敏感信息

因此必须将这个类与可信任类的访问域隔离,JVM中为了避免这样的危险操作,只允许由同一个类加载器加载的同一包内的类之间互相访问,这样一个由同一个类加载器加载的并属于同一个包的多个类集合称为运行时包

类加载体系为不同类加载器加载的类提供不同的命名空间,同一命名空间内的类可以互相访问,不同命名空间的类不知道彼此的存在

除了命名空间的访问隔离和双亲委派的受信类保护,类加载器体系还用保护域来定义代码在运行时可以获得的权限

这里需要我们关注的点是CodeSource,它是解释如下

每个class文件均和一个代码来源相关联,这个代码来源(java.security.CodeSource)通过URL类成员location指向代码库和对该class文件进行签名的零个或多个证书对象的数组。class文件在进行代码认证的过程中可能经过多个证书签名,也可能没有进行签名

访问控制策略Policy对权限的授予是以CodeSource为基础进行的,每个CodeSource拥有若干个Permission,这些Permission对象会被具体地以其子类描述,并且和CodeSource相关联的Permission对象将被封装在java.security.PermissionCollection类的一个子类实例中,以描述该CodeSource所获取的权限

类加载器的实现可以通过将代码来源(CodeSource)即代码库和该class文件的所有签名者信息,传递给当前的Policy对象的getPermissions()方法,来查询该代码来源所拥有的权限集合PermissionCollection(在策略初始化时生成),并以此构造一个保护域传递给defineClass()以此指定类的保护域

以上复杂的理论表现在代码中如下(其中有一个细节在后续分析)

 

实际上在JDK的ClassLoader源码中,有这样的处理

 

当传入的ProtectionDomain为空时,会在预处理中定义为默认

 

回到上文提到的细节,发现这里默认的情况和上文缺少了一个PermissionCollection

 

为什么在JSP Webshell中指定了AllPermission

定义:The AllPermission is a permission that implies all other permissions

在JDK源码文档中有这样一句话:application or applet is completely trusted

这意味着改代码拥有全部的权限,也就是最高权限

拥有SocketPermissionFilePermission这种敏感操作的权限

也就完全发挥了JSP Webshell的功能,所以在JSP中指定ProtectionDomain是必要且有意义的

 

最终的自定义类加载器JSP Webshell如下

 

0x02 BCEL ClassLoader

在较高版本的JDK8中BCELClassLoader被删除所以需要在较低版本的JDK中测试

参考P神的文章:https://www.leavesongs.com/PENETRATION/where-is-bcel-classloader.html

 

该类加载的作用是给出一段特殊字符串,直接加载为类对象

简单查看loadClass方法的代码,可以看到加载了以"$$BCEL$$"开头的字符串

 

BCEL比较知名的是Fastjson的BasicDataSource利用

查看源码可以发现包含driveClassLoaderdriverClassNameget/set方法,具备了Fastjson的触发条件

给出一个较高版本Fastjson的POC,果然和推测差不多,主要是基于上面上个属性

 

两个name对象被缓存后,可以让BasicDataSourceBCEL ClassLoader绕过黑名单

最下面的$ref是高版本Fastjson的一个特性,可以链式调用,最终调用到BasicDataSource.connection

其实BasicDataSource类并没有connection属性,但这样的调用会触发get/set Connnection方法

 

跟入BasicDataSourcegetConnnection

 

注意到这里的触发点是Class.forName并不是loadClass等方法

其实Class.forName第二个参数initial为true时,类加载后将会直接执行static{}块中的代码

回到该Fastjson POC本身driveClassName的BCEL字节码对应的Java代码正好符合static条件

 

类似地,我们可以把BCEL ClassLoader的概念引入JSP Webshell中

 

0x03 URLClassLoader

另一个ClassLoader,区别在于可以加载任意路径下的类

还是选择0x01中的ByteCodeEvil

 

也可以利用URLClassLoader做RCE的回显

 

上文代码编译的字节码被URLClassLoader加载后,可以在报错信息中看到RCE的回显结果

同样可以用于JSP Webshell

 

0x04 defineClass0

主要参考了su18师傅给出的JSP Webshell,使用到的Proxy类是Java动态代理的底层实现类

基于Proxynative方法defineClass0做一些事情,也许可以绕过一些防御

 

例如下面的代码调用native方法defineClass0加载字节码

 

JSP Webshell

 

0x05 TemplatesImpl

该类是Java安全知名的类,例如著名的CC链、Fastjson、7U21

Fastjson利用

给出恶意类

 

Fastjson的POC

 

注意其中的Payload来自于恶意类,该类应该继承自com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet

该链需要开启Feature.SupportNonPublicField参数再反射设置属性,查看官方说明,如果某属性不存在set方法,但还想设置值时,需要开启该参数,这里的情况正好符合,而实际项目中很少出现这种情况,导致该链较鸡肋,没有实际的意义(其实TemplateImpl类中有set方法,比如setTransletBytecodes,但是名称和Bytecodes不一致)

com.alibaba.fastjson.parser.deserializer.JavaBeanDeserializer.parseField设置属性时会有判断

 

反序列化时,fastjson中会把”_”开头的属性替换为空。并在outputProperties设置值时调用getOutputProperties

 

调用到com.sun.org.apache.xalan.internal.xsltc.trax.newTransformer方法

 

跟入getTransletInstance,通过defineTransletClasses得到Class然后newInstance实例化

 

再跟入defineTransletClasses,对父类进行了验证,这样解释了为什么Payload恶意类要继承自该类。如果验证没有问题,将在上方的newInstance方法中实例化该类,造成RCE

 

注意到其中的ClassLoaderTransletClassLoader,简单的继承了ClassLoader

 

AccessController.doPrivileged方法主要做权限操作,目的是给ClassLoader设置指定的权限

跟入defineClass发现没有传入name,直接根据字节码获得类

 

为什么_bytescode要对字节码进行base64编码?反序列化的过程中会调用很多类,在经过该类com.alibaba.fastjson.serializer.ObjectArrayCodec.deserialze的时候,会对字段进行一次base64的解码

 

跟入lexer.bytesValue()方法,看到decodeBase64

 

基于TemplatesImpl的JSP Webshell

这里不给出代码了,大概分析下思路,参考三梦师傅的代码,有两种实现:

第一种是在JSP中构造一个TemplatesImpl类,按照Fastjson的POC给每个属性设置值,最后调用getOutputProperties方法。获取输入和回显可以基于文件,新建两个文件,写入请求参数在恶意类中读取执行并返回到输出文件

第二种是直接基于序列化数据,调用readObject反序列化触发

 

0x06 VersionHelper

给出基于VersionHelper的一个JSP Webshell,发现方法调用和ClassLoader类似

 

static块中实例化

 

跟入VersionHelper12类的loadClass方法,可以看到底层是一个URLClassLoader,这也解释了为什么要保存成一个文件

 

0x07 JDK-ASM

ASM框架可以直接操作字节码,而JDK其实是自带ASM的,并不需要引入第三方依赖

最终目标是加载字节码触发漏洞,并不是一定要使用JAVAC来编译生成,也可以直接写入

 

例如0x02的BCEL的例子,需要编译得到一长串String bcelCode = "$$BCEL$$......";

而笔者尝试直接用ASM构造出ByteCodeEvil字节码并加载,由于该库是JDK自带,所以理论上有一定的Bypass可能

给出ASM构造出的BCEL JSP Webshell

 

0x08 参考

https://xz.aliyun.com/t/7798

https://github.com/threedr3am/JSP-Webshells