转载自：https://mp.weixin.qq.com/s/GKbE44VclJKj2PZ4Cpr_Sw
本次 shiro 实战有点像是零组安全实验室考核的那道题目，都是默认密钥，但是无法利用，但是考核人跟我说这是 shiro 的洞，最后也是遗憾没能拿下，今天偶遇这篇文章，思路让我豁然开朗。
打工人在日常挖洞时，收到了朋友给的一个shiro反序列化洞，而且默认密钥。
抑制住自己激动的心，颤抖的手，赶紧掏出了shiro反序列化利用工具。本以为一切将水到渠成，事实证明，反转总是来得措不及防。
1. 长度限制
直接使用shiro反序列化综合利用工具对着漏洞就是“一梭子”，结果……问题不大，可能利用链太少，让我们换一个。
通常，飞鸿哥的工具总会给我一个惊喜，然而，飞鸿哥都没有帮我拿下它。
这么多利用链都没有一个能拿下它，这shiro怕不是有毒，想安安静静当一个脚本小子看来是不行了。
手工一下，看来shiro确实有，我们尝试生成一个payload：
自己生成了payload，发现发不过去。payload我就不提供了，网上多的是，看各位想怎么用了：
由于payload一个能发过去一个发不过去，证明我应该没有被拉黑。在反复尝试中发现，字符串需要达到一个固定数值，多一个都发不过去。
对比了一下，发现一共将近5000个字符，第一行总计才2100，差了800多个字符。
2. 过程
整体看下来，感觉好像是waf。如何能让waf解析不了，而让服务端可以解析，是目前的主要问题。
尝试HOST回车、TAB等一系列操作均未成功：
当去掉GET方法后，发现服务器报501，但是发现返回包有rememberMe：
尝试取消请求包的rememeberMe，返回包也没有了，说明后台处理了rememberMe。终于上岸了：
问题是解决了，但是一个个生成payload似乎太麻烦了，合理运用工具才会更美好，今天偷个懒，就不自己写脚本了，直接用人家的代理吧：
爆破利用链，burp抓包修改后放行：
于是，你就可以看到胜利的晨光：
后面建议用burp对包请求的字符串进行替换，或者写shell，要不然一直抓包改包，比较麻烦：
3. 分析
由于请求要经过servlet，所以我在HTTPServlet.class的service函数打了个断点：
最后进行上一步操作到”rememberSerializedIdenyity“函数：
看到了用于处理请求cookie的”getRememberedSerializedIdentity“函数：
因此，当未知http请求时，shiro是先处理cookie后到servlet，所以rememberMe值是会处理的。
4. 总结
最终也是拿到了shell。这种防御shiro的方法可谓美妙，取了一个长度临界值，既不影响正常使用，还可以防御攻击。
如果这样可以躲避该waf的话，那是不是在某种程度上也可以用来做webshell，效果应该不错。
对于这种waf，建议对未知http方法的包进行丢弃，或者修改shiro的默认密钥，防止攻击者对其进行破坏。
微信
支付宝