使用 Burp Infiltrator 進行漏洞挖掘

01-30

在本文中，我將演示如何使用Burp Infiltrator來找到JetBrains公司產品TeamCity的通用型0day，TeamCity是Java編寫的一款針對專業開發人員和構建工程師的持續集成（CI）伺服器。在這一過程中Burp Infiltrator通過測試目標應用程序，注入代碼來跟蹤用戶輸入，最終幫助我使用經典的掃描技術找到了一枚通常情況下難以找到的漏洞。除此之外我還將分享一些使用Infiltrator的一些技巧，以使大家能夠獲得更多的收益。有關Infiltrator的基本介紹，請參閱Burp Infiltrator介紹。

實例解析

Infiltrator在注入代碼時發送一個pingback到Burp Collaborator，那麼只要Burp Scanner給Burp Collaborator提供數據，Burp Scanner就會觸發潛在的漏洞，例如運行系統命令或更改文件系統。這一點有助於找到可能被輸入轉換，輸入過濾或輸出缺失掩蓋的漏洞。同時它還揭示了應用程序遍歷的代碼路徑，以覆蓋到每個危險的API，這樣也會使漏洞更容易修補和利用。

首先，我開始通過使用Collaborator ID來對需要進行滲透的應用程序進行全面的清查，禁用除了外部服務交互的每個掃描檢查，並且啟用實時主動掃描和瀏覽來作為普通用戶。

在瀏覽了一段時間之後，我注意到，在一些頁面上有一些相同的模式的交互。這些交互顯示應用程序正在從用戶輸入創建一個位元組數組，然後將其傳遞給FileInputStream.read方法。該方法由org.eclipse.jgit包中的類調用，而該包是TeamCity的Git插件的依賴項。

我從與存儲庫URL創建新項目相關的頁面獲得了這些交互，這意味著URL可能被寫入文件系統。雖然我不知道這些內容是寫在哪裡，但我知道位元組數組的確切內容。請參閱以下截圖：

這是一個有趣的參數值：某些基於屬性的文件是用用戶提供的數據構建的。解碼後實際的字元串看起來像這樣：

我馬上認識到這是一個Git倉庫文件配置。這個文件格式很簡單：

1、一部分被表示為[sectionName]，每個部分都有一組屬性，這些屬性使用propertyName = value格式設置。

2、分號或散列後的所有字元串都將被視為注釋。

3、反斜杠轉義特殊字元。

4、通過在行的末尾添加反斜杠來支持多行屬性值。

我的目標是轉義teamcity部分，並在核心部分設置屬性。首先我會使用Collaborator客戶端來生成一系列用於我的payload的交互ID。因此，每次轉義遠程屬性的嘗試都會產生Infiltrator與文件內容的交互。此設置提供了一個方便的反饋循環，允許一個輸入值在由多層代碼轉換後確定輸入值的影響。

在使用這種方法一段時間後，我意識到我想出的所有URL都可以被正確轉義，雖然我可以使用0x0a字元輸入換行符，但它仍然在遠程屬性的上下文中。此外，某些位元組會使org.apache.commons.httpclient.HttpMethodBase類引發異常，因為這些異常在URL中是非法的。

經過幾次嘗試後，我改進了我的payload，最後得出以下的POC：

生成以下文件：

對上面的payload進行解析，我們可以得到這些信息：％23（＃）字元使HttpClient不會出現異常，因為URL片段中的所有內容都被忽略。％0d（CR）字元將插入符號返回到行的開頭，使得能夠有效的寫入原始屬性之上。分號從原始內容中注釋其中的剩餘部分，並在解碼％0a（LF）之後，轉義TeamCity添加的反斜杠。

這是一個簡單的語句，允許我們轉義當前屬性並將任意數據寫入屬性層次結構的頂層。設置這些屬性中的一些屬性的影響是巨大的，這可能導致從代碼執行到在代碼庫（代表合法的開發人員）中插入後門到迫使開發人員將任意代碼提取到其機器上。

事實上，有幾十個可以添加的屬性可能會導致遠程代碼執行，比如core.sshCommand，core.editor，gpg.program等等。其他屬性允許攻擊者設置存儲庫特定的代理，更改簽名的檢查方式，設置載入git鉤子的位置等等。

以上是使用Burp Infiltrator發現錯誤並為其編寫POC的示例。但這只是冰山一角，用Collaborator的URL去對需要進行滲透的應用程序進行全面的了解可以產生非常有趣的結果，如：

1、非同步滲透者事件。

2、從輸入轉換中獲取的SMTP協作者事件被報告為滲透者交互。

3、將由相同API生成的多個Infiltrator交互的看似無關的插入點相關聯

4、互動指向從不同插入點到達同一個易受攻擊代碼路徑的多種方式。

滲透應用程序是一個迭代過程; 選擇正確的目標路徑取決於您要獲得的交互量。理想情況下，我們只對應用程序的位元組碼及其依賴關係感興趣。這是因為應用程序可能不會自動實例化XML解析器，但它可能會使用庫來處理XML解析。如果是這種情況，我們不會滲透XML依賴關係，即使Scanner可靠地檢測到XML漏洞，我們也不會看到這些Infiltrator交互。

相反，如果我們盲目滲透一切，我們可能會產生誤導性的互動。例如，當Web伺服器接收到請求時，它將使用其路徑來確定哪個應用程序應該發送此請求。以下屏幕截圖顯示了一個示例：

看起來有一個文件遍歷問題，但是調用堆棧顯示沒有執行org.eclipse.jetty包以外的代碼。這種交互顯然不是來自應用程序，而是來自Web伺服器本身。

使用Collaborator ID全面了解您的目標應用程序，等待Infiltrator交互到達並相應地調整您的目標路徑。

還有一個重要的是決定是——什麼時候滲透您的目標應用程序是最為正確的時間。一般來說，我們要修補與用戶功能相關的每個類。大多數應用程序在首次部署之前可能會滲透，但有一些情況可能不是這種情況。

比如，有一個例子就是通過插件的可擴展性來進行的。插件在運行時會拓寬應用程序的攻擊面，在這種情況下，最好先安裝要測試的所有插件，將這些插件的位置添加到目標路徑列表中，並重新部署滲透的應用程序。

JSP頁面是一個值得提及的特殊情況。簡而言之，JSP代碼被轉換成servlet，而這些代碼又被編譯成Java位元組碼。JSP的大多數實現都是按需實現的，即：JSP只有在客戶端請求之後才能被編譯。這意味著Infiltrator不會調用JSP文件，因為它們最初不是Java位元組碼。然而，用戶可以通過多種方式解決這個問題。例如，通過在部署應用程序之前手動觸發JSP預編譯，這將生成所需的位元組碼。

可能出現的問題

如果您看到奇怪的行為或者您的應用程序在滲透後無法啟動，請注意Web伺服器日誌（或應用程序日誌記錄工具）中的異常。現代應用程序通常會出現一些異常，因此如果您認為有問題，您可以對以下類型進行過濾：

java.lang.ClassFormatErrornjava.lang.VerifyErrornjava.lang.NoClassDefFoundErrornjava.lang.StackOverflowErrorn

這四種類型的例外是一些很好的指標，一些類別或檔案館正在進行修補過程破壞的假設。另外，我們也非常希望您能夠將您所遇到的問題提交一份報告，因為您的反饋有助於改善滲透人員們的體驗！

本文翻譯自http://blog.portswigger.net/2017/06/behind-enemy-lines-bug-hunting-with.html，如若轉載，請註明原文地址：使用 Burp Infiltrator 進行漏洞挖掘更多內容請關注「嘶吼專業版」——Pro4hou