CVE-2023-22527漏洞剖析:Confluence身份验证绕过与OGNL注入RCE复现

📅 2026/6/25 18:29:27
CVE-2023-22527漏洞剖析:Confluence身份验证绕过与OGNL注入RCE复现
1. 项目概述一次对CVE-2023-22527的深度剖析最近在安全研究圈里CVE-2023-22527这个编号被频繁提及。这是一个影响Atlassian Confluence Data Center和Server的远程代码执行漏洞CVSS评分高达10.0属于最高危级别。简单来说它允许未经身份验证的攻击者在特定配置的Confluence实例上直接执行任意代码从而完全控制服务器。对于任何一个运行着Confluence作为知识库或协作平台的企业来说这无异于在公网上敞开了一扇大门。我花了些时间在可控的实验室环境中完整复现了这个漏洞目的不是为了攻击而是为了彻底理解它的成因、利用条件以及防御要点。这篇文章就是这次复现过程的详细记录和思考希望能给安全运维人员、渗透测试工程师以及对应用安全感兴趣的朋友们提供一个从原理到实操的完整视角。2. 漏洞背景与影响范围解析2.1 漏洞基本信息与严重性CVE-2023-22527是一个存在于Atlassian Confluence Data Center和Server中的身份验证绕过漏洞其直接后果是导致远程代码执行。Atlassian官方在2023年10月初发布了安全公告。这个漏洞的可怕之处在于它不需要攻击者拥有任何有效的用户凭证。在默认配置下Confluence实例如果启用了“允许匿名访问”或配置了特定的“白名单”URL攻击者就可以构造特殊的HTTP请求绕过所有的身份验证检查访问到本应受保护的管理员配置接口。一旦攻击者能够以管理员身份访问这些配置接口他们就可以修改Confluence的配置例如插入恶意的OGNL表达式。Confluence底层使用了Apache Struts2框架而OGNL表达式注入是Struts2历史上臭名昭著的RCE漏洞根源。通过配置修改触发的OGNL表达式解析最终导致了任意Java代码的执行。因此这个漏洞链可以概括为身份验证绕过 - 访问管理员配置功能 - 注入OGNL表达式 - 远程代码执行。其CVSS 3.x评分为10.0临界影响范围覆盖了Confluence Data Center和Server的8.0.0至8.5.3版本。2.2 受影响的版本与配置条件理解这个漏洞的利用条件至关重要并非所有Confluence实例都“在劫难逃”。首先版本是关键。根据官方通告受影响的版本为Confluence Data Center Server: 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.1.0, 8.1.1, 8.1.3, 8.1.4, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.3.0, 8.3.1, 8.3.2, 8.4.0, 8.4.1, 8.4.2, 8.5.0, 8.5.1, 8.5.2, 8.5.3。低于8.0.0或高于8.5.3的版本如8.5.4及以上不受影响。其次配置是另一个决定性因素。漏洞利用的前提是Confluence实例启用了“允许匿名访问”功能。这个功能通常用于让未登录用户也能查看某些公开空间或页面。在confluence.cfg.xml配置文件中这对应着seraph.allow.anonymous.access设置为true。或者管理员在“白名单”中配置了特定的URL路径允许匿名访问而攻击者恰好利用了这些路径。注意很多企业内网的Confluence为了内部协作方便可能默认就开启了匿名访问。而一些面向外网的知识库为了便于合作伙伴或客户查阅也常常会启用此功能。这使得该漏洞的实际影响面非常广。3. 漏洞原理深度拆解从绕过到代码执行3.1 身份验证绕过机制剖析Confluence的权限检查并非铁板一块。其安全过滤器链中对于某些特定的管理端点特别是与配置相关的/json/*和/admin/*下的接口本应进行严格的身份验证和授权检查。然而在受影响版本中当匿名访问功能启用时权限检查逻辑存在缺陷。攻击者发送的HTTP请求中可以通过精心构造的请求参数或路径触发一个逻辑条件使得安全过滤器误认为该请求是针对一个“公开”或“白名单”内的资源从而跳过了后续的权限验证步骤。具体到CVE-2023-22527其绕过点与/server-info.action和/json/setup-restore.action等端点相关。攻击者通过访问一个本应公开的端点或利用白名单再通过请求参数、HTTP头如X-Atlassian-Token或路径遍历技巧将请求“重定向”或“关联”到本应受保护的管理端点最终达到未授权访问/json/setup-restore.action这个关键配置恢复接口的目的。3.2 OGNL表达式注入与命令执行链成功绕过认证访问到/json/setup-restore.action只是一个开始。这个接口的功能是从一个备份文件ZIP格式中恢复Confluence的站点配置。在恢复过程中Confluence会解析备份文件中的confluence.cfg.xml等配置文件并将其内容应用到运行中的实例。漏洞的第二阶段就发生在这里。攻击者可以构造一个恶意的备份ZIP文件。在这个ZIP包的confluence-cfg.xml文件中提前植入恶意的OGNL表达式。例如在某个配置项的值中插入${java.lang.RuntimegetRuntime().exec(calc.exe)}这样的字符串。当Confluence其Web层基于Struts2在解析并应用这个配置文件时如果对配置值的处理不当没有进行充分的过滤或转义就会将${...}中的内容当作OGNL表达式进行解析和执行。OGNLObject-Graph Navigation Language是Struts2中用于绑定视图和控制器数据的强大表达式语言但权力越大责任越大一旦被注入它就能直接调用Java的静态方法、访问系统属性、甚至实例化对象。在实际利用中攻击者通常会使用更复杂的OGNL链来执行命令例如通过ProcessBuilder来执行系统命令或者直接写入一个JSP Webshell到web目录从而获得一个持久的后门。3.3 漏洞利用链全景图为了更直观地理解整个攻击流程我们可以将其梳理为以下几个关键步骤信息收集攻击者识别目标Confluence版本8.0.0 - 8.5.3并探测其是否启用了匿名访问通过访问首页或特定API观察是否要求登录。构造恶意请求利用身份验证绕过漏洞向/json/setup-restore.action端点发送一个未授权的POST请求。上传恶意备份包在请求中携带一个精心构造的ZIP格式备份文件。该文件内包含嵌入了OGNL表达式的confluence-cfg.xml。触发配置恢复Confluence服务端处理该请求开始“恢复”站点配置。解析与表达式执行在解析恶意配置文件时OGNL表达式被触发执行攻击者植入的Java代码得以在服务器上运行。建立控制执行的代码通常用于反弹Shell、下载并执行远程木马或在web目录写入Webshell从而完全控制服务器。4. 实验环境搭建与漏洞复现实操声明以下所有操作均在完全隔离的本地虚拟机实验室中进行所有靶机均为自行搭建的测试版本。严禁对任何非授权系统进行测试。4.1 靶机环境准备为了安全地研究这个漏洞我们需要搭建一个包含漏洞的Confluence环境。准备虚拟机使用VMware或VirtualBox创建一台纯净的Linux虚拟机如Ubuntu 20.04 LTS配置至少4GB内存和2核CPU。确保网络设置为Host-Only或NAT模式与宿主机互通但隔离于外网。安装Java环境Confluence依赖Java。安装OpenJDK 11与Confluence 8.x兼容。sudo apt update sudo apt install openjdk-11-jdk -y java -version # 验证安装下载并安装有漏洞的Confluence从Atlassian官方归档站点下载Confluence 8.5.3的安装包.bin文件和对应的破解/评估用授权文件。直接运行安装程序。chmod x atlassian-confluence-8.5.3-x64.bin sudo ./atlassian-confluence-8.5.3-x64.bin按照交互式提示完成安装选择“评估”模式并指定安装目录如/opt/atlassian/confluence和数据目录。配置与启动安装完成后通过浏览器访问http://虚拟机IP:8090进行初始设置。在设置过程中关键一步是选择“外部数据库”如MySQL或PostgreSQL并提前建好库。使用内嵌的H2数据库在后续恢复操作中可能会遇到问题。完成初始化创建管理员账户。启用匿名访问这是触发漏洞的必要条件。以管理员身份登录Confluence进入“管理” “用户安全” “匿名访问”。勾选“允许匿名访问”并保存。此时未登录用户应能访问Confluence首页。4.2 漏洞利用工具与POC构造网络上已经有安全研究人员公开了针对此漏洞的利用脚本Python。在复现时我们可以参考其逻辑但务必理解每一步在做什么。一个典型的利用脚本核心功能包括检测检查目标URL是否存在、版本是否在受影响范围、匿名访问是否开启。构造恶意备份包在内存中动态生成一个ZIP文件其中包含恶意的confluence-cfg.xml。XML文件中的OGNL表达式需要根据目标系统进行定制Linux为/bin/bash -cWindows为cmd /c。发送攻击请求构造一个多部分表单数据multipart/form-data的POST请求将恶意ZIP包作为buildIndex参数注意实际参数名可能因版本细微差别而不同需根据实际情况调整上传到/json/setup-restore.action端点。请求头中通常需要设置X-Atlassian-Token: no-check以绕过另一层令牌检查。处理执行结果如果漏洞利用成功脚本可能会尝试读取命令执行的结果如果OGNL表达式设计了回显或者直接提示Webshell的写入地址。实操心得一OGNL表达式的“坑”在构造OGNL表达式执行命令时直接使用Runtime.exec(“whoami”)在复杂命令或需要管道的情况下可能会失败。更可靠的方式是使用字符串数组参数形式new String[]{“/bin/bash”, “-c”, “whoami /tmp/out.txt”}。这样能更好地处理命令行中的空格和特殊符号。我们的目标是让服务器将命令执行结果写入一个web可访问的临时文件然后我们再通过HTTP去读取这个文件实现回显。4.3 分步复现过程记录假设我们的靶机IP是192.168.1.100我们已经准备好了利用脚本exploit.py。信息探测# 使用curl探测匿名访问和版本版本信息可能藏在HTML注释或JS文件里 curl -v http://192.168.1.100:8090/ # 查看响应头或页面中是否包含“Atlassian Confluence”及版本号 # 尝试访问一个需要权限的页面看是否直接跳转登录 curl -v http://192.168.1.100:8090/spaces/viewdefault.action如果未登录也能看到页面内容说明匿名访问已开启。执行漏洞利用python3 exploit.py -u http://192.168.1.100:8090 -c “id”脚本会执行以下操作检测环境。在内存中创建ZIP其中XML包含执行id /tmp/test.txt的OGNL表达式。发送未授权POST请求到/json/setup-restore.action。如果成功会尝试访问http://192.168.1.100:8090/tmp/test.txt来读取命令执行结果。验证执行结果 如果利用成功我们访问http://192.168.1.100:8090/tmp/test.txt应该能看到uid1001(confluence) gid1001(confluence) groups1001(confluence)类似的输出这证明我们以Confluence进程用户的身份执行了系统命令。获取交互式Shell可选 为了进一步探索我们可以让目标服务器下载一个反弹Shell的脚本并执行。首先在攻击机Kali上监听一个端口nc -lvnp 4444然后使用漏洞执行一个下载并执行反弹Shell的命令。注意这里需要将命令进行适当的编码或使用更复杂的OGNL链来避免特殊字符问题。一个更稳妥的方法是先写入一个包含反弹Shell命令的脚本文件再执行它。实操心得二关于“恢复”动作的副作用利用/json/setup-restore.action会触发Confluence的“站点恢复”流程。这个过程会覆盖当前Confluence的部分配置在测试环境中这没问题但在理解漏洞时要知道真实的攻击可能会破坏目标服务的正常配置导致服务异常从而容易被发现。这也是一些POC选择写入Webshell而非直接执行破坏性命令的原因——更隐蔽。5. 漏洞修复与安全加固指南5.1 官方补丁与升级方案Atlassian官方已经发布了修复此漏洞的版本。最根本、最有效的解决方案是立即升级。对于Confluence 8.5.x系列升级到8.5.4或更高版本。对于Confluence 8.4.x系列升级到8.4.4或更高版本。对于Confluence 8.3.x系列升级到8.3.4或更高版本。对于更早的8.x版本应升级到上述修复版本或最新的长期支持版。升级前务必在测试环境进行充分验证并做好完整的数据和配置备份。Atlassian提供了详细的升级指南。5.2 临时缓解措施如果由于某些原因无法立即升级必须采取严格的临时缓解措施禁用匿名访问这是阻断漏洞利用链条最直接的一步。进入Confluence管理界面在“管理” “用户安全” “匿名访问”中取消勾选“允许匿名访问”并保存。这将使身份验证绕过失效。检查并清理白名单进入“管理” “常规配置” “站点白名单”审查所有允许未经身份验证访问的URL路径。除非业务绝对必要否则应移除所有条目。特别是要检查是否存在包含/json/或/admin/路径的白名单。网络层隔离与防护防火墙规则在边界防火墙或主机防火墙上严格限制对Confluence服务器端口默认8090的访问。只允许可信的IP地址或IP段如公司办公网访问。WAFWeb应用防火墙部署或启用WAF并更新规则集添加针对CVE-2023-22527的防护规则拦截对/json/setup-restore.action等敏感端点的未授权访问和异常POST请求。监控与告警加强Confluence服务器的日志监控confluence-home/logs/重点关注atlassian-confluence-security.log和atlassian-confluence.log中关于身份验证失败、对/json/setup-restore.action的访问尝试以及配置变更的记录。设置告警一旦发现异常访问立即通知。5.3 长期安全建设建议一次漏洞的修复不应是终点而应是完善安全体系的起点。建立漏洞应急响应流程明确漏洞情报获取、风险评估、临时缓解、升级修复、事后复盘的标准操作程序。最小权限原则运行Confluence的服务器账户如confluence应仅拥有必要的文件系统读写权限避免使用root权限运行。定期安全评估对面向互联网的应用定期进行安全扫描和渗透测试主动发现潜在风险。纵深防御不要依赖单一安全措施。结合网络隔离、主机加固、应用层WAF、入侵检测系统IDS/IPS和严格的访问控制构建多层防御体系。6. 复现过程中的常见问题与排查实录在复现过程中我遇到了几个典型问题这里记录下来供大家参考。6.1 漏洞利用失败的可能原因问题现象可能原因排查步骤与解决方案脚本返回“目标似乎不受影响”或“匿名访问未开启”1. 目标版本不在受影响范围。2. 匿名访问确实被禁用。3. 网络不通或服务未运行。1. 手动访问/login.action查看页面底部或源码中的版本信息。2. 尝试直接访问首页看是否需要登录。访问/spaces/viewdefault.action看是否跳转登录页。3. 使用curl或telnet检查目标IP的8090端口是否开放。脚本显示绕过成功但命令未执行1. OGNL表达式构造有误未能成功解析执行。2. 命令执行了但无回显或回显路径不对。3. 目标服务器存在安全软件拦截。1. 检查构造的OGNL表达式语法特别是转义和引号。尝试最简单的命令如touch /tmp/test_success。2. 登录到靶机服务器查看Confluence应用日志catalina.out或atlassian-confluence.log搜索OGNL或表达式解析错误。3. 检查/tmp/目录下是否生成了预期的文件。请求返回400/500错误1. 请求的端点路径或参数名不正确。2. 备份ZIP文件结构或内容格式不符合Confluence要求。3. Confluence服务内部错误。1. 使用Burp Suite拦截一次正常的Confluence备份/恢复操作对比攻击请求的URL、参数名、请求头差异。2. 分析Confluence日志查看具体的错误堆栈信息。3. 确保ZIP包内必须包含有效的confluence-cfg.xml且其格式能被Confluence解析。命令执行了但权限不足Confluence进程以低权限用户如confluence运行无法执行某些操作如监听1024以下端口。这是正常情况。利用成功后获取的是Confluence进程用户的权限。后续提权需要利用系统或内核的其他漏洞这超出了本漏洞的范围。6.2 实验室环境下的特殊问题数据库连接中断由于漏洞利用本质是触发了一次“站点恢复”这个过程会重写数据库连接配置。如果POC中恶意XML里的数据库连接信息是错误的会导致恢复后Confluence无法连接数据库服务崩溃。在测试环境中务必记录下原始的数据库连接字符串jdbc url或者在构造POC时保持这部分配置与靶机环境一致。并发请求导致服务不稳定自动化脚本可能会快速发送多个请求。Confluence的恢复操作是重量级的频繁触发可能导致服务暂时无响应或内存溢出。在测试时建议单次执行并给服务留出处理时间。实操心得三日志是你的朋友在整个复现过程中confluence-home/logs/atlassian-confluence.log是最重要的信息来源。无论是认证绕过阶段的权限检查日志还是恢复操作时的配置解析日志亦或是OGNL表达式执行时的错误信息都会在这里留下痕迹。学会查看和解读这些日志不仅能帮你排查复现问题更能让你深刻理解漏洞触发的每一步流程这对于真正掌握一个漏洞至关重要。