成功RCE,执行CC6并且弹出计算器 服务端同理,不再演示。 动态类加载 攻击原理:java.rmi.server.codebase简单来说就是远程的classpath,当RMI的流程出现本地加载不到类的时候,会选择从codebase去加载,也就是远程include代码,显然存在很大漏洞隐患,触发加载远程类有下面的情况: Server端函数的返回类型为接口定义类型的...
public static void main(String... args) throws IOException, NamingException { // 为true则打开RMI和CORBA协议使用远程codebase的选项 System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true"); // 为true则打开LDAP协议使用远程codebase的选项 //System.setProperty("com.sun.jndi.ldap.objec...
漏洞主要分布于1.2.68及以下的版本中,在将json反序列化为对象时,存在代码执行漏洞 如果一些项目未更新到最新版本,则存在安全漏洞 1.1 log4j2 log4j 2.x 版本,是目前用得较多的Java日志组件,存在远程命令执行漏洞CVE-2021-44228 二者的RCE都是利用lookup方法,进而使用jndi ldap/rmi进行远程命令执行,本文不深究payload...
分析jndi注入+RMI漏洞利用流程: 首先服务端会根据恶意exp类与标识构造一个Reference对象引用,然后将这个恶意的Reference引用绑定到RMI注册中心,当客户端调用lookup方法获取Reference对象引用时,然后会加载Reference引用中指定的类,一般会先从本地寻找Exp类,如果找不到就会从Reference引用中指定的远程地址(http://127.0.0.1:...
利用codebase执行命令 首先说一下codebase是什么 java.rmi.server.codebase:codebase是一个地址,告诉Java虚拟机我们应该从哪个地方去搜索类,有点像我们日常用的CLASSPATH,但CLASSPATH是本地路径,而codebase通常是远程URL,比如http、ftp等。 当对象在发送序列化的数据的时候会带上codebase信息,当接受方在本地classpat...
客户端就需要从服务端提供的java.rmi.server.codebaseURL去加载类;对于服务端而言,如果客户端传递的方法参数是远程对象接口方法参数类型的子类,那么服务端需要从客户端提供的java.rmi.server.codebaseURL去加载对应的类,客户端与服务端两边的java.rmi.server.codebaseURL都是互相传递的,客户端何服务端要远程加载类都...
去年我salt大哥带我搞一个存在FastJson漏洞站的时候, 在ECS上启动rmi使用Reference 加载远程codebase代码库的方法, 但是一直没能成功执行命令。 最后才了解到需要修改掉/etc/hostname文件为公网ip地址才能够正常利用, 在修改掉/etc/hostname为公网ip后,成功弹回来了shell。
这样就是在 Client 执行 lookup 操作时让其直接加载远程恶意类进行 RCE,不需要任何其他的 gadget。 防御 受到自6u141、7u131、8u121起默配置com.sun.jndi.rmi.object.trustURLCodebase=false,直接远程加载会被限制,报错信息如下: 另外还对可反序列化的类做了白名单检测- JEP290,对 JEP290 的分析文章很多,常见...
使用远程方法调用,会涉及参数的传递和执行结果的返回。参数或者返回值可以是基本数据类型,当然也有可能是对象的引用。所以这些需要被传输的对象必须可以被序列化,这要求相应的类必须实现 java.io.Serializable 接口,并且客户端的serialVersionUID字段要与服务器端保持一致。
利用codebase执行任意代码 codebase是一个地址告诉虚拟机在哪里搜索类,如:codebase=http://example.com/,就会加载org.vulhub.example.Example类,在RMI流程中,客户端和服务端传递的是序列化后的对象,在这些对象反序列时就会去寻找类,寻找时会先在ClassPath下寻找,然后在codebase中寻找。如果可以控制codebase就能加载恶...