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这边的疏忽，一起搭配唱了一出好戏。也是吸取了教训，不可大意，这种高危漏洞即使存在于内网也应该马上修复，避免百密一疏。