升级过log4j，却还没搞懂log4j漏洞的本质？

原创

华为云开发者联盟 2021-12-21 11:37:53 博主文章分类：程序员之家 ©著作权

文章标签 客户端 java 服务端 log4j 漏洞 文章分类 Java 后端开发

©著作权归作者所有：来自51CTO博客作者华为云开发者联盟的原创作品，请联系作者获取转载授权，否则将追究法律责任

摘要：log4j远程代码漏洞问题被大范围曝光后已经有一段时间了，今天完整讲清JNDI和RMI以及该漏洞的深层原因。

本文分享自华为云社区《升级过log4j,却还没搞懂log4j漏洞的本质？为你完整讲清jndi、rmi以及该漏洞的深层原因！》，作者：breakDraw。

log4j远程代码漏洞问题被大范围曝光后已经有一段时间了。

很多人只能看到一个“弹出一个计算器”的演示，于是内心想着“哦，就是执行任意代码，启动个计算器”，却对这个漏洞的原理不甚了解。

升级过log4j，却还没搞懂log4j漏洞的本质？_客户端

而对于java开发应用不是非常深的同学来讲，jndi、rmi更是很陌生的名词。

这里会以不断提问的方式，逐步推进这个问题的解答，一步步揭开这个漏洞的本质，并给出对这个漏洞的思考。

Q:log4j里的”${}“符号是什么？有什么用？

A:可以通过${}的方式，打印一些特殊的值到日志中。

例如${hostName}就可以打印主机名

${java:vm}打印jvm信息

${thread:threadName}就可以打印线程名

当你把这个值作为日志的参数，就会打印出来这些值而非原参数名字。

可以理解为log4j的功能更强大了，不需要自己写java代码来打印这些信息，直接用一个字符串就能搞定这些打印。

上面这些都是要实现对应的Lookup类才能做的，即要么log4j内置，要么我们自己新增。

Q:上面这个打印本机信息的是漏洞的原因吗？看起来好象可以在机器里执行奇怪的命令？或者查看文件路径？

A:不是的。上面这些lookup，都是事先定义好的一些loopup字符，并不能做任意的事情！而且就算你发了这些${java.vm}啥的，也只能在服务端打印和收集，你作为攻击者，是收集不到这些信息的

真正的原因，是因为log4j支持的${jndi:xxxx}，即支持jndi进行lookup来寻找对象并打印。

Q:什么是JNDI？

A:JavaNamingandDirectoryInterface（JAVA命名和目录接口）

简单说就是可以通过JNDI，在java环境中用一个名字，去lookup寻找一个东西使用。

例如可以直接在自己的Java环境中配置一个数据库连接，名字叫“java:MySqlDS”然后别的java进程通过jndi去查找”java:MysqlDs“,接着就会得到一个数据库连接。这样如果1个机器有多个进程，都要用同一个连接，完全可以修改整个java环境的jndi数据库对象，然后其他进程就能同时生效了。

Connection conn=null; 
// Context就是jdni的类
Context ctx = new InitialContext(); 
// jndi关键方法，通过loopup找一个对象
Object datasourceRef = ctx.lookup("java:MySqlDS"); 
//引用数据源 
DataSource ds = (Datasource) datasourceRef; 
conn = ds.getConnection(); 
c.close();

除了数据库连接，他还支持loopup找dns，可以弄一个dnsContext然后寻找”sun.com“对应的dns对象使用JNDI进行高级DNS查询

这样log4j里就可以通过${jndi:dns:huaweicloud.com}来获取当前机器中huaweicloud.com对应的域名对象进行打印，来确认网络请求失败时，是否是dns获取有问题。

这也就是log4j为啥要引入jndi的原因,可以更方便地获取一些可打印的对象进行日志统计。

然而，jndi还支持通过RMI/LDAP+url字符串，来寻找并获取一个远程对象。这个寻找远程对象的操作，就是此次漏洞的核心问题所在。

这里只讲RMI。LDAP类似，就不再论述。

Q:RMI是什么？

A:RMI，RemoteMethodInvocation。

具体含义：

远程服务器实现具体的Java方法并提供接口
客户端本地仅需根据接口类的定义，提供相应的参数即可调用远程方法

在RMI中，实际上就是返回了一个stub（桩）调用对象给客户端，然后客户都用这个stub对象去做远程调用。

这样客户端就不用关心背后网络怎么写的

甚至不用知道对方服务是什么端口或者ip

因此也不需要写sokect的一堆方法搞半天了，也避免了总是修改访问的url啥的。

具体过程如下：

升级过log4j，却还没搞懂log4j漏洞的本质？_java_02

Server端监听一个端口，这个端口是JVM随机选择的；
Client端并不知道Server远程对象的通信地址和端口，但是Stub中包含了这些信息，并封装了底层网络操作；
Client端可以调用Stub上的方法；
Stub连接到Server端监听的通信端口并提交参数；
远程Server端上执行具体的方法，并返回结果给Stub；
Stub返回执行结果给Client端，从Client看来就好像是Stub在本地执行了这个方法一样；

Q:RMI客户端不需要关心服务端的监听端口？那客户端从哪里拿到stub对象呢？总不可能凭空生成吧

A:服务端那边可以启动一个RMI注册中心服务RMIRegistry，端口设置为统一的1099，ip也是固定的。

然后当客户端希望拿到某个服务例如订单服务order的stub对象时，就用”order“这个名字到RMI注册中心上去请求这个stub这样的话，客户端只需要知道RMI注册中心即可，不需要知道其他服务的ip、端口，非常节省管理成本。

服务端代码长这样：

// 建立一个订单服务通信桩
OrderServerStub stub = new OrderServerStub();
// 启动一个RMI注册中心, 端口为1099
LocateRegistry.createRegistry(1099);
// 把OrderServer这个桩，注册到rmi://0.0.0.0:1099/order这个url上
Naming.bind("rmi://0.0.0.0:1099/order", stub);

客户端的代码长这样，可以看到一个loopup就把这个桩找过来了。然后就能直接调用stub里的queryOrder方法查询订单了！

Registry registry = LocateRegistry.getRegistry("kingx_kali_host",1099);
OrderServerStub stub = (OrderServerStub) registry.lookup("hello");
stub.queryOrder("aaa");

升级过log4j，却还没搞懂log4j漏洞的本质？_java_03

Q:那JNDI和RMI又是什么关系？怎么就联系到一起了

A:上面的代码里，可以看到RMI需要自己写一段Java代码执行。如果以后你不用RMI来存这个通信对象了，而是用LDAP之类的，咋办？难道代码都要重新写然后部署一份吗？

而如果能用JNDI的方式，通过一个小小的字符串，就能拿到，那就简单了。那么当我需要切换通信对象的获取方式时，切换JDNI里的设置即可。

而RMI正好实现了JNDI的spi接口，以至于能支持用JNDI+字符串去获取对象

升级过log4j，却还没搞懂log4j漏洞的本质？_漏洞_04

这里贴一下SPI的概念：

SPI，全称为ServiceProviderInterface，是一种服务发现机制。它通过在ClassPath路径下的META-INF/services文件夹查找文件，自动加载文件里所定义的类。这一机制为很多框架扩展提供了可能，比如在Dubbo、JDBC中都使用到了SPI机制

说人话，spi就是框架方提供一个interface接口，然后只要有人在服务的class发现路径下写一个实现类，就能在代码里直接用上。

而log4j里，正好就支持用${jndi:rmi:x.x.x.x:1099/path}的方式进行RMI对象的获取。

log4j开发者可能本意只是方便用jndi获取各种java容器内置对象，没想到忽略了rmi的获取方式。

这就导致了我们的服务可能会访问黑客部署的RMI服务，获取到一个不可信的远程调用对象。

Q:但是刚才提到，我们只会通过RMI去拿到一个stub，stub里的内容仅仅是通过特定的ip+port去做发送，代码是固定的。再怎么恶意的命令，也只会在RMI注册中心即黑客的服务器上执行，怎么就在我这边触发了攻击？

而且这个stub对象的class文件在我们服务器本地并没有，难道不会报classNotFind异常吗？

A:某个讲RMI注入的文章里这样说道：

RMI服务端除了直接绑定远程对象之外，还可以通过References引用类来绑定一个外部的远程对象（当前名称目录系统之外的对象）。绑定了Reference之后，服务端会先通过Referenceable.getReference()获取绑定对象的引用，并且在目录中保存。当客户端在lookup()查找这个远程对象时，客户端会获取相应的objectfactory，最终通过factory类将reference转换为具体的对象实例。