Log4j 2.x < 2.15.0 反序列化漏洞分析(含排查措施和修复建议)

VSole2021-12-10 20:20:14

漏洞简述

Log4j 2系列 < 2.15.0版本中存在反序列化漏洞。

奇安信代码安全实验室分析发现该组件存在Java JNDI注入漏洞。程序将用户输入的数据进行日志,即可触发此漏洞;成功利用此漏洞的攻击者可在目标服务器上执行任意代码。

奇安信代码安全实验室经验证,Apache Struts2、Apache Solr、Apache Druid、Apache Flink等众多组件与大型应用均受影响。

漏洞复现

为便于验证,复现使用的是环境 java 1.8.0_161 的较老版本。

利用工具如下:

https://github.com/tangxiaofeng7/apache-log4j-poc

结果成功执行指定命令(打开macdown)。

代码分析

在org.apache.logging.log4j.core.lookup Interpolator.calss lookup() 处理时,从第 190 行可以看到,它支持多种格式,其中包含jndi,故而使用jndi尝试进行攻击。

触发点在org.apache.logging.log4j.core.net JndiManager.class lookup()。

传入可能的用户输入值,即可触发攻击。

修复分析

在 org.apache.logging.log4j.core.appender AbstractOutputStreamAppender.class directEncodeEvent() 调用getLayout()进行处理时,如下所示代码中添加了对于jndi调用的白名单检查。

并且,后续对 org.apache.logging.log4j.core.net JndiManager.class lookup() 基本重写,也添加了jndi检查。

缓解分析

jvm 启动参数

-Dlog4j2.formatMsgNoLookups=true`

在传入上述逻辑之前,org.apache.logging.log4j.core.pattern MessagePatternConverter.class format() 中

第114 行会执行检查:如果按照缓解建议添加jvm启动参数,那么此处this.noLookups即为true,则不会进入后续处理,不会触发后续反序列化流程。

处理建议

1、漏洞排查

排查应用是否引入了 Apache Log4j2 Jar 包,若存在依赖引入,则可能存在漏

洞影响。

  • (a)相关用户可根据 Java JAR 解压后是否存在 org/apache/logging/log4j 相关路径结构,判断是否使用了存在漏洞的组件,若存在相关 Java 程序包,则极可能存在该漏洞。

  • (b)若程序使用 Maven 打包,查看项目的 pom.xml 文件中是否存在如下图所示的相关字段,若版本号为小于 2.15.0-rc2,则存在该漏洞。

  • (c)若程序使用 gradle 打包,查看 build.gradle 编译配置文件,若在dependencies 部分存在 org.apache.logging.log4j 相关字段,且版本号为小于 2.15.0-rc2,则存在该漏洞。

2、攻击排查

  • 攻击者在利用前通常采用 dnslog 方式进行扫描、探测,对于常见
  • 利用方式可通过应用系统报错日志中的
  • “javax.naming.CommunicationException”、
  • “javax.naming.NamingException: problem generating object using object factory”、”Error looking up JNDI resource”关键字进行排查。
  • 流量排查:攻击者的数据包中可能存在:“${jndi:rmi”、
  • “${jndi:ldap” 字样,推荐使用奇安信网神网站应用安全云防护系
  • 统全流量或 WAF 设备进行检索排查。

3、修复建议

(1)升级到最新版本:

请联系厂商获取修复后的官方版本:https://github.com/apache/logginglog4j2 ;

请尽快升级 Apache Log4j2 所有相关应用到最新的 log4j-2.15.0-rc2 版本,地址:https://github.com/apache/logginglog4j2/releases/tag/log4j-2.15.0-rc2 或采用奇安信产品解决方案来防护此漏洞。

(2)缓解措施:

  • 添加 jvm 启动参数 -Dlog4j2.formatMsgNoLookups=true。
  • 在应用程序的 classpath 下添加 log4j2.component.properties 配置文件文件,文件内容:log4j2.formatMsgNoLookups=True。
  • 设置系统环境变量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 设置为 true。
  • 建议 JDK 使用 11.0.1、8u191、7u201、6u211 及以上的高版本。
  • 限制受影响应用对外访问互联网。

事件启发

Apache Log4j 是Apache 的一个开源项目。Log4j 是一个强大的日志操作包,是可重用组件,广泛应用于Java、 C、C++、.Net、PL/SQL 等程序中。通过各种第三方扩展,可将 Log4j 集成到 J2EE、JINI以及SNMP应用中。

近年来,攻击者越来越多地开始利用开源组件漏洞发动供应链攻击。据安全机构调查显示,开源供应链攻击事件比2020年增长了650%。虽然企业第三方风险管理的意识和预算已经增长,但这并不一定意味着所采取的措施是有效的。

奇安信代码安全事业部技术总监章磊认为,Apache Log4j RCE 漏洞之所以能够引起安全圈的极大关注,不仅在于其易于利用,更在于它巨大的潜在危害性。当前几乎所有的技术巨头都在使用该开源组件,它所带来的危害就像多米诺骨牌一样,影响深远。我们首先需要做的是梳理自身产品中所使用的软件资产,检测其中是否使用了开源组件、影响哪些资产、影响程度如何,判断受影响资产应修复到哪个版本,其它关联组件是否受影响等,最后着手修复和防御后续类似攻击。用户可通过奇安信开源卫士等工具系统化地应对此类漏洞。

章磊还表示,开源软件安全治理是一项任重道远的工作,需要国家、行业、用户、软件厂商都重视起来并投入才能达到良好效果。

奇安信开源卫士20211209.907版本已支持对Log4j 任意代码执行漏洞的检测。用户可登录 https://oss.qianxin.com 进行检测。

序列化log4j
本作品采用《CC 协议》,转载必须注明作者和本文链接
12月9日晚,Apache Log4j2反序列化远程代码执行漏洞(CVE-2021-44228)细节已被公开,受影响版本为Apache Log4j 2.x< 2.15.0-rc2。 Apache Log4j-2中存在JNDI注入漏洞,当程序将用户输入的数据进行日志记录时,即可触发此漏洞,成功利用此漏洞可以在目标服务器上执行任意代码。 当前官方已发布2.15.0、2.15.1-rc1等版本,用户
腾讯云容器安全服务团队通过犀引擎发现较多镜像受ApacheLog4j2远程代码执行漏洞影响,存在较高风险!为助力全网客户快速修复漏洞,免费向用户提供试用,登录控制台(https://console.cloud.tencent.com/tcss)即可快速体验。
2022年1月19日,360漏洞云团队监测到Apache发布安全公告,修复了多个存在于Apache Log4j中的漏洞。其中,1个严重漏洞,2个高危漏洞。Apache Log4j序列化漏洞漏洞编号CVE-2022-23307漏洞类型反序列化漏洞等级严重公开状态未知在野利用未知漏洞描述由于处理序列化数据时不安全的输入验证而存在该漏洞。
本文首发于奇安信攻防社区漏洞简述Log4j 2系列 < 2.15.0版本中存在反序列化漏洞。奇安信代码安全实
Apache Log4j 1.2 版本的 Java 日志库中存在一个缺陷,JMSAppender 容易受到不受信任 数据的反序列化的影响,如果部署的应用程序配置为使用 JMSAppender 和攻击者的 JMS Broker,允许远程攻击者在服务器上执行代码。发现存在 JNDI 远程命令执行漏洞,效果与 log4j2 漏洞类似,但利用条件相对苛刻。
后续经过扫描探测发现T3、IIOP协议同时关闭了,仅限HTTP访问。需要用户名密码,打补丁后,可以判断用户名密码是否存在,但是无法上传文件成功。
近日,Apache官方发布了多个安全漏洞的公告,包括Apache log4j 代码问题漏洞(CNNVD-202201-1425、CVE-2022-23307)、Apache Log4j SQL注入漏洞(CNNVD-202201-1421、CVE-2022-23305)、Apache log4j 代码问题漏洞(CNNVD-202201-1420、CVE-2022-23302)等。成功利用上述漏洞的攻
目前的Log4j2检测都需要借助dnslog平台,是否存在不借助dnslog的检测方式呢
Apache Log4j2是一款优秀的Java日志框架,最近爆出了一个jndi注入的漏洞,影响面非常广,各大厂商都被波及。Log4j2作为日志记录的第三方库,被广泛得到使用,这次主要分享一下,最近的一些调试记录。
这是本系列第三篇文章,依旧是某省HVV红队的经历。 过程中只用到很简单的方法,所以加了个标题“有手就行”。 这家企业在内网犯了几乎所有能犯的错误,打起来也比较顺利,只不过当时被管理员发现了,争分夺秒的过程也比较有趣哈哈。
VSole
网络安全专家