作者：Longofo@知道創宇404實驗室
時間：2020年4月8日
Nexus Repository Manager 3最近曝出兩個el表示式解析漏洞，編號為CVE-2020-10199［1］，CVE-2020-10204［2］，都是由Github Secutiry Lab團隊的@pwntester發現。由於之前Nexus3的漏洞沒有去跟蹤，所以當時diff得很頭疼，並且Nexus3 bug與安全修復都是混在一起，更不容易猜到哪個可能是漏洞位置了。後面與@r00t4dm師傅一起復現出了CVE-2020-10204［3］，CVE-2020-10204［4］是CVE-2018-16621［5］的繞過，之後又有師傅弄出了CVE-2020-10199［6］，這三個漏洞的根源是一樣的，其實並不止這三處，官方可能已經修復了好幾處這樣的漏洞，由於歷史不太好追溯回去，所以加了可能，通過後面的分析，就能看到了。還有之前的CVE-2019-7238［7］，這是一個jexl表示式解析，一併在這裡分析下，以及對它的修復問題，之前看到有的分析文章說這個漏洞是加了個許可權來修復，可能那時是真的只加了個許可權吧，不過我測試用的較新的版本，加了許可權貌似也沒用，在Nexus3高版本已經使用了jexl白名單的沙箱。
1
測試環境
文中會用到三個Nexus3環境：
nexus-3。14。0-04
nexus-3。21。1-01
nexus-3。21。2-03
用於測試jexl表示式解析，用於測試jexl表示式解析與el表示式解析以及diff，用於測試el表示式解析以及diff。
2
漏洞diff
CVE-2020-10199、CVE-2020-10204漏洞的修復界限是3。21。1與3。21。2，但是github開源的程式碼分支好像不對應，所以只得去下載壓縮包來對比了。在官方下載了與，但是beyond對比需要目錄名一樣，檔名一樣，而不同版本的程式碼有的檔案與檔名都不一樣。我是先分別反編譯了對應目錄下的所有jar包，然後用指令碼將中所有的檔案與檔名中含有3。21。1-01的替換為了3。21。2-03，同時刪除了META資料夾，這個資料夾對漏洞diff沒什麼用並且影響diff分析，所以都刪除了，下面是處理後的效果：
如果沒有除錯和熟悉之前的Nexus3漏洞，直接去看diff可能會看得很頭疼，沒有目標的diff。
3
路由以及應對處理類
1
一般路由
抓下nexus3發的包，隨意的點點點，可以看到大多數請求都是POST型別的，URI都是：
post內容如下：
可以看下其他請求，json中都有與這兩個key，在程式碼中搜索下這個關鍵字：
可以看到這樣的地方，展開看下程式碼：
透過註解方式注入了action，上面post的也在中，透過註解注入了對應的method：
所以之後這樣的請求，我們就很好定位路由與對應的處理類了。
2
API路由
Nexus3的API也出現了漏洞，來看下怎麼定位API的路由，在後臺能看到Nexus3提供的所有API。
點幾個看下包，有GET、POST、DELETE、PUT等型別的請求：
沒有了之前的action與method，這裡用URI來定位，直接搜尋定位不到，所以縮短關鍵字，用來定位：
透過@Path註解來注入URI，對應的處理方式也使用了對應的@GET、@POST來註解
可能還有其他型別的路由，不過也可以使用上面類似的方式進行搜尋來定位。還有Nexus的許可權問題，可以看到上面有的請求透過@RequiresPermissions來設定了許可權，不過還是以實際的測試許可權為準，有的在到達之前也進行了許可權校驗，有的操作雖然在web頁面的admin頁面，不過本不需要admin許可權，可能無許可權或者只需要普通許可權。
4
build Constraint Violation With Template造成的幾次Java EL 漏洞
在跟蹤除錯了CVE-2018-16621［8］與CVE-2020-10204［9］之後，感覺這個keyword可以作為這個漏洞的根源，因為從呼叫棧可以看出這個函式的呼叫處於Nexus包與hibernate-validator包的分界，並且計算器的彈出也是在它之後進入hibernate-validator的處理流程，即，最終在hibernate-validator包中的ElTermResolver中透過完成了表示式的執行，與@r00t4dm師傅也說到了這個：
於是反編譯了Nexus3所有jar包，然後搜尋這個關鍵詞（使用的修復版本搜尋，主要是看有沒有遺漏的地方沒修復；Nexue3有開源部分程式碼，也可以直接在原始碼搜尋）：
後面作者也釋出了漏洞分析［10］，確實用了作為了漏洞的根源，利用這個關鍵點做的汙點跟蹤分析。
從上面的搜尋結果中可以看到，el表示式導致的那三個CVE關鍵點也在其中，同時還有其他幾個地方，有幾個使用了做了清除，還有幾個，看起來似乎也可以，心裡一陣狂喜？然而，其他幾個沒有做清除的地方雖然能透過路由進入，但是利用不了，後面會挑選其中的一個做下分析。所以在開始說了官方可能修復了幾個類似的地方，猜想有兩種可能：
官方自己察覺到了那幾個地方也會存在el解析漏洞，所以做了清除 有其他漏洞發現者提交了那幾個做了清除的漏洞點，因為那幾個地方可以利用；但是沒清除的那幾個地方由於沒法利用，所以發現者並沒有提交，官方也沒有去做清除。
不過感覺後一種可能性更大，畢竟官方不太可能有的地方做清除，有的地方不做清除，要做也是一起做清除工作。
1
CVE-2018-16621分析
這個漏洞對應上面的搜尋結果是RolesExistValidator，既然搜尋到了關鍵點，自己來手動逆向回溯下看能不能回溯到有路由處理的地方，這裡用簡單的搜尋回溯下。
關鍵點在，呼叫了。搜尋下有沒有呼叫的地方：
在RolesExist中有呼叫，這種寫法一般會把RolesExist當作註解來使用，並且進行校驗時會呼叫。繼續搜尋RolesExist：
有好幾處直接使用了RolesExist對roles屬性進行註解，可以一個一個去回溯，不過按照Role這個關鍵字RoleXO可能性更大，所以先看這個（UserXO也可以的），繼續搜尋RoleXO：
會有很多其他干擾的，比如第一個紅色標註，這種可以忽略，我們找直接使用地方。在中，看到第二個紅色標註這種註解大概就知道，這裡能進入路由了。第三個紅色標註使用了roleXO，並且有roles關鍵字，上面RolesExist也是對roles進行註解的，所以這裡猜測是對roleXO進行屬性注入。有的地方反編譯出來的程式碼不好理解，可以結合原始碼看：
可以看到這裡就是將提交的引數注入給了roleXO，RoleComponent對應的路由如下：
透過上面的分析，我們大概知道了能進入到最終的，不過中間可能還有很多條件需要滿足，需要構造payload然後一步一步測。這個路由對應的web頁面位置如下：
測試（這裡使用的3。21。1版本，CVE-2018-16621是之前的漏洞，在3。21。1早修復了，不過3。21。1又被繞過了，所以下面使用的是繞過的情況，將換成去繞過，繞過在後面兩個CVE再說）：
修復方式：
加上了對el表示式做了清除，將替換為了，之後的兩個CVE就是對這個修復方式的繞過：
2
CVE-2020-1024分析
這就是上面說到的對之前修復的繞過，這裡就不細分析了，利用格式就不會被替換掉（使用3。21。1版本測試）：
3
CVE-2020-10199分析
這個漏洞對應上面搜尋結果是：
（標號1）出現在了（標號2）的中，又被註解在（標號3、4）之上，註解在了（標號5）之上，在方法中使用到了（標號6、7）。按照這個思路要找呼叫了的地方。
也來手動逆向回溯下看能不能回溯到有路由處理的地方。
搜尋ConstraintViolationFactory：
有好幾個，這裡使用第一個分析，點進去看就能看出它是一個API路由：
被傳遞給了，在並沒有呼叫的其他函式，不過它的兩個方法，也是呼叫了對應的方法。它的是類：
建構函式中呼叫的，在e賦值了（標號1），的使用（標號2），呼叫了（在後面可以看到memberNames引數），這也是之前要到達漏洞點所需要的，這個呼叫處於中（標號3），的呼叫在（標號4）和（標號5）中都進行了呼叫，而這兩個方法透過上面的註解也可以看出，透過外部傳遞請求能到達。
的路由為，在後臺API找到它來進行呼叫（使用3。21。1測試）：
還有的其他幾個子類也是可以的：
4
CleanupPolicyAssetNamePatternValidator未做清除點分析
對應上面搜尋結果的，可以看到這裡並沒有做清除操作：
這個變數是透過報錯丟擲放到中的，要是報錯資訊中包含了value值，那麼這裡就是可以利用的。
搜尋：
在類註解中使用了，繼續搜尋：
在a中的屬性被註解了，繼續搜尋：
在中的方法中有呼叫，其中的也正好是物件。y在的可透過路由進入的方法又呼叫了。
構造payload測試：
然而這裡並不能利用，value值不會被包含在報錯資訊中，去看了下，無論如何構造，最終也只會丟擲value中的一個字元，所以這裡並不能利用。
與這個類似的是，那裡也是透過丟擲異常，但是那裡是可以利用的，不過被修復了，可能之前已經有人提交過了。還有其他幾個沒做清除的地方，要麼被if、else跳過了，要麼不能利用。
人工去回溯查詢的方式，如果關鍵字被呼叫的地方不多可能還好，不過要是被大量使用，可能就不是那麼好處理了。不過上面幾個漏洞，可以看到透過手動回溯查詢還是可行的。
5
JXEL造成的漏洞（CVE-2019-7238）
可以參考下@iswin大佬之前的分析https：//www。anquanke。com/post/id/171116，這裡就不再去除錯截圖了。這裡想寫下之前對這個漏洞的修復，說是加了許可權來修復，要是隻加了許可權，那不是還能提交一下？不過，測試了下3。21。1版本，就算用admin許可權也無法利用了，想去看下是不是能繞過。在3。14。0中測試，確實是可以的：
但是3。21。1中，就算加了許可權，也是不行的。後面分別除錯對比了下，以及透過下面這個測試：
才知道3。14。0與上面這個測試使用的是處理，它的getMethod方法如下：
而在3。21。1中Nexus設定的是，這個，它的get Method方法如下：
可以看出只允許呼叫String、Map、Collection型別的有限幾個方法了。
6
總結
看完上面的內容，相信對Nexus3的漏洞大體有了解了，不會再無從下手的感覺。嘗試看下下其他地方，例如後臺有個LDAP，可進行jndi connect操作，不過那裡呼叫的是，雖然會遠端請求class檔案，不過並不會載入class，所以並沒有危害。
有的漏洞的根源點可能會在一個應用中出現相似的地方，就像上面那個buildConstraintViolationWithTemplate這個keyword一樣，運氣好說不定一個簡單的搜尋都能碰到一些相似漏洞（不過我運氣貌似差了點，透過上面的搜尋可以看到某些地方的修復，說明已經有人先行一步了，直接呼叫了buildConstraintViolationWithTemplate並且可用的地方似乎已經沒有了）
仔細看下上面幾個漏洞的payload，好像相似度很高，所以可以弄個類似fuzz引數的工具，蒐集這個應用的歷史漏洞payload，每個引數都可以測試下對應的payload，運氣好可能會撞到一些相似漏洞。
References
https：//support。sonatype。com/hc/en-us/articles/360044882533
https：//support。sonatype。com/hc/en-us/articles/360044356194-CVE-2020-10204-Nexus-Repository-Manager-3-Remote-Code-Execution-2020-03-31
https：//support。sonatype。com/hc/en-us/articles/360044356194-CVE-2020-10204-Nexus-Repository-Manager-3-Remote-Code-Execution-2020-03-31
https：//support。sonatype。com/hc/en-us/articles/360044356194-CVE-2020-10204-Nexus-Repository-Manager-3-Remote-Code-Execution-2020-03-31
https：//support。sonatype。com/hc/en-us/articles/360010789153-CVE-2018-16621-Nexus-Repository-Manager-Java-Injection-October-17-2018
https：//support。sonatype。com/hc/en-us/articles/360044882533
https：//support。sonatype。com/hc/en-us/articles/360017310793-CVE-2019-7238-Nexus-Repository-Manager-3-Missing-Access-Controls-and-Remote-Code-Execution-2019-02-05
https：//support。sonatype。com/hc/en-us/articles/360010789153-CVE-2018-16621-Nexus-Repository-Manager-Java-Injection-October-17-2018
https：//support。sonatype。com/hc/en-us/articles/360044356194-CVE-2020-10204-Nexus-Repository-Manager-3-Remote-Code-Execution-2020-03-31
https：//github。com/Cryin/Paper/blob/master/CVE-2018-16621%20Nexus%20Repository%20Manager3%20%E4%BB%BB%E6%84%8FEL%E8%A1%A8%E8%BE%BE%E5%BC%8F%E6%B3%A8%E5%85%A5。md
往 期 熱 門
覺得不錯點個“在看”哦