作者：云鼎實驗室
原文鏈接：https://mp.weixin.qq.com/s/GRtDqr45x-tNnoR2Qi5ISg

一、背景

漏洞概述：

WebLogic是美國Oracle公司的主要產品之一，是商業市場上主要的 J2EE 應用服務器軟件，也是世界上第一個成功商業化的J2EE應用服務器，在 Java 應用服務器中有非常廣泛的部署和應用。

10月21日，Oracle官方發布數百個組件的高危漏洞公告。其中組合利用CVE-2020-14882/ CVE-2020-14883可使未經授權的攻擊者繞過WebLogic后臺登錄等限制，最終遠程執行代碼接管WebLogic服務器，利用難度極低，風險極大。

此處漏洞均存在于WebLogic的控制臺中。該組件為WebLogic全版本自帶組件，并且該漏洞通過HTTP協議進行利用，CVE-2020-14882漏洞允許未授權的用戶繞過管理控制臺的權限驗證訪問后臺，CVE-2020-14883允許后臺任意用戶通過HTTP協議執行任意命令。

漏洞編號：

CVE-2020-14882、CVE-2020-14883

漏洞等級：

高危，CVSS評分9.8

受影響的版本：

10.3.6.0.0、12.1.3.0.0、12.2.1.3.0、12.2.1.4.0、14.1.1.0.0

二、復現

復現環境

本次測試是用的weblogic 10.3.6.0及weblogic12.2.1.3.0，weblogic12.2.1.4.0

權限繞過漏洞（CVE-2020-14882）復現：

在正常訪問console后臺時會提示輸入帳號密碼

對于其他路徑也限制了訪問，可以看到返回403

通過未授權訪問，則可以繞過驗證直接訪問后臺。

可看到通過未授權訪問的后臺與正常登陸的后臺相比，由于權限不足，缺少部署等功能，無法安裝應用，所以也無法通過部署項目等方式直接獲取權限。

‘%252E%252E%252F’即為二次URL編碼過后的‘../’，通過這個就可以實現穿越路徑未授權訪問相關管理后臺

任意代碼執行復現

利用上述未授權訪問CVE-2020-14882結合CVE-2020-14883

利用方式（一）：

通過：

com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext，這種方法最早在CVE-2019-2725被提出，該方法通用于各版本weblogic。

這里首先需要我們構造一個惡意的xml文件，如這里我們自己本地搭建的http://10.211.55.2:9999/rce-win.xml。

其次需要被攻擊的weblogic能夠訪問我們的惡意xml。

其他gadget：

com.bea.core.repackaged.springframework.context.support.ClassPathXmlApplicationContext

利用方式（二）：

通過com.tangosol.coherence.mvel2.sh.ShellSession，但此利用方法只能在Weblogic 12.2.1及以上版本利用，因為10.3.6并不存在com.tangosol.coherence.mvel2.sh.ShellSession類。

我們可以看到在當前10.3.6版本會提示

當使用12版本測試時，即可測試成功

其他exp：

比如回顯的

或者post形式：

調試分析

首先，通過靜態資源文件繞過路徑權限的校驗。之后weblogic會對提交的url進行兩次url解碼。最后會將handle中的參數傳入HandleFactory執行任意代碼。

從繞過路徑權限的校驗開始。首先weblogic的請求會經過weblogic.servlet.internal.WebAppServletContext#execute處理，這里會調用securedExecute()

跟進securedExecute，后會調用doSecuredExecute，繼續跟進

weblogic.servlet.internal.WebAppServletContext#doSecuredExecute 在這里調用checkAccess進行權限的檢查

進入weblogic.servlet.security.internal.WebAppSecurity#checkAccess()中可以看到當我們請求的路徑為/console/console.portal時，checkAllResources為false

這里跟進weblogic.servlet.security.internal.WebAppSecurityWLS#getConstraint()

這里即比較我們的relURI是否匹配我們matchMap中的路徑，并判斷rcForAllMethods和rcForOneMethod是否為null

當我們的relURI為/console.portal時，rcForAllMethods不為null，rcForOneMethod為null，所以返回了rcForAllMethods。而對應靜態資源就不會有限制和校驗

接下來回到checkAccess，如果這里是原來的/console.portal時，到這就結束了

如果使用console/images/console.portal則會繼續判斷resourceConstraint及后續的isAuthorized，并進入weblogic.servlet.security.internal.ChainedSecurityModule#checkAccess

在weblogic.servlet.security.internal.CertSecurityModule#checkUserPerm中會進入hasPermission校驗權限

所以當我們這里使用靜態資源路徑時，unrestrict值就為true

之后會根據web.xml中的配置對應的AsyncInitServlet來到了weblogic.servlet.AsyncInitServlet#service

這里如果解碼后的url里沒有“；”，那么就會繼續調用super.service

再次進入super.service()

最終不管哪種請求都會來到doPost，并在這里調用createUIContext

可以看到此時已經經過了一次解碼

隨后進入getTree又進行了一次解碼，此時requestPattern就變成/css/../console.portal

之后來到com.bea.console.utils.BreadcrumbBacking#init類，進入findFirstHandle

這里會逐個檢查參數中是否有handle并將handle的參數內容提取出來返回

最后將獲取到的handleStr作為參數調用HandleFactory.getHandle(handleStr);此時也就來到了代碼執行的入口

此時傳進來的handleStr會在這里被拆成兩部分，一個作為被實例化的類，另一個作為該類的構造函數參數及實例化，比如java.lang.String('aaaa')，被拆分成java.lang.String和aaaa

所以我們就可根據此來構造gadget，最終通過反射機制在此觸發

比如當我們構造了惡意gadget后就變成了這樣，隨后即可觸發rce

三、修復

目前Oracle官方已發布了最新針對該漏洞的補丁，請受影響用戶及時下載補丁程序并安裝更新。

Oracle官方補丁需要用戶持有正版軟件的許可賬號，使用該賬號登陸https://support.oracle.com后，可以下載最新補丁。

參考鏈接：https://www.oracle.com/security-alerts/cpuoct2020.html

在舊版補丁中，使用黑名單過濾，可使用大小寫繞過，請更新最新版的補丁，或者如無使用必要可選擇關閉console。

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1395/