我是靠谱客的博主 大方黑米,最近开发中收集的这篇文章主要介绍Log4j2漏洞受害者自诉之ELK,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

Log4j2漏洞受害者自诉之ELK

    • 前言
    • 现象
    • 排查
    • 最后

前言

书接上回Log4j2漏洞复现 ,撸完代码后我表示不可能、我没事、隔岸观火、被窝里看戏,没过多少就受到了攻击。前文写在最后(图-1),啪啪啪,打脸来的就是这么快。
图-1
在这里插入图片描述

现象

在这里插入图片描述
在这里插入图片描述

排查

由于后面的poweshell是高危操作,阿里云拦截下来了,才有此次报警。

刚开始一脸懵逼,查看了进程链后发现是ELK的logstash,就有点怀疑是最近火爆的Log4j2漏洞在作怪,但是ELK是部署在内网不对外网开放怎么会存在被攻击的漏洞,而且之前我也通过kibana的各种查询测试不存在该漏洞。

疑惑之余,还是搜索了一下ELK目录下是否存在Log4j2的jar包,一看还真有,果断查看log文件是否有异常。——搜索 ${

在这里插入图片描述
哦,这令人窒息的操作,还真是这玩意惹的祸,我甚至有点小兴奋,但是它是怎么攻入内网的,根据时间点查询logstash
在这里插入图片描述
马上就看到了,这个nginx错误日志,试图从前端项目的dist文件里查找${…}内容,但是没找到报错了,打印到了nginx错误日志里了。

真相大白了,而处于内网的ELK又去拉取这个nginx日志,从而执行了这个lookup。

nginx这边一时半会不好调整,还是暂时停用了ELK,等明天上班了去公司摸鱼修复。

最后

还好没什么损失,前文我还在吐槽没有傻子打个日志会用这种占位符的方式,就算用了也应该屏蔽了这种非法输入,结果啪啪啪地打我的脸,这么出名的ELK组件都在用这种方式,而且部署在了内网,还会由于nginx这边的疏忽,一起搭配唱了一出好戏。也是吸取了教训,不可大意,这种高危漏洞即使存在于内网也应该马上修复,避免百密一疏。

最后

以上就是大方黑米为你收集整理的Log4j2漏洞受害者自诉之ELK的全部内容,希望文章能够帮你解决Log4j2漏洞受害者自诉之ELK所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(62)

评论列表共有 0 条评论

立即
投稿
返回
顶部