Log4j 爆“核弹级”漏洞,公司炸锅了...

2021年12月12日 140点热度 0条评论

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

%title插图%num

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

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

怎么利用这个漏洞呢?

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

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

log4j2

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

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

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

今天讨论的主角就是log4j2。

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

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

现在思考一个问题:

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

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

%title插图%num

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

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

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

%title插图%num

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

JNDI

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

%title插图%num

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

看不懂?看不懂就对了!

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

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

%title插图%num

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文件里面藏有恶意代码,那不就完犊子了吗?

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

%title插图%num

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

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

JNDI 注入

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

%title插图%num

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

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的说明:

%title插图%num

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

%title插图%num

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

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

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

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

赶紧检查检查哦!

%title插图%num

harry

这个人很懒,什么都没留下

文章评论