0x01 漏洞描述

Confluence 是由 Atlassian 开发的企业级协作软件。2023年10月，Atlassian 官方披露 CVE-2023-22515 Atlassian Confluence Data Center & Server 权限提升漏洞。攻击者可构造恶意请求创建管理员，从而登录系统，造成敏感信息泄漏等。

如果 Confluence 站点托管在 Atlassian Cloud(域名为：atlassian.net)，则不受此漏洞影响。

0x02 影响版本

8.0.0 - - 8.0.4

8.1.0 - - 8.1.4

8.2.0 - - 8.2.3

8.3.0 - - 8.3.2

8.4.0 - - 8.4.2

8.5.0 - - 8.5.1

0x03 环境搭建

安装包 https://www.atlassian.com/software/confluence/download-archives

jar 包：

https://product-downloads.atlassian.com/software/confluence/downloads/atlassian-confluence-8.5.1.zip  
https://product-downloads.atlassian.com/software/confluence/downloads/atlassian-confluence-8.5.2.zip

大致的安装可以看 https://cn-sec.com/archives/2177640.html

其中有一步数据库的安装会存在一些问题，首先是新建数据库的时候，对编码有要求

CREATE DATABASE confluence CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

随后是连接

jdbc:mysql://localhost/confluence?sessionVariables=transaction_isolation='READ-COMMITTED'

在配置数据库时需要指定 READ-COMMITTED

下一步是做调试准备，这里的调试需要找到 Service

随后在 cmd 里面运行这一个行命令，就会跳出如图所示的框框

tomcat9w.exe //ES//Confluence151123100612

随后添加 JAVA_OPTS，进行动调

【----帮助网安学习，以下所有学习资料免费领！加vx：yj009991，备注“freebuf”获取！】

① 网安学习成长路径思维导图
② 60+网安经典常用工具包
③ 100+SRC漏洞分析报告
④ 150+网安攻防实战技术电子书
⑤ 最权威CISSP 认证考试指南+题库
⑥ 超1800页CTF实战技巧手册
⑦ 最新网安大厂面试题合集（含答案）
⑧ APP客户端安全检测指南（安卓+IOS）

0x04 漏洞分析

根据官方的公告，修复建议是给 /setup打头的接口做鉴权校验

<security-constraint>
<web-resource-collection>
<url-pattern>/setup/*</url-pattern>
<http-method-omission>*</http-method-omission>
</web-resource-collection>
<auth-constraint />
</security-constraint>

由于 Confluence 这里的框架是基于 S2 的，S2 的大致流程如 su18 师傅的图所示

也就是说我们现在需要去找一下 /setup/*接口是怎么被处理的，直接分析是比较难的，所以先 diff 一下代码。

• 首先 struts2.xml里面

• 修复版本新增了 struts.override.acceptedPatterns

• 修复版本删除了 server-info action

• 接着是 BootstapStatusProviderImpl类里面增加了部分内容，对属性 setupPersister 和 applicationConfig 做了限制

这里有点没看懂修了什么，所以我先动调观察具体接口是怎么处理的，根据 Struts2 的特性，去到 struts.xml里面找对应的 Interceptor，不难找到具体处理的拦截器是 SetupCheckInterceptor

开始动调，看一下 /setup/setupadministrator.action接口的逻辑是怎么处理的。

中间走到 com.atlassian.config.ApplicationConfig#isSetupComplete时，在新版本的 fix 里面是增加了这一段的 ReadOnlyApplicationConfig配置的

所以这里的漏洞利用思路大概就是先动态修改 setupPersister或 applicationConfig，在触发了这一点之后，能够下一步访问 /setup/setupadministrator.action，重新配置管理员密码。

这里具体的实现很有意思，su18 师傅的文章说的很明白，我就直接拿过来用了

https://su18.org/post/struts2-1/

OGNL 中的根对象即为 ValueStack（值栈），这个对象贯穿整个 Action 的生命周期（每个 Action 类的对象实例会拥有一个 ValueStack 对象）。当Struts 2接收到一个 .action的请求后，会先建立Action 类的对象实例，但并不会调用 Action 方法，而是先将 Action 类的相应属性放到 ValueStack 的实现类 OgnlValueStack 对象 root 对象的顶层节点（ ValueStack 对象相当于一个栈）。在处理完上述工作后，Struts2 就会调用拦截器链中的拦截器，这些拦截器会根据用户请求参数值去更新 ValueStack 对象顶层节点的相应属性的值，最后会传到 Action 对象，并将 ValueStack 对象中的属性值，赋给 Action 类的相应属性。当调用完所有的拦截器后，才会调用 Action 类的 Action 方法。ValueStack 会在请求开始时被创建，请求结束时消亡。

我们需要找一个 OGNL 的点, 并且这个点能够以某种方式去调用某个类的 getter / setter, 以此来配置 applicationConfig 的 setupComplete 字段

于是去 diff 跟 Struts2 有关的依赖, 即 com.atlassian.struts2_struts-support-1.1.0.jar和 com.atlassian.struts2_struts-support-1.2.0.jar

发现修改的类是 SafeParametersInterceptor，这个类会处理所有的输入，所以 server-info.action这个请求也会经过它

同时，Confluence 使用了 XWork 框架，它允许通过 HTTP 请求来设置 Java 对象的参数：XWork Plugin Complex Parameters and Security

XWork allows the setting of complex parameters on an XWork action object. For example, a URL parameter of formData.name=Charleswill be translated by XWork into the method calls getFormData().setName("Charles")by the XWork parameters interceptor. If getFormData()returns null, XWork will attempt to create a new object of the appropriate return type using its default constructor, and then set it with setFormData(newObject)

这就允许我们在输入时候传参类似于 ?test=a.b.c，动调一下

http://192.168.80.137:8090/server-info.action?a.b.c

这里会先做过滤，跟进 this.filterSafeParameters()方法，该方法会对传入的参数进行判断，如果包含关键字或者满足正则匹配则返回 false

BLOCKED_PARAMETER_NAMES: actionErrors、actionMessages  
EXCLUDE_CLASS_PATTERN: .*class[^a-z0-9_].*  
SAFE_PARAMETER_NAME_PATTERN: \w+((\.\w+)|(\[\d+\])|(\['[\w.]*'\]))*  
MAP_PARAMETER_PATTERN: .*\['[a-zA-Z0-9_]+'\]

如果不在黑名单内，最后会调用 isSafeComplexParameterName()方法，这个方法会检查传入的参数是否调用了当前 action 的某个 getter / setter，如果调用了，则判断里面是否有 ParameterSafe注解。

如果没有实现 @ParameterSafe注解，那么 isSafeMethod 就会返回 false

这么一看，漏洞成立需要绕过黑名单验证，并且满足 @ParameterSafe注解，利用条件十分苛刻。继续往下走，回到 com.atlassian.xwork.interceptors.SafeParametersInterceptor#doIntercept，跟进 super.doIntercept()方法。能够看到这里是跟进到了 com.opensymphony.xwork2.interceptor.ParametersInterceptor#doIntercept方法，它会重新处理一遍参数，这就导致上面的黑名单完全没生效。

跟进 setParameters()方法后其实就是 S2 处理 OGNL 语句的那一套，参考 https://drun1baby.top/2022/10/27/Java-Struts2-%E7%B3%BB%E5%88%97-S2-001/#%E6%B5%81%E7%A8%8B%E5%88%86%E6%9E%90

总的来说, 因为 SafeParametersInterceptor.doIntercept()方法的一些逻辑问题, 导致这个类自身对传入参数的过滤并没有生效, 我们最终还是可以通过 a.b.c=e的形式去调用当前 action 的 getter / setter, 并不需要关心方法本身或者它的 returnType 是否使用了 @ParameterSafe注解

到这里思路就很清晰了，我们只需要构造 OGNL 即可，调用某个 Action 里的 setter，让 isSetupComplete=false即可

以 ServerInfoAction 为例, 它继承自 ConfluenceActionSupport

这里的 getBootstrapStatusProvider()方法调用了 BootstrapStatusProviderImpl.getInstance()，接下来就可以去 BootstrapStatusProviderImpl里面寻找调用链，可惜的是这里的 setSetupComplete()已经用不了了，只能找另外的

最终找到的是 getApplicationConfig()方法，而在 ApplicationConfig类里面存在 setSetupComplete()方法可用

因为 Confluence 的所有 Action 都继承自 ConfluenceActionSupport, 所以理论上只要访问任意一个使用了 SafeParameterInterceptor 的路由, 无论是 GET 还是 POST 方法都能够利用成功

于是最后的 PoC 应该是

http://192.168.80.137:8090/server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=false

在进行覆盖 setupComplete=false之后重新注册管理员

http://192.168.80.137:8090/setup/setupadministrator-start.action

0x05 未授权之后的 RCE

X1r0z 师傅已经介绍了一种 RCE 的方法，但是利用条件有限，需要 web目录可写并且高权限用户

其实有一种更简单的方法，看到：https://packetstormsecurity.com/files/175225/Atlassian-Confluence-Unauthenticated-Remote-Code-Execution.html

可以通过上传插件实现 RCE，利用工具github上已经存在了：https://github.com/AIex-3/confluence-hack/

http://192.168.80.137:8090/plugins/servlet/upm

上传 plugin_shellplug.jar，访问 /plugins/servlet/com.jsos.shell/ShellServlet