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，进行动调
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 callsgetFormData().setName("Charles")by the XWork parameters interceptor. IfgetFormData()returns null, XWork will attempt to create a new object of the appropriate return type using its default constructor, and then set it withsetFormData(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
0x06 Ref
http://www.bmth666.cn/2023/11/05/CVE-2023-22515-Confluence-Broken-Authentication/ https://exp10it.cn/2023/10/atlassian-confluence-cve-2023-22515-%E5%88%86%E6%9E%90/
原创稿件征集
征集原创技术文章中，欢迎投递
投稿邮箱：edu@antvsion.com
文章类型：黑客极客技术、信息安全热点安全研究分析等安全相关
通过审核并发布能收获200-800元不等的稿酬。
更多详情，点我查看！
参与靶场实战，戳"阅读原文"
