apache log4j2漏洞修复（log4j2漏洞CVE44228官方修复方案）

本文目录

• log4j2漏洞CVE44228官方修复方案
• 各组织/开源项目对 Log4Shell 漏洞的响应汇总
• 未及时上报安全漏洞 阿里云被工信部通报 业内人士：错在没有重视流程
• Apache Log4j2远程代码执行漏洞
• Log4j史诗级漏洞，我们这些小公司能做些什么
• 烽火狼烟丨Apache Log4j2远程代码执行漏洞（CVE44832）通告
• Log4j 漏洞还没收拾完，新漏洞又来了
• 怎么检查有没有Apache Log4j漏洞

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 .
***隐藏网址***

各组织/开源项目对 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 漏洞的回应，格式为 公司/组织/项目名称 | 回应类别（已更新/修复/不受影响等）| 回应链接 。 此漏洞影响面太广，希望大家一起合作，避免更多组织或个人因此受到损失。

未及时上报安全漏洞 阿里云被工信部通报 业内人士：错在没有重视流程

通报指出，阿里云是工信部网络安全威胁信息共享平台合作单位。经研究， 现暂停阿里云公司作为上述合作单位6个月。暂停期满后，根据阿陵迅里云公司整改情况，研究恢复其上述合作单位 。

据了解，Apache Log4j2作为阿帕奇软件基金会旗下的一款日志纪录工具，是基于Java语言的开源日志框架，被广泛用于业务系统开发。

工信部网络安全管理局曾在17日发布了《关于阿帕奇Log4j2组件重大安全漏洞的网络安全风险提示》。其中指出，坦汪码 阿里云在近日发现阿帕奇Log4j2组件存在远程代码执行漏洞 ，并将漏洞情况告知阿帕奇软件基金会。 12月9日，工信部网络安全威胁和漏洞信息共享平台收到有关网络安全专业机构报告 ，阿帕奇Log4j2组件存在严重安全漏洞。

随后，工信部立即组织有关网络安全专业机构开展漏洞风险分析，召集阿里云、网络安全企业、网络安全专业机构等开展研判，通报督促阿帕奇软件基金会及时修补该漏洞，向行业单位进行风险预警。

“目前来看，是阿里更早发现了这个漏洞，并将问题反馈给了Apache基金会让哪，之后Apache为Log4j发布了新版补丁修复。但是，阿里云没有及时去向工信部申报。主要错误在于没有重视上报流程和申报漏洞。”有业内人士表示。

根据今年9月1日施行的工信部、国家网信办、公安部联合印发的《网络产品安全漏洞管理规定》， 网络产品提供者应在发现漏洞的2日内向工业和信息化部报送漏洞信息 ，并及时进行修补，将修补方式告知可能受影响的产品用户。

据此前报道，阿里云安全团队于11月24日向阿帕奇软件基金会提交了Log4j 漏洞邮件。而根据公告，工信部是12月9日才收到上述漏洞的报告，距离阿里云首次发现已经过去了2个星期。

Apache Log4j2远程代码执行漏洞

一、情况分析

近日，监测发现互联网中出现 Apache Log4j2 远程代码执行漏洞。攻击者可利用该漏洞构造特殊的数据请求包，最终触发远程代码执行。由于该漏洞影响范围极广，建议广大用户及时排查相关漏洞。

Apache Log4j2是一个基于Java的日志记录工具。该工具重写了Log4j框架，并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发，用来记录日志信息。大多数情况下，开发者可能会将用户输入导致的错误信息写入日志中。此次漏洞触发条件为只要外部用户输入的数据会被日志记录，即可造成远程代码执行。

由于Apache Log4j2在JAVA应用中使用量大，目前已知受影响的组件应用有：Apache Struts2、Apache Solr、Apache Druid、Apache Flink，但问题不仅仅局限在这些项目，用Java开发的系统都有可能用此日志框架。

二、影响范围

Apache Log4j 2.x 《= 2.14.1

三、处置建议

***隐藏网址***

2、升级已知受影响的应用及组件，如spring-boot-start-log4j2/Apache Solr/Apache Flink/Apache Druid

排查方法：到服务器搜索排查Java应用是否引入 log4j-api , log4j-core 两个jar包，影响版本：Apache Log4j 2.x 《= 2.14.1

参考链接

***隐藏网址***

***隐藏网址***

Log4j史诗级漏洞，我们这些小公司能做些什么

12月10日，看到朋友圈中已经有人在通宵修改、上线系统了。随即，又看到阿里云安全、腾讯安全部门发出的官方报告：” Apache Log4j2存在远程代码执行漏洞 “，且漏洞已对外公开。

看到相关消息，马上爬起来把所有项目的日志系统过滤一遍，还好老项目采用的log4j，新项目采用的logback，没有中招。随后就看到朋友圈铺天盖地的相关消息。

作为一个史诗级的事件，紧急修改漏洞是必然的。作为程序员，如果看到这则消息，连去核查一下系统都做不到，那真的不是一个合格的程序员。

经历过这次事件，不仅是看热闹而已，还要思考一下，作为小公司如何避免、提前预防、做好准备应对这类Bug。

Apache Log4j2是一款优秀的Java日志框架，与Logback平分秋色，大量主流的开源框架采用了Log4j2，像Apache Struts2、Apache Solr、Apache Druid、Apache Flink等均受影响。所以，这样一个底层框架出现问题，影响面可想而知。

漏洞信息： Apache Log4j 2.15.0-rc1 版本存在漏洞绕过，需及时更新至 Apache Log4j 2.15.0-rc2 版本。

影响范围：2.0 《= Apache log4j2 《= 2.14.1。

***隐藏网址***

方案一：升级版本，发布系统；

方案二：临时补救：

攻击伪代码示例：

基于上述代码的基本攻击步骤：

腾讯安全专家的回复现如下：

log4j2漏洞复现

关于漏洞及解决方案，上面已经详细聊了，问题基本得以解决。在大的互联网企业，是有专门的安全运维部门来监控、扫描这些漏洞的。但在小公司，很显然没有这样的条件。

那么，我们该怎么办？同时，作为事件的经历者，你是否思考过这个事件中反映出的一些其他问题吗？

在大企业，一旦发现这样的漏洞，安全部门会第一时间进行通知。但在小企业，没有安全部门，你是如何获取到漏洞的消息的呢？

比如我所在的企业，是没有安全部门的，但也几乎是第一时间得知漏洞消息，进行系统排查的。

如何获得圈内第一手消息，取决于也反映着你在社交圈或技术圈所处的位置与现状 。

很多朋友可能也看到了这则漏洞消息，但也就是看一下热闹，然后该干嘛干嘛了，系统有漏洞就有漏洞了呗~

如果你是如此，或者你的团队是如此，你真的需要反省一下职业素养问题了。

很多人可能觉得自己很牛，觉得自己怀才不遇，觉得工资收入低，觉得被亏待……那么，对照一下对这件事所作出的反应，基本就知道自己是不是被亏待了。

这样的突发事件，也是对系统运维、团队管理的一个考验，也是一个仿真练习：大家都正在进行着当前业务的开发，有一个突发Bug要修改，改一半的代码如何操作？如大面积发布？

第一 ，改一半的代码怎么办？如果你的团队的代码开发都是基于master（主干）进行开发、提交代码，针对这样的突发事件，必然会面对改了一半的代码，提交了，想一起发布但还没测试，这种骑虎难下的局面。

所以，代码的管理（如何打分支、合并分支、分支与主干代码不同环境的发布）必须得从日常的点滴做起，当突发事件发生时，也不至于手忙脚乱。

第二 ，有大量项目需要发布怎么办？当然，最古老的方式就是一个系统一个系统手动发布。如果是微服务及应用较多，不仅容易出现错误，而且耗时较长。这就提醒我们，构建自动化发布流程的重要性。

有安全部门的公司，会定期扫描系统漏洞，那么没有安全部门的公司只能坐以待毙吗？

任何一个漏洞对软件系统来说都有可能是致命的，也是需要我们谨慎对待的。对于漏洞的处理及做出的反应也是从业者职业素养的体现。

而如果能从一次次突发事件中学习、思考到更多内容，你将比别人更快地成长。

烽火狼烟丨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 及更高版本），官方下载地址：

***隐藏网址***

注：从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。

参考链接

***隐藏网址***

***隐藏网址***

***隐藏网址***

Log4j 漏洞还没收拾完，新漏洞又来了

闹得沸沸扬扬的Apache Log4j 2 被曝存在“核弹级”漏洞从被发现到现在已经过去了十几天，据说全球有近一半企业都受到了影响。

大批研发和安全人员为此深夜加班修 Bug，直到今天

Log4j 漏洞的修复工作还在进行中，然而新的漏洞又出现了。

据云安全供应商 Wiz 报告，微软 Azure 应用服务中存在一个名为“NotLegit”的漏洞——该漏洞将影响所有通过“本地 Git”部署的 PHP、Node、Ruby 和 Python 应用。

Wiz 方面将该漏洞称为“NotLegit”，自 2017 年 9 月以来便一直存在，很可能已被利用。Wiz 指出，唯一不受“NotLegit”漏洞影响的是基于 IIS 的应用，具体影响范围包括：

自 2017 年 9 月以来，在 Azure 应用服务中使用“本地 Git”部署的所有 PHP、Node、Ruby 和 Python 应用；

从 2017 年 9 月起，在应用容器中创建或修改文件后，使用 Git 源代码部署在 Azure 应用服务中的所有 PHP、Node、Ruby 和 Python 应用；

微软在了解问题严重性后很快便采取了相关必要措施。Azure 应用服务团队进行深入调查找到了根结所在，随后为大部分受影响客户修复应用，并在 2021 年 12 月 7 日至 15 日之间通过邮件通知所有仍然暴露的客户。

No.1

因为Log4j漏洞涉及范围广，让不少不了解相关技术的人也知道了安全漏洞这个概念。对于技术开发和安全人员来说，安全漏洞问题其实是非常常见的，也已经成为了一个重要的课题。

常见的安全漏洞主要有以下这些：

SQL注入

web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。

失效的身份认证

应用中负责认证和会话管理的部分没有正确实现，使得攻击者得以泄露密码，口令或令牌，进而可能获取其他用户的身份。

敏感数据泄露

攻击者不是直接攻击密码，而是在传输过程中或从客户端（例如：浏览器）窃取密钥、发起中间人攻击，或从服务器端窃取明文数据。这通常需要手动攻击。通过使用图形处理单元（GPU），早前检索的密码数据库可能被暴力破解。

越权访问

越权访问（Broken Access Control，简称BAC）是Web应用程序中一种常见的漏洞，由于其存在范围广、危害大，被OWASP列为Web应用十大安全隐患的第二名。

安全性错误配置

攻击者能够通过未修复的漏洞、访问默认账户、不再使用的页面、未受保护的文件和目录等来取得对系统的未授权的访问或了解。

XSS跨站脚本攻击

XSS漏洞出现在当web页面包含不可信的数据，却没有合适的验证手段来找到它的时候。XSS使得攻击者能够在受害者的浏览器中执行脚本，从而劫持会话，或重定向到恶意站点。

其实安全问题出现的原因远远不止上述这些，在互联网时代，网络安全问题远比我们想象的要严峻得多。

No.2

随着互联网的发展和普及，网络在给我们生活带来极大便利的同时，也给我们留下了隐私数据泄露、电脑病毒传播等诸多问题，因此不仅仅从个人还是企业的角度来讲，网络安全的相关问题都是重中之重。

企业招聘到合适的安全测试人才相当不易，并非IT企业的招聘要求苛刻，实际情况是大量求职人员受专业技能限制而无法满足企业需求。

安全测试工程师工作的重点在于对企业信息化建设和维护，其中包含技术及管理等方面的工作，工作相对稳定，随着项目经验的不断增长和对行业背景的深入了解，掌握企业核心网络架构、安全技术，具有不可替代的竞争优势。

怎么检查有没有Apache Log4j漏洞

1、人工检测
jar解压后是否存在org/apache/logging/log4j相关路径结构，判断是否使用了存在漏洞的组件，若存在相关Java程序包，则很可能存在该漏洞。
应用程序能引用 org.apache.logging.log4j的包，很大概率存在漏洞
如果应用程序引用了 log4j-core-2.xx.xx.jar 或 log4j-api-2.xx.x.jar 很大概率存在漏洞。
如果pom文件引用了以下
***隐藏网址***
《dependency》
《groupId》org.apache.logging.log4j《/groupId》
《artifactId》log4j-core《/artifactId》
《version》2.xx.x《/version》
《/dependency》
***隐藏网址***
《dependency》
《groupId》org.apache.logging.log4j《/groupId》
《artifactId》log4j-api《/artifactId》
《version》2.xx.xx《/version》
《/dependency》
也是存在漏洞。
修复方法：
官方补丁
***隐藏网址***
临时解决方案
1. 设置jvm参数 “-Dlog4j2.formatMsgNoLookups=true”
2. 设置“log4j2.formatMsgNoLookups=True”
3. 系统环境变量“FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS”设置为“true”
————————————————
版权声明：本文为CSDN博主「非ban必选」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
***隐藏网址***