本月初的时候，一条 Log4j 官网发布的漏洞说明引起了各互联网公司的轩然大波，各大公司都在连夜升级修复，毕竟是自己入行以来为数不多亲生经历的一次严重事故，所以简单记录一下：
漏洞说明
2021年12月6日，Apache Log4j2 Java 日志模块存在远程命令执行漏洞可直接控制目标服务器问题，攻击者攻击难度极低。
由于 Apache Log4j2 某些功能存在递归解析功能，攻击者可直接构造恶意请求，触发远程代码执行漏洞。该漏洞可通过 critical、error、warining、notice、info、debug等日志级别触发，只需部分日志内容可控，此漏洞波及大量开源组件，包括 ELK、 Apache 、Struts2、Apache Solr、Apache Druid、Apache Flink 等均受影响。目前漏洞细节已被公开，攻击者可利用该漏洞进行远程命令执行。
Apache Log4j2 远程代码执行漏洞的详细信息已被披露，而经过分析，本次 Apache Log4j 远程代码执行漏洞，正是由于组件存在 Java JNDI 注入漏洞。当程序将用户输入的数据记入日志时，攻击者通过构造特殊请求，来触发 Apache Log4j2 中的远程代码执行漏洞，从而利用此漏洞在目标服务器上执行任意代码。
据悉，此次 Apache Log4j2 远程代码执行漏洞风险已被业内评级为“高危”，且漏洞危害巨大，利用门槛极低。有报道称，目前 Apache Solr、Apache Struts2、Apache Druid、Apache Flink 等众多组件及大型应用均已经受到了影响，需尽快采取防御手段。
漏洞简述
2.15.0 之前的 Log4j 版本存在通过 ldap JNDI 解析器的远程代码执行漏洞。根据 Apache 的 Log4j 安全指南：Apache Log4j2 <=2.14.1 在配置、日志消息和参数中使用的 JNDI 功能不能防止攻击者控制的 LDAP 和其他 JNDI 相关端点。当启用消息查找替换时，可以控制日志消息或日志消息参数的攻击者可以执行从 LDAP 服务器加载的任意代码。从 log4j 2.15.0 开始，默认情况下已禁用此行为。
受影响的版本
2.15.0 之前的任何 Log4J 版本都会受到此特定问题的影响。
Log4J 的 v1 分支被认为是生命周期结束 (EOL)，它容易受到其他 RCE 向量的攻击，因此建议仍然尽可能更新到 2.15.0。
影响
使用易受攻击的 Log4J 版本记录不受信任或用户控制的数据可能会导致针对我们的应用程序的远程代码执行 (RCE)。这包括记录的错误中包含的不受信任的数据，例如异常跟踪、身份验证失败和用户控制输入的其他意外向量。
解决方案
此问题已在 Log4J v2.15.0 中修复，强烈建议升级到官方最新的版本。
目前，Apache Log4j 已经发布了新版本来修复该漏洞，请受影响的用户将 Apache Log4j2 的所有相关应用程序升级至最新的 Log4j-2.15.0 版本，同时升级已知受影响的应用程序和组件，如 srping-boot-strater-log4j2、Apache Solr、Apache Flink、Apache Druid 等。
Apache 日志服务团队还提供以下缓解建议，作为临时方案使用：
- 以前的版本 (>=2.10) 中，可以通过将系统属性“log4j2.formatMsgNoLookups”设置为“true”或从类路径中删除 JndiLookup 类来缓解这种行为（例如：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class）；
- Java 8u121 通过将“com.sun.jndi.rmi.object.trustURLCodebase”和“com.sun.jndi.cosnaming.object.trustURLCodebase”默认为“false”来防止 RCE；
-
如果Log4J 无法升级，请确保在客户端和服务器端组件上都设置了 ：
-Dlog4j2.formatMsgNoLookups=true 系统属性。