log4j2漏洞,log4j2漏洞修复方案
烽火狼烟丨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。
参考链接
烽火狼烟丨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、官方已发布安全版本，请及时下载更新，下载地址：
2、临时缓解措施：
在日志记录配置的PatternLayout中，用线程上下文映射模式（%X、%mdc或%MDC）替换${ctx:loginId} 、${ctx:loginId} 等涉及上下文查找的内容。当所使用诸如HTTP标头或用户输入等应用程序外部的数据时，可以删除对上下文查找的引用。
分布式 | log4j2 漏洞修复方案
dble 运行依赖许多组件的 jar 包，当遇到某个组件有漏洞时，需要紧急修复。
安全漏洞说明：
??：方案1可实施，截止至北京时间2021年12月14日11时，log4j 官方已经发布 2.16.0 版本，相关 release notes：
??：下面介绍的2，3步骤是临时缓解步骤，不排除有其他问题
dble版本：2.19.07.x - 3.21.10.x版本，2.19.07.x之前的版本需要自行尝试替换方案，官方不再提供支持
影响：需要重启 dble
步骤：
1.1 停止 dble
1.2 将 dble 服务器上 log4j 的 jar 包进行备份并 mv 至 /tmp/ 目录下
/path/to/dble/lib 下有四个 jar 包分别是：（操作前需要确认一下）
执行下面的操作：
1.3 将 log4j 2.16.0 版本的相关 jar 包，上传到该路径下/path/to/dble/lib，并变更权限
参考链接： ，其他jar在此网站上查找
1.4 重复1.2，1.3步骤升级其余三个jar包
1.5 启动dble
dble版本：理论上全版本dble适配
影响：需要重启dble
步骤：
在 dble 配置文件 /path/to/dble/conf 下添加配置文件 log4j2.component.properties
修改文件权限：
添加如下配置：
验证方式：
开发环境验证该变量重启后被加载，不重启情况下，不会被加载。
dble版本：适用于dble版本 3.20.07.0
3.20.07.0及之后的dble版本由于对 JVM 参数进行了限制，因此不支持此种方式，会在近期修复。
影响：需要重启dble
步骤：
在 dble 配置文件/path/to/dble/conf/wrapper.cof 中添加如下配置，并重启dble。
配置：
原环境中是否存在 wrapper.java.additional 的参数，下面配置中的14在原环境中按需替换
执行以下命令判断是否使用该参数启动：
不推荐
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 .
链接地址：
警惕！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
下载链接：
2、升级已知受影响的应用及组件，如srping-boot-strater-log4j2/Apache Solr/Apache Flink/Apache Druid
3、手动替换 log4j2 版本为 2.15.1-SNAPSHOT
log4j-core:
log4j-api:
log4j-slf4j18-impl:
4、做好资产自查以及预防工作，以免遭受黑客攻击
“网络大流感”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漏洞的攻击行为将还会持续一段时间，这将是一场“网络安全大流感”。
传统模式下，安全人员可以在本地检测、打补丁、修复漏洞。相对于传统模式，“云上企业”使用的是云计算、云存储服务等，没有自己的机房和服务器。进入云环境，安全防护的“边界”不复存在，对底层主机的控制权限也没有本地那么多，同时还多一层虚拟化方面的攻击方式。
特别是疫情影响下，大量企业、机构开启数字化转型，从本地服务器迁徙到云服务器。短时间内完成云迁移，企业很可能缺乏对应的云安全管理能力成熟度；同时，往往也面临着安全能力不足、专业人手紧缺等情况。
面对这场史诗级的漏洞危机，“云上企业”应该如何应对呢？
在安恒信息高级产品专家盖文轩看来：“企业上云之后，传统的网络安全风险依然存在，此外，还会面临新的安全风险，比如用户与云平台之间安全责任边界划分等问题。另外，传统的硬件设备可能不适用于云环境，因此需要针对特殊情况部署相关安全服务。”
而在安永大中华区 科技 风险咨询服务合伙人赵剑澐看来：“面对快速上云，企业急需搭建满足自身业务发展与管理要求的安全保障体系。”
那么，对于这些“云上企业”，究竟是选择云服务商提供的原生安全服务，还是另寻第三方专业的安全服务商呢？
事实上，目前即使是高度自动化的云原生安全方案，也无法做到完全自主自治，仍然需要合格的云安全服务专业团队参与。高轶峰强调，对于中小型企业，选择满足资质的第三方专业安全机构，能够保证服务的独立性，保障工作顺利开展及服务质量。
每日经济新闻