Apache Shiro 组件反序列化漏洞分析

最新推荐文章于 2025-06-03 17:36:08 发布

why811

最新推荐文章于 2025-06-03 17:36:08 发布

阅读量1.5k

点赞数 1

CC 4.0 BY-SA版权

文章标签： apache java eclipse tomcat

本文链接：https://blog.youkuaiyun.com/why811/article/details/133904219

本文主要介绍Shiro反序列化漏洞，包括Shiro - 550和Shiro - 721。Shiro为保持用户登录状态，将持久化信息加密存于Cookie的rememberMe字段。在Shiro 1.2.4版本前有默认固定加密Key，攻击者可伪造Cookie触发漏洞。还分析了漏洞产生原因、加密解密过程及1.2.5版本修复情况。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

概述

Apache Shiro是一个强大且易用的Java安全框架,执行身份验证、授权、密码和会话管理。使用Shiro的易于理解的API,您可以快速、轻松地获得任何应用程序,从最小的移动应用程序到最大的网络和企业应用程序。

它的原理比较简单：为了让浏览器或服务器重启后用户不丢失登录状态，Shiro支持将持久化信息序列化并加密后保存在Cookie的rememberMe字段中，下次读取时进行解密再反序列化。但是在Shiro 1.2.4版本之前内置了一个默认且固定的加密Key,导致攻击者可以伪造任意的rememberMe Cookie,进而触发反序列化漏洞。

Shiro反序列化漏洞目前为止有两个，Shiro-550(Apache Shiro < 1.2.5)和Shiro-721( Apache Shiro < 1.4.2 )。这两个漏洞主要区别在于Shiro550使用已知密钥撞，后者Shiro721是使用登录后rememberMe={value}去爆破正确的key值进而反序列化，对比Shiro550条件只要有足够密钥库（条件比较低）、Shiro721需要登录（要求比较高鸡肋）。

Apache Shiro < 1.4.2默认使用AES/CBC/PKCS5Padding模式

Apache Shiro >= 1.4.2默认使用AES/GCM/PKCS5Padding模式

shiro反序列化漏洞成因

概述

Apache Shiro是一个强大且易用的Java安全框架,执行身份验证、授权、密码和会话管理。使用Shiro的易于理解的API,您可以快速、轻松地获得任何应用程序,从最小的移动应用程序到最大的网络和企业应用程序。

Apache Shiro < 1.4.2默认使用AES/CBC/PKCS5Padding模式

Apache Shiro >= 1.4.2默认使用AES/GCM/PKCS5Padding模式

Shiro-550：Hard Code->Deserialize->RCE

Shiro 550 反序列化漏洞存在版本：

shiro <1.2.4，产生原因是因为shiro接受了Cookie里面rememberMe的值，然后去进行Base64解密后，再使用aes密钥解密后的数据，进行反序列化。

这个aes密钥是硬编码（简称写死），也就是他密钥是写死在jar包里面的，众所周知AES 是对称加密，即加密密钥也同样是解密密钥，那如果我们能知道了这个密钥就可以伪造恶意cookie

接下来我们从Cookie的加密和解密过程来了解shiro-550

Cookie加密过程

直接来看shiro的CookieRememberMeManager在org.apache.shiro.web.mgt.CookieRememberMeManager#rememberSerializedIdentity里面，存在一个将serialized数据Base64加密然后作为Cookie返回的行为

我们看下哪些地方调用了这个方法，狂摁Ctrl+B:

 org.apache.shiro.web.mgt.CookieRememberMeManager#rememberSerializedIdentity<-
 org.apache.shiro.mgt.AbstractRememberMeManager#rememberIdentity<-
 org.apache.shiro.mgt.AbstractRememberMeManager#rememberIdentity(重载)<-
 org.apache.shiro.mgt.AbstractRememberMeManager#onSuccessfulLogin

看到这个函数名都知道是登陆成功调用的，如果继续跟下去的话，会有：

 org.apache.shiro.mgt.DefaultSecurityManager#rememberMeSuccessfulLogin <-
 org.apache.shiro.mgt.DefaultSecurityManager#onSuccessfulLogin<-
 org.apache.shiro.mgt.DefaultSecurityManager#login<-
 ……

会追溯到Filter之类的，大概就是：

登陆->登陆成功->设置Base64编码后的AES加密的Cookie

在onSuccessfulLogin方法这里下个断点

在调用rememberIdentity之前先调用isRememberMe判断了用户是否选择了RememberMe选项，如果选了进入rememberIdentity方法

这个方法先创建一个PrincipalCollection对象，包含了登录信息。

随后进入rememberIdentity方法

这个方法调用convertPrincipalsToBytes把序列化后的PrincipalCollection对象加密，然后返回

而这个seriallize方法，调用org.apache.shiro.mgt.AbstractRememberMeManager#getEncryptionCipherKey去获取加密的key

跟进，发现直接返回了一个属性

转到定义，这个属性貌似是预先定义好的，虽然没看出究竟是哪里定义的，不过我们可以看到一个叫做DEFAULT_CIPHER_KEY_BYTES的东西，这个就是传说中的硬编码的shirokey

之后就是调用rememberSerializedIdentity返回base64加密的cookie了。

接下来康康解密过程：

Cookie解密过程

我们其实可以猜测，加密解密的功能实际上都是由这个

org.apache.shiro.web.mgt.CookieRememberMeManager类来实现的，在这个类里面四处找一找，可以找到getRememberedSerializedIdentity方法里面有一行：

这个很像获取Cookie然后去读取值的操作，在这里下个断点，带着Cookie访问服务，果然就断下来了

单步跟进，发现他获取到了我们的Cookie：

随后判断了一下我们Cookie的值是不是等于DELETED_COOKIE_VALUE (deleteMe)，如果不是则进行decode并且返回：

返回到了这里：

并且调用convertBytesToPrincipals（这个函数名字是不是很熟悉？），将Cookie的结果转化为凭据（PrincipalCollection对象）

因为之前加密过程调用convertPrincipalsToBytes，是一个序列化过程，那这里显然就是一个反序列化过程，跟进：

解密，而后反序列化；

跟进，触发点在

org.apache.shiro.io.DefaultSerializer#deserialize：

1.2.5 版本修复

修改了org.apache.shiro.mgt.AbstractRememberMeManager的硬编码方式，并且去掉了默认key，采用随机生成的shiro AES key

但是这个key是可以自定义的：

private static final String ENCRYPTION_KEY = "3AvVhmFLUs0KTA3Kprsdag==";
public CookieRememberMeManager rememberMeManager() {
        CookieRememberMeManager cookieRememberMeManager = new CookieRememberMeManager();
        cookieRememberMeManager.setCookie(rememMeCookie());
        // remeberMe cookie 加密的密钥 各个项目不一样 默认AES算法 密钥长度（128 256 512）
        cookieRememberMeManager.setCipherKey(Base64.decode(ENCRYPTION_KEY));
        return cookieRememberMeManager;
}

或者：

spring-shiro.xml

在安全管理器SecurityManager中加入rememberMeManager；