上海工商网站查询企业信息,网站设计在线crm系统,设计 中国官网,天河建设网站前言Shiro 是 Apache 旗下的一个用于权限管理的开源框架#xff0c;提供开箱即用的身份验证、授权、密码套件和会话管理等功能。该框架在 2016 年报出了一个著名的漏洞——Shiro-550#xff0c;即 RememberMe 反序列化漏洞。4年过去了#xff0c;该漏洞不但没有沉没在漏洞的…前言Shiro 是 Apache 旗下的一个用于权限管理的开源框架提供开箱即用的身份验证、授权、密码套件和会话管理等功能。该框架在 2016 年报出了一个著名的漏洞——Shiro-550即 RememberMe 反序列化漏洞。4年过去了该漏洞不但没有沉没在漏洞的洪流中反而凭借其天然过 WAF 的特性从去年开始逐渐升温恐将在今年的 HW 演练中成为后起之秀。面对这样一个炙手可热的漏洞这篇文章我们就来讲下我是如何从 0 到 1 的将该漏洞的自动化检测做到极致的。漏洞成因网上相关分析已经很多使用了 Shiro 框架的 Web 应用登录成功后的用户信息会加密存储在 Cookie 中后续可以从 Cookie 中读取用户认证信息从而达到“记住我”的目的简要流程如下。在 Cookie 读取过程中有用 AES 对 Cookie 值解密的过程对于 AES 这类对称加密算法一旦秘钥泄露加密便形同虚设。若秘钥可控同时 Cookie 值是由攻击者构造的恶意 Payload就可以将流程走通触发危险的 Java 反序列化。在 Shiro 1.2.4 及之前的版本Shiro 秘钥是硬编码的一个值 kPHbIxk5D2deZiIxcaaaA 这便是 Shiro-550 的漏洞成因。但这个漏洞不只存在于 1.2.4 版本后续版本的读取流程没有什么改动这就意味着只要秘钥泄露依然存在高危风险。有趣的是国内不少程序员习惯性的 copy/paste一些 Github 示例代码被直接复制到了项目中这些示例中设置秘钥的代码也可能被一并带到项目中这就给了安全人员可乘之机后来出现的 Shiro Top 100 Key 便是基于此原理收集的这大概也是该漏洞经久不衰的一个侧面因素吧。反序列化利用链提纯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 反连的 Payloadnew 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 全版本都存在的利用链只是不同版本的变量获取略有差异大致流程如下:1 currentThread - threadGroup -
2 for(threads) - target - this$0 - handler - global -
3 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 检测方式 我这里简单复述一下结论。使用一个空的 SimplePrincipalCollection 作为 payload序列化后使用待检测的秘钥进行加密并发送秘钥正确和错误的响应表现是不一样的可以使用这个方法来可靠的枚举 Shiro 当前使用的秘钥。Key 错误时Key 正确时借助这种方法我们就可以将 Shiro 的检测拆为两步探测 Shiro Key如果探测成功则报出秘钥可被枚举的漏洞如果探测失败直接结束逻辑利用上一步获得的 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 里采用白名单的方式校验一下要加载的类是不是就可以完全避免恶意反序列化的发生既然已有无心插柳的有效性在前何不顺水推舟将这个问题从源码层面根治安全之路漫漫唯有繁星相伴。愿诸位都能成为暗黑森林中的一颗闪亮的星共勉。
