Java反序列化中jndi注入的高版本jdk绕过
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远程类加载的攻击方式，高版本依然有加载本地工厂类和反序列化本地利用链的攻击方式。
