Confluence 未授權漏洞分析（CVE-2023-22515）

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，備註 “博客園” 獲取！】

　① 網安學習成長路徑思維導圖
　② 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=Charles will 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

更多網安技能的在線實操練習，請點擊這裏>>