奇形怪状之java框架漏洞

0x01 啥是框架漏洞，为什么会有这个漏洞？

相信很多人都经历了之前的spring-core事件，好吧就算你不知道这是啥玩意，你也一定从各个安全网站那里得知了一些其他漏洞，比如说之前圈子里过年的log4j2（cve-2021-44228），这两个漏洞分别都是基于log4j2框架，以及spring框架的rce漏洞。到这里，你应该就明白了，因为框架中的某些错误而被利用的漏洞，我们统称他为框架漏洞，我们常见的有shiro、fastjson、st2（前几年HVV流行的三大洞）以及新的log4j2、spring等等。

0x02 如何判断漏洞的存在

既然知道了这些在log4j2、spring框架下可能会产生的漏洞，那我们应当如何判断这些漏洞是否存在呢？这就又回到了我们亘古不变的话题，黑、白、灰盒测试。
我们要知道漏洞存在的条件一定是要知道两个关键的信息的。

1. jdk版本

2. 中间件版本

下面我们根据不同情况逐一进行分析

基于白盒判断是否存在框架漏洞

既然是白盒，我们就要先了解相关框架漏洞的版本信息，我们来看看jdk的版本，当前的jdk版本是不是大于8，以此作为log4j2和spring漏洞存在的首要判断。其次是判断所使用的中间件版本属于apache还是nginx，从而判断出他是否存在st2或是shiro的漏洞。至于我们常见的fastjson和log4j，就只能在审核的过程中来借助工具进行代码的查看了

基于黑盒判断是否存在框架漏洞

既然是黑盒，我们的目的也已经很明显了，对吧？我们只需要通过技术手段获取到他的jdk版本，就可以对漏洞做一个简要的判断。但是，在大多数情况下，我们肯定是没有办法通过常规技术手段来进行jdk版本的判断的，至少据笔者所知没有。绝大多数情况下，黑盒测试者基于对这些框架漏洞的测试判断，还是采用抓包以及盲打的手段来进行一个漏洞的探测。

首先我们在黑盒测试使用bp抓包的过程中，会遇到一些特征码，我们可以依靠这些特征码来进行一个漏洞存在的判断。

比如我们判断现在这个漏洞是否是spring，就可以通过bp的返回包来进行一个查看当我们发现accept头中包含了这部分内容时，我们基本可以确定该框架确实是使用了spring

而类似的判断呢我们还可以对shiro来进行使用，我们对shiro的发包进行一个截取，同样的，当我们在包体内发现了remberme=的参数时，则证明了当前的框架就可能是用shiro进行编写的

恰恰也会有一些比较奇特的框架是不能进行直接抓包判断的，比方说st2框架，在st2框架中我们常见的.action和.do的文件格式，都是需要我们进行一些目录扫描之后才可能会找的到，比如

亦或者是html的源码里我们发现了没有后缀的文件，这也是有可能的。

总而言之，st2的判断就比较麻烦一点，各位师傅还要多费心去研究。

最后的最后，则是我们压轴的两个漏洞，log4j2和fastjson，他们没有固定的测试方式，所以也衍生出了我们经久不衰的测试方式，穷举，直接拿起代码在尾部一顿疯狂输出。例如

可以使用各种各样的语句直接丢在那里进行测试，当然你也可以直接用工具进行批量的攻击，亦或者你也可以通过技术手段增加对应的key，来测试fastjson是否存在。
至于log4j2，各位还是在确认jdk版本之后，自行进行工具测试。

0x03 写在最后

至此，几个漏洞的简要判断就到此结束，后续如果有机会，我们会给大家拆解对应的框架漏洞利用链，或者告诉大家在HVV期间遇到这些事件的应急处理。咱们今天就到此结束。感谢实验室成员望舒的爆肝输出，期待后续我们带给大家更多分享。

该内容转载自网络，更多内容请点击“阅读原文”

原文始发于微信公众号（web安全工具库）：奇形怪状之java框架漏洞