由于利用工具以及很成熟了，就不进行复现了。本文只探讨漏洞原理。个人见解。

低版本shiro550

手动判断是否存在shiro组件的方法

1，未登录的情况下，请求包的cookie中没有rememberMe字段，返回包set-Cookie里也没有deleteMe字段
2，登录失败的话，不管有没有勾选RememberMe字段，返回包都会有rememberMe=deleteMe字段
3，不勾选RememberMe，登录成功的话，返回包set-Cookie里有rememberMe=deleteMe字段。但是之后的所有请求中Cookie都不会有RememberMe字段
4，勾选RememberMe，登录成功的话，返回包set-Cookie里有rememberMe=deleteMe字段，还会有remember字段，之后的所有请求中Cookie都会有rememberMe字段
5，或者可L以在cookie后面自己加一个rememberMe=1.看返回包有没有rememberMe=deleteMe

我们首先要搞明白Shiro的RememberMe机制的流程，是如何实现用户通过Cookie（rememberMe字段）实现无状态会话保持的。

客户端请求 → 生成序列化用户信息 → AES加密 → Base64编码 → Cookie返回

客户端携带Cookie → Base64解码 → AES解密 → 反序列化恢复会话

漏洞根源就是加密cookie的硬编码密钥泄露，反序列化无校验：解密后的数据直接通过ObjectInputStream反序列化，未进行类白名单过滤。

获取到密钥之后就可以根据不同环境选择合适的利用链。有了key和链，就可以开始利用

序列化恶意对象 → AES-CBC加密 → Base64编码 → 设置Cookie头；

我们构造好payload然后进行AES加密，base64编码后，设置在cookie部分，发送恶意Cookie至目标登录接口，触发反序列化执行任意代码。（可以使用ysoserial工具进行序列化对象）

服务端接收到cookie后的处理过程

1. **Cookie解析**：Shiro从请求头提取`rememberMe`字段值。

2. **Base64解码**：将字符串解码为二进制数据。

3. **AES解密**：使用默认或自定义密钥解密得到原始序列化数据。

4. **反序列化触发**：

- 调用`ObjectInputStream.readObject()` 还原对象。

- 通过Gadget链反射调用危险方法（如`Runtime.exec()` ）。

高版本shiro721

721的漏洞根源是AES-CBC加密模式中Padding校验机制缺陷，可以通过错误回显爆破加密密钥。

也就是密钥可爆破（佳都），或者获得已登录的cookie逆过程来构造payload

（偷一个图）

已知Cookie的利用价值

• 关键信息获取：
  有效Cookie（rememberMe=Base64(AES-CBC(序列化用户数据))）提供以下信息：
  • 加密块对齐方式：通过Base64解码后的长度推断分块模式。
  • 合法明文结构：用户数据序列化后的字节特征（如类名、字段长度）。
• 攻击方法：
  基于合法Cookie的已知明文-密文对，可跳过部分Padding爆破步骤，直接构造恶意Payload。

开始复现

环境搭建

git clone https://github.com/inspiringz/Shiro-721.git
cd Shiro-721/Docker
docker build -t shiro-721 .
docker run -p 8080:8080 -d shiro-721h

或者直接使用vulfocus在线靶场