jndi注入原理:

JNDI(Java Name and Dictionary Interface Java名称与目录接口),一套JavaEE的标准,类似Windows注册表。

结构如下:

key:路径+名称
value:存的数据(在jndi中存的是对象Object)

jndi是java用于访问目录和命名服务的 API。使用jndi进行查询本来是一个正常的功能,但由于实现时没有考虑安全问题,如果查询了恶意对象就会导致被攻击。但是不是所有攻击都能够导致RCE(比如dnslog2333)
JNDI查询分为以下两个步骤:

1、客户端请求一个命名服务并获取对象

2、客户端解析这个对象

这两个步骤都有可能导致漏洞的发生,jndi支持LDAP、RMI、DNS、CORBA四种可能导致危险的协议,每种都对应了不同的实现方式,支持绑定的对象也包含了引用对象、反序列化对象、属性对象等等,所以攻击手段和漏洞都很多。

最常用也是最危险的攻击有jndi+rmi和jndi+ldap,corba也可以用来命令执行(但是修复得比较早,而且用corba的基本都可以用rmi)

JNDI+RMI

关键代码位于RegistryContext#lookup

public Object lookup(Name name) throws NamingException {
  if (name.isEmpty()) {
    return (new RegistryContext(this));
  }
  Remote obj;
  try {
    obj = registry.lookup(name.get(0));
    //这里可以看到远程对象是通过rmi原生的lookup获取到的
  } catch (NotBoundException e) {
    throw (new NameNotFoundException(name.get(0)));
  } catch (RemoteException e) {
    throw (NamingException)wrapRemoteException(e).fillInStackTrace();
  }
  return (decodeObject(obj, name.getPrefix(1)));

可以看到远程对象是通过rmi原生的lookup获取到的,而rmi是通过反序列化获取到的远程对象,这时如果客户端系统里有gadget组件,这一步的反序列化就能导致代码执行了。
第二步,在decodeObject里面对获取到的obj进行了解析,逻辑位于RegistryContext#decodeObject

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);

注释注明了,如果com.sun.jndi.rmi.object.trustURLCodebase为true就可以通过codebase加载
任意远程类,导致代码执行。这个校验是在jdk8u121开启的,并且是加在RegistryContext里面的,也就是只对了jndi的rmi实现作了限制,所以安全人员后续才会发掘出ldap的利用。

Object obj = (r instanceof RemoteReference) ? ((RemoteReference)r).getReference(): (Object)r;

这段代码判断传入的对象,是否满足RemoteReference接口,如果有则getReference()获取reference对象,然后进入getObjectInstance函数。

具体利用流程如下:

1、目标代码中调用了InitialContext.lookup(URI),URI为用户可控的;

2、攻击者设置uri为恶意rmi服务地址;

3、攻击者设置rmi server向目标返回一个reference引用对象,reference对象中指定了一个精心构造的Factory类;

4、目标进行lookup操作远程对象时,获取到动态加载并实例化了这个Factory类,接着调用factory.getObjectInstance()加载外部远程对象实例;

5、攻击者可以在Factory类文件的构造方法、静态代码块、getObjectInstance()方法等处写入恶意代码,达到RCE的效果;

getObjectInstance 主函数当中使用此类的getInstance()函数,即可得到系统当前已经实例化的该类对象,若当前系统还没有实例化过这个类的对象,则调用此类的构造函数。
可以引出后续的两种命令执行利用方式:

if (ref != null) {
            String f = ref.getFactoryClassName();
            if (f != null) {
                // if reference identifies a factory, use exclusively
 
 
 
 
                factory = getObjectFactoryFromReference(ref, f); //触发点1
                if (factory != null) {
                    return factory.getObjectInstance(ref, name, nameCtx,
                                                     environment); //触发点2
                }
                // 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;

第一种是getObjectFactoryFromReference(),在这个函数中会通过获取到对应的恶意class对象,在开启trustURLCodebase时可以通过URLClassloader加载远程类并进行实例化,通过class.newInstance()触发恶意构造函数:

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

第二种是通过实例化的类,调用起getObjectInstance函数,来执行恶意代码:

只要攻击者实现ObjectFactory接口,重写getObjectInstance,即可执行恶意代码。

public class Exec implements ObjectFactory {
    public Exec(){}
    public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment) throws Exception {
        System.out.println("factory.getObjectInstance hook!");
        return null;
    }
}

综上所述,RMI的RCE利用从某种意义上说并不是利用反序列化导致的代码执行,只是利用反序列化来加载恶意远程对象。

JNDI+LDAP

核心逻辑在ldapCtx#c_lookup

protected Object c_lookup(Name name, Continuation cont)
throws NamingException {
cont.setError(this, name);
Object obj = null;
Attributes attrs;
try {
......
if (attrs.get(Obj.JAVA_ATTRIBUTES[Obj.CLASSNAME]) != null) {
// 序列化对象或序列化引用
obj = Obj.decodeObject(attrs);
}
if (obj == null) {
obj = new LdapCtx(this, fullyQualifiedName(name));
}
} catch (LdapReferralException e) {
......
try {
return DirectoryManager.getObjectInstance(obj, name,
this, envprops, attrs);
......
}

只看关键代码,这里主要分为两个步骤:
首先通过Obj.deocodeObject从ldap获取字符串,解码出一个ldap对象,然后通过DirectoryManager.getObjectInstance解析,这里和RMI是一样的逻辑,只是没有rmi关于trusrURLCodebase的校验。

所以jndi+ldap获取对象的方式和rmi差不多,都是通过反序列化获取的。然后解析对象调用的是DirectoryManager.getObjectInstance,其实和NamingManager.getObjectInstance基本是一样的。decodeRefernce,原生反序列化,但是如果com.sun.jndi.ldap.object.trustURLCodebase开启,会调一个重写的resolveClass进行远程类加载。

1、解析对象时调用getObjectFactoryFromReference,在开启com.sun.jndi.ldap.object.trustURLCodebase时进行远程类加载

2、和rmi一样用本地工厂类,但ldap服务端不能像rmi一样直接绑远程对象,需要绑序列化后的数据。

JNDI注入与jdk版本

jdk针对jndi注入的利用有两次修复,8u121对RMI和corba的jndi注入进行限制,com.sun.jndi.ldap.object.trustURLCodebase 限制了这两种服务加载远程工厂类。

8u191禁用了ldap的远程类加载。

至此,高版本可用的jndi注入还有:加载本地工厂类,打本地反序列化链,

前者是tomcat8/9才引入的,后者需要本地反序列化链。

总结:

1、jndi注入的原理

一般说的jndi注入原理是远程类加载。其他攻击方法还有本地工厂类代码执行、反序列化。

2、jndi注入与反序列化

jndi注入依赖反序列化来传递对象,但常说的jndi注入代码执行并不是由反序列化链导致的。同样jndi注入也可以转化成通常说的反序列化攻击。

3、jndi注入与jdk升级

jdk升级只能修复jndi远程类加载的攻击方式,高版本依然有加载本地工厂类和反序列化本地利用链的攻击方式。