使用Elastic Security检测最新的spring4shell漏洞
这个漏洞在清明假期刚出来的时候就想研究一下，一直拖延到现在。看来是已经赶不上热度了，但我觉得还是值得记录一下的。特别是Elastic刚刚在Forrester的“终端检测与响应Wave”报告中， 被评为“Strong Performer”（卓越表现者）
Elastic Security的检测机制
Elastic Security虽然也带了行为勒索软件防御、恶意行为防护、反恶意软件、主机内存保护、内存威胁防护等防护功能，但在现在看到的PoC里面，大多数是通过部署webshell的方式进行远程命令执行的，因为只包含了简单的runtime execute的代码，所以很难被判定为恶意软件（再次验证，单单有防护是不够的，防护很容易被绕过去）：
然后创建安全应用中的时间线（timeline）工具，进行调查：
遵循规则可以检测远程部署 webshell 的行为：
http.request.method : ("POST" or "GET" ) and url.query : *classLoader.resources.context*
威胁捕获（文件创建）
我们还可以从文件的角度检测 webshell。我们不一定要自己去研究，也可以看看我们的安全生态系统中有哪些可以利用的情报。比如，可以：
- 转到https://github.com/edelucia/rules/blob/main/sigma/Spring4Shell.yaml，并复制 sigma 规则
- 转到https://uncoder.io/ 并粘贴规则并转换为 ES 查询
打开 Kibana -> 安全 -> 时间线，修正一下查询：
file.path:*webapps/ROOT* 和 (file.path:*tomcatwar.jsp OR file.path:*shell.jsp OR file.path:*0xd0m7.jsp OR file.path:*wpz.jsp OR file.path :*myshell.jsp) 和 event.action : "creation"
我们还可以通过查看整个漏洞利用路径的分析器，很容易地检查远程执行了哪些命令：
威胁捕获（网络 - 远程命令执行）
根据注入的 webshell 的定义方式，RCE 可能会有所不同。我们可以在我们的演示中使用以下规则来检测 RCE：
http.request.method : ("POST" 或 "GET" ) 和 url.full : *.jsp?*=*
威胁狩猎（java的子进程）
如果我们要检测tomcat(java) -> webshell(java) -> command的链。我们可以在我们的演示中使用以下规则来检测 RCE：
sequence by host.id
/\\*tomcat fork一个java线程\\*/
[process where process.name : "java" and process.parent.name : "java"] by process.parent.pid
/\\*java线程执行运行时命令\\*/
[process.parent.name : "java" and process.args: "/usr/bin/coreutils"] by process.parent.pid
总结
无论是log4shell还是spring4shell，这些漏洞都是针对生产环境，可以远程执行代码的漏洞。大趋势是：DevSecOps 不仅仅是一个想法，而是一个日益增长的现实。可观察性和安全团队在同一平台上协作的解决方案的要求会增加。而Elastic Stack给我们提供了这样的一个途径，我们在使用Elastic Agent采集数据，日志的同时，为什么不把安全防护，安全检测一起做了呢。
