打工人在日常挖洞时,收到了朋友给的一个shiro反序列化洞,而且默认密钥。抑制住自己激动的心,颤抖的手,赶紧掏出了shiro反序列化利用工具。本以为一切将水到渠成,事实证明,反转总是来得措不及防。直接使用shiro反序列化综合利用工具对着漏洞就是“一梭子”,结果......问题不大,可能利用链太少,让我们换一个。通常,飞鸿哥的工具总会给我一个惊喜,然而,飞鸿哥都没有帮我拿下它。这么多利用链都没有一个能拿下它,这shiro怕不是有毒,想安安静静当一个脚本小子看来是不行了。手工一下,看来shiro确实有,我们尝试生成一个payload:自己生成了payload,发现发不过去。payload我就不提供了,网上多的是,看各位想怎么用了:由于payload一个能发过去一个发不过去,证明我应该没有被拉黑。在反复尝试中发现,字符串需要达到一个固定数值,多一个都发不过去。对比了一下,发现一共将近5000个字符,第一行总计才2100,差了800多个字符。整体看下来,感觉好像是waf。如何能让waf解析不了,而让服务端可以解析,是目前的主要问题。当去掉GET方法后,发现服务器报501,但是发现返回包有rememberMe:尝试取消请求包的rememeberMe,返回包也没有了,说明后台处理了rememberMe。终于上岸了:问题是解决了,但是一个个生成payload似乎太麻烦了,合理运用工具才会更美好,今天偷个懒,就不自己写脚本了,直接用人家的代理吧:后面建议用burp对包请求的字符串进行替换,或者写shell,要不然一直抓包改包,比较麻烦:由于请求要经过servlet,所以我在HTTPServlet.class的service函数打了个断点:最后进行上一步操作到”rememberSerializedIdenyity“函数:看到了用于处理请求cookie的”getRememberedSerializedIdentity“函数:因此,当未知http请求时,shiro是先处理cookie后到servlet,所以rememberMe值是会处理的。最终也是拿到了shell。这种防御shiro的方法可谓美妙,取了一个长度临界值,既不影响正常使用,还可以防御攻击。如果这样可以躲避该waf的话,那是不是在某种程度上也可以用来做webshell,效果应该不错。对于这种waf,建议对未知http方法的包进行丢弃,或者修改shiro的默认密钥,防止攻击者对其进行破坏。读完有话想说?点击留言按钮,让上万读者听到你的声音!
文章来源: http://mp.weixin.qq.com/s?__biz=MzAwMzYxNzc1OA==&mid=2247499496&idx=1&sn=6eefbe3244c84f7cdc82311d634c405a&chksm=9b3ad859ac4d514fb50aa3d500715675a39cc6c4603fa7b8c58df96c07ad974b72646983e117#rd
如有侵权请联系:admin#unsafe.sh