*本文中涉及到的相關(guān)漏洞已報送廠商并得到修復(fù)，本文僅限技術(shù)研究與討論，嚴(yán)禁用于非法用途，否則產(chǎn)生的一切后果自行承擔(dān)。

介紹

這篇文章將從一個Apache tika服務(wù)器的命令注入漏洞到完全利用的步驟。CVE是https://nvd.nist.gov/vuln/detail/CVE-2018-1335。由于Apache Tika是開源的，我能夠通過分析Apache Tika代碼來確定問題。雖然命令注入漏洞通常很簡單，但要實現(xiàn)完整的遠(yuǎn)程代碼或命令執(zhí)行需要克服一些障礙。這是由于Java處理執(zhí)行操作系統(tǒng)命令的方式以及Apache Tika代碼本身的一些特性。但在最后，我們?nèi)匀豢梢允褂肅script.exe來執(zhí)行操作。

什么是Apache TikaApache Tika?工具包可從超過一千種不同的文件類型(如PPT，XLS和PDF)中檢測和提取元數(shù)據(jù)和文本。所有這些文件類型都可以通過一個接口進行解析，使得Tika對搜索引擎索引，內(nèi)容分析，翻譯等非常有用。(https://tika.apache.org/)

Apache Tika有幾個不同的組件：Java庫，命令行工具和自帶REST API的獨立服務(wù)器(tika-server)。此攻擊特別針對獨立服務(wù)器，它通過REST API公開https://wiki.apache.org/tika/TikaJAXRS。樣本可在https://archive.apache.org/dist/tika/tika-server-1.17.jar找到。

Breaking Down The CVE

我們首先需要閱讀issue，看看可以從中獲取哪些信息。

原始描述：在Tika 1.18之前，客戶端可以將精心設(shè)計的標(biāo)頭發(fā)送到tika-server，該標(biāo)頭可用于將命令注入運行tika-server的服務(wù)器的命令行。此漏洞僅影響在對不受信任的客戶端開放的服務(wù)器上運行tika-server的漏洞。

我們可以從這個描述中看到的事情：1.版本1.18已修補；

2.版本1.17未修補；

3.該漏洞是命令注入；

4.漏洞的入口點是“headers”；

5.這會影響代碼的tika-server部分。

有了這些信息，我們現(xiàn)在有了一個識別漏洞的起點。下一步將看看Tika補丁和未補丁版本的差異，特別是tika-server部分。為Java中已知的執(zhí)行操作系統(tǒng)命令的函數(shù)編寫Grepping代碼是另一個不錯的選擇。最后，搜索tika-server代碼的各個部分，我們可以假設(shè)這些報頭是某種HTTP請求。

0x01

對tika-server 1.17與1.18源目錄進行并行遞歸比較。只返回一個已修改的文件，如下部分。

由于目標(biāo)是在頭字段中找到命令注入，所以第一個結(jié)果是一個代碼塊，這個代碼塊已經(jīng)添加到補丁版本“ALLOWABLE_HEADER_CHARS”中。這是一個非常好的開始,假設(shè)這是補丁試圖過濾可用于將命令注入頭字段的字符。

繼續(xù)向下是一個名為“processHeaderConfig”的函數(shù)內(nèi)部的代碼，它已在1.18中刪除。它使用一些變量來動態(tài)創(chuàng)建一個方法，該方法似乎設(shè)置了某個對象的屬性，并使用HTTP頭來執(zhí)行此操作。

以下是此功能的說明：

截圖顯示了不同屬性的前綴，并在此代碼的開頭定義為靜態(tài)字符串。

因此，我們有一些靜態(tài)字符串可以作為HTTP頭文件包含在請求中，并用于設(shè)置對象的某些屬性。最終header的示例看起來像“X-Tika-OCRsomeproperty：somevalue”，然后將“someproperty”轉(zhuǎn)換為類似于“setSomeproperty()”的函數(shù)，并將somevalue作為要設(shè)置的值傳遞給該函數(shù)。

可以看到這里正在使用這個函數(shù)，并且在請求中檢查了前綴頭以確定如何調(diào)用該函數(shù)。然后，所有需要的參數(shù)都從HTTP請求傳遞到“processHeaderConfig”函數(shù)。

查看使用“processHeaderConfig”函數(shù)的方式，可以看到正在“TesseractOCRConfig”對象上設(shè)置屬性。搜索可能使用我們發(fā)現(xiàn)的“TesseractOCRConfig”對象的地方：tika-parsers/src/main/java/org/apache/tika/parser/ocr/TesseractOCRParser.java。

這是來自“TesseractOCRParser.java”的“doOCR”函數(shù)，它將配置屬性從我們剛剛發(fā)現(xiàn)的“TesseractOCRConfig”對象直接傳遞到一個字符串?dāng)?shù)組中，這些字符串用于構(gòu)造“ProcessBuilder”的命令，然后該過程已開始。

這看起來很有希望,如果我們將所有信息放在一起，我們應(yīng)該能夠向服務(wù)器發(fā)出某種HTTP請求，設(shè)置一個看起來像“X-Tika-OCRTesseractPath：”的標(biāo)題。并將此命令插入cmd字符串并執(zhí)行。唯一的問題是“config.getTesseractPath()”前綴為另一個我們無法控制的字符“getTesseractProg()”，最終是一個靜態(tài)字符串“tesseract.exe”。為了解決這個問題，我們可以用雙引號包裝我們想要執(zhí)行的命令，Windows將忽略引號后附加的任何內(nèi)容，只執(zhí)行我們的注入的命令。

為了進行測試，我們可以使用tika-server文檔中的示例來檢索有關(guān)文件的一些元數(shù)據(jù)。

由于OCR用于從圖像中提取文本和內(nèi)容，我們將上傳圖像而不是docx，以期有望達(dá)到“doOCR”功能。

我們最終得到：curl -T test.tiff http://localhost:9998/meta --header "X-Tika-OCRTesseractPath: \"calc.exe\""

在上傳圖像時，通過在PUT請求中將一個命令用雙引號括起來作為“X-Tika-OCRTesseractPath”HTTP頭的值來標(biāo)識命令注入。

0x02 不僅僅是彈個計算器

我們直接更改正在執(zhí)行的應(yīng)用程序名稱。由于該命令作為數(shù)組傳遞給Java ProcessBuilder，因此我們實際上不能運行多個命令，也不能將參數(shù)作為單個字符串添加到命令中，否則執(zhí)行將失敗。這是因為將一組字符串傳遞給Java中的進程構(gòu)建器或runtime.exec的工作方式如下：

通常像cmd.exe或/bin/sh這樣的shell解釋的字符(例如＆，，|，`等)不會被ProcessBuilder解釋并且將被忽略，因此您不能中斷命令或添加任何將它作為單個字符串的參數(shù)。不像“X-Tika-OCRTesseractPath: \“cmd.exe /c some args\”這樣簡單。

回到“cmd”數(shù)組的構(gòu)造，您可以看到我們也控制了命令中的多個參數(shù)，這是每個看起來像“config.get*()”的項，但是它被一些我們不控制的其他項分割開了。

我的第一個想法是運行“cmd.exe”，然后將參數(shù)“/c”作為“config.getLanguage()”傳入，然后將“|| somecommand ||”作為“config.getPageSegMode()”插入，這雖然可以執(zhí)行“somecommand”。但是在調(diào)用｀“doOCR”｀之前，還有另一個函數(shù)在｀“config.getTesseractPath()”｀字符串上調(diào)用，該字符串只執(zhí)行該命令(目的是檢查是否被調(diào)用的應(yīng)用程序是有效的應(yīng)用程序)。這里的問題是只運行沒有參數(shù)的“cmd.exe”并一直掛起，因為“cmd.exe”永遠(yuǎn)不會退出并讓執(zhí)行繼續(xù)執(zhí)行“doOCR”功能。

0x03 解決方案

除了運行單個命令外，我們可以更深入地了解“doOCR”函數(shù)使用Process Monitor啟動進程時會發(fā)生什么。 查看進程的屬性，當(dāng)tika-server啟動它時，會生成以下命令行，該命令行是使用inject命令構(gòu)造的。"calc.exe"tesseract.exe C:\Users\Test\AppData\Local\Temp\apache-tika-3299124493942985299.tmp C:\Users\Test\AppData\Local\Temp\apache-tika-7317860646082338953.tmp -l eng -psm 1 txt -c preserve_interword_spaces=0

我們控制的命令部分以紅色突出顯示。我們可以在命令中注入3個地方，1個命令和2個參數(shù)。另一個有趣的發(fā)現(xiàn)是Tika實際上創(chuàng)建了2個臨時文件，其中一個作為第一個參數(shù)被傳遞。

經(jīng)過一些進一步的調(diào)查后，我能夠確認(rèn)傳遞給命令的第一個臨時文件是我上傳的文件中的內(nèi)容。這意味著我可以用一些代碼或命令填充該文件并執(zhí)行它。

現(xiàn)在我必須找到一個原生的Windows應(yīng)用程序，它將忽略tika-server創(chuàng)建的所有隨機雜散參數(shù)，并仍然執(zhí)行第一個文件內(nèi)容作為某種命令或代碼，即使它具有“.tmp”擴展名。找到一些可以做到這一切的事情起初對我來說聽起來不太可能。最后我發(fā)現(xiàn)了Cscript.exe，它看起來有點希望。我們來看看Cscript可以做些什么。

Cscript正是我們所需要的。它將第一個參數(shù)作為腳本，并允許您使用"//E:engine"標(biāo)志來指定要使用的腳本引擎(可能是Jscript或VBS)，因此文件擴展名無關(guān)緊要。將它放入新命令現(xiàn)在看起來如下所示。"cscript.exe"tesseract.exe C:\Users\Test\AppData\Local\Temp\apache-tika-3299124493942985299.tmp C:\Users\Test\AppData\Local\Temp\apache-tika-7317860646082338953.tmp -l //E:Jscript -psm 1 txt -c preserve_interword_spaces=0

這可以通過設(shè)置以下HTTP標(biāo)頭來完成：X-Tika-OCRTesseractPath: "cscript.exe"X-Tika-OCRLanguage: //E:Jscript

將上傳的“image”文件將包含一些Jscript或VBS：var oShell = WScript.CreateObject("WScript.Shell");var oExec = oShell.Exec('cmd /c calc.exe');

首先，上傳失敗，因為它不是有效圖片，無法驗證圖像的魔術(shù)字節(jié)。然后我發(fā)現(xiàn)將內(nèi)容類型設(shè)置為“image/jp2”迫使Tika不檢查圖像中的魔術(shù)字節(jié)，但仍然通過OCR處理圖像。這允許上載包含Jscript的圖像。

最后，將所有這些放在一起，我們有完整的command/jscript/vbs腳本。

結(jié)論

雖然這是一個簡單的命令注入，但為了利用，還是需要嘗試各種方法的。Apache不建議在不受信任的環(huán)境中運行Tika服務(wù)器或?qū)⑵浔┞督o不受信任的用戶。此錯誤也已修補，當(dāng)前版本為1.20，因此如果您使用此服務(wù)，請確保更新。

*參考來源：rhinosecuritylabs，FB小編周大濤編譯，轉(zhuǎn)載請注明來自FreeBuf.COM

總結(jié)

以上是生活随笔為你收集整理的java 漏洞挖掘_Apache Tika命令注入漏洞挖掘的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。