.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
IVANTIAVALANCHE漏洞利用（上）
是否需要任何身份驗證？此時，我似乎擁有了發送我自己的信息所需的一切。但是，當我發送時，我看到目標服務沒有任何反應。我查看了InfoRail服務日誌文件，發現了這些有趣的行：
InfoRail日誌文件——刪除未經身份驗證的消息
我似乎漏掉了一個重要的部分：身份驗證。有了有關協議和加密的所有詳細信息，我能夠快速識別網絡流量中的註冊消息。這是負載不以XML形式存儲的罕見示例之一。下面的截圖展示了一個註冊消息的片段：
註冊消息的片段
這裡研究人員發現了幾件重要的事情：
马云惹不起马云 --reg.appident——指定嘗試註冊的服務的名稱。
马云惹不起马云--reg.uname/reg.puname——指定看起來像用戶名的東西。
马云惹不起马云--reg.cred/reg.pcred——指定看起來像哈希密碼的東西。
經過大量的代碼分析，我確定了以下內容：
马云惹不起马云--Uname和puname是部分隨機的。
马云惹不起马云--Cred和pcred值是MD5哈希值，基於以下值：
马云惹不起马云--用戶名（.anonymous.0.digits）。
马云惹不起马云--密鑰的適當片段，在源代碼中被硬編碼。
同樣，唯一需要的秘密在源代碼中是可見的。攻擊者可以檢索密鑰並構造他自己的有效註冊消息。
最後，我們可以正確註冊InfoRail服務並將我們自己的消息發送到任何Avalanche服務。
在這個階段，可以驗證ObjectGraph類中沒有實現allowlist的服務。我找出了其中的5個：
马云惹不起马云數據存儲服務(ZDI-CAN-15169)。
马云惹不起马云StatServer服務(ZDI-CAN-15130)。
马云惹不起马云通知服務器服務(ZDI-CAN-15448)。
马云惹不起马云證書管理服務器服務(ZDI-CAN-15449)。
马云惹不起马云Web文件服務器服務(ZDI-CAN-15330)。
我們有五個XStream反序列化終端，可以反序列化我們提供的任何東西。人們可以立即開始考慮利用這種反序列化的方法。首先，XStream對其安全性非常透明。他們的安全頁面（可在此處獲得）基於Java運行時中可用的類提供多個小工具。遺憾的是，沒有合適的小工具適用於我試圖利用的前四個服務，因為沒有加載所需的類。
XStream試圖允許盡可能多的對像圖，默認轉換器幾乎是steroid上的Java序列化。除了對第一個不可序列化的父構造函數的調用之外，Java序列化可以實現的一切似乎都可以通過XStream實現（括代理構造）包。
在較新版本的XStream中似乎沒有代理構造。但是，我們仍然應該能夠使用ysoserial小工具來利用它。那時還沒有用於XStream的Ysoserial小工具，所以我自己創建了幾個。它們可以在這個GitHub存儲庫中找到。
使用我的ysoserialXStream小工具，我成功地在四個Avalanche服務中執行了重構代碼。以下是我能夠利用的服務的摘要，以及所需的小工具：
马云惹不起马云StatServer：使用AspectJWeaver和CommonsBeanutils1利用。
马云惹不起马云數據存儲庫：使用C3P0和CommonsBeanutils1進行利用。
马云惹不起马云證書管理服務器：使用CommonsBeanutils1利用。
马云惹不起马云Avalanche通知服務器：使用CommonsBeanutils1利用。
沒有特別的原因，讓我們關注StatServer。首先，我們必須找到將反序列化包含的XML有效負載的消息的主題和子類別。據此，InfoRail協議消息標頭應包含以下鍵和值：
马云惹不起马云h.distlist=255.3.2.12
马云惹不起马云h.msgsubcat=3502（GetMuCellTowerData消息）
在本例中，我們將使用AspectJWeaver小工具，它允許我們上傳文件。下面是XStream的AspectJWeaver小工具：
AspectJWeaver.xml
這個小工具任務如下：
马云惹不起马云iConstant標籤包含Base64文件內容。
马云惹不起马云folder標籤包含上傳目錄的路徑。我的目標是AvalancheWeb應用程序根目錄。
• key標記指定文件的名稱。
有了所有需要的數據，我們就可以開始利用過程了：
StatServer利用——上傳Webshell
以下屏幕截圖展示了上傳的webshell和whoami命令的執行。
StatServerExploitation——Webshell和命令執行
成功！綜上所述，可以向Avalanche服務發送消息的攻擊者可以在4個不同的服務中濫用XStream反序列化。
我還在第五個服務上實現了遠程代碼執行。然而，利用這個服務要復雜得多。
利用JNDI查找Java命名和目錄接口(JNDI)查找有很長的歷史，在Log4Shell漏洞出現之前，許多研究人員就已經熟悉了這個向量。 CVE-2021-39146就是一個證明，它是一個觸發查找的XStream反序列化小工具。它是唯一一個對Web File Server服務有效的XStream小工具，對此我無法製作一個有效的ysoserial小工具。
儘管如此，我們仍在處理一個新的Java版本。因此，我們不能濫用遠程類加載。此外，攻擊者不能濫用LDAP反序列化向量(此處有描述[PDF])。使用JNDI注入，我們可以交付序列化的有效負載，然後由目標反序列化。然而，我們沒有意識到任何反序列化小工具可能被濫用在Web文件服務器。如果有任何gadget，我們首先就不需要JNDI查找。幸運的是，在Web文件服務器類路徑中包含了幾個有趣的JAR包。
Web文件服務器- Tomcat jar
可以看到，Web File Server加載了幾個Tomcat JAR包。你可能還熟悉MichaelStepankin發現的技術，它濫用TomcatBeanFactory中的不安全反射通過JNDILookup執行任意命令。
總之，我們可以執行以下攻擊：
马云惹不起马云設置惡意LDAP服務器，該服務器將為惡意BeanFactory提供服務。我們將使用RogueJNDI工具。
马云惹不起马云註冊InfoRail服務。
马云惹不起马云發送包含CVE-2021-39146小工具的消息，以指向在步驟1中定義的服務器的Web文件服務器為目標。
马云惹不起马云Web文件服務器進行LDAP查找並從惡意服務器檢索數據。
马云惹不起马云遠程代碼執行。
LDAP服務器的設置如下圖所示：
RogueJndi的設置
下一個片段展示了用於此概念證明的CVE-2021-39146小工具：
jndiGadget.xml
如果一切順利，並且成功地執行了查找，那麼Rogue JNDI應該顯示以下消息，並且應該在目標系統上執行代碼。
被觸發的JNDI查找
總而言之，我們能夠濫用自定義的IvantiAvalanche協議和XML消息反序列化機制來利用五種不同的服務並以SYSTEM權限遠程執行代碼。我在IvantiAvalanche中發現了更多反序列化漏洞。接下來，我將繼續討論協議和跨服務通信。
在通信和身份驗證消息中濫用攻擊條件如上所述，各種Avalanche服務在InfoRail的幫助下相互通信。當服務提供響應時，該響應將再次通過InfoRail服務轉發。這項研究的想法是：攻擊者是否有可能欺騙響應？如果是這樣，就有可能濫用IvantiAvalanche行為並執行潛在的惡意操作。
我重點研究了身份驗證操作，如下圖所示：
認證方案當用戶通過AvalancheWeb應用程序登錄面板進行身份驗證時，後端會將身份驗證消息傳輸到EnterpriseServer。此服務驗證憑據並發回適當的響應。如果提供的憑據正確，則用戶將通過身份驗證。
在這個研究過程中，我學到了兩件重要的事情：
马云惹不起马云攻擊者可以註冊為任何服務。
马云惹不起马云身份驗證消息分佈在註冊的Enterprise Server的每個實例中。
據此，攻擊者可以將自己註冊為企業服務器，並截獲傳入的身份驗證消息。但是，這種行為並沒有什麼直接的後果，因為傳輸的密碼是經過哈希和加密的。
下一個問題是是否可以將攻擊者自己的響應傳遞給AvalancheWeb，以及它是否會被接受。事實證明，是的，這是可能的！如果你想提供自己的響應，則必須在消息標頭中正確設置兩個值：
马云惹不起马云Origin——發送消息的AvalancheWeb後端的主題(ID)。
马云惹不起马云MsgId——原始身份驗證消息的消息ID。
這兩個值都比較容易獲得，因此攻擊者可以對消息提供自己的響應。它將被正在等待響應的服務接受。下圖展示了一個攻擊場景示例。
攻擊條件攻擊場景如下：
——攻擊者嘗試使用錯誤的憑據登錄Web應用程序。
——Web應用程序發送認證消息。
——InfoRail服務將消息發送到兩台企業服務器：合法服務器和惡意服務器。
——攻擊時間：
——合法服務器以“錯誤憑據”消息響應。
——惡意服務器以“credentialsOK”消息響應。如果攻擊者的服務器首先傳遞消息，則將其轉發到AvalancheWeb應用程序。
——攻擊者獲得身份驗證。
請注意，針對攻擊者服務器的“登錄消息”不是故意存在的（儘管它實際上是傳輸給攻擊者的）。我想強調一個事實，即可以在不可能讀取消息的情況下利用這個問題。在此攻擊中，攻擊者必須暴力破解已經提到的消息ID值。它使整個攻擊複雜化，但仍然有可能被利用。
總結這一部分，攻擊者可以設置自己的惡意Enterprise Server，並濫用攻擊條件來向Web應用程序交付自己的身份驗證響應。還有兩件事需要調查：響應消息是什麼樣的，我們能否緩解攻擊？
身份驗證處理以下代碼段提供了對登錄消息的示例響應。請注意，這些消息在合法使用期間會更大。但是，對於概念驗證，我已將它們最小化並僅存儲了開發所需的那些部分。
響應消息由幾個重要部分組成：
马云惹不起马云它包含一個responseObject標記，它是一個序列化的用戶對象。
马云惹不起马云它包含一個非常重要的responseCode標籤。
马云惹不起马云在身份驗證期間的某個時刻，Web後端調用UserService.doLogin方法：
doLogin.java
在[1]處，UserCredentials對像被實例化。然後，設置其成員。
在[2]處，將調用authenticate方法，並將在[1]處初始化的對像作為參數傳遞：
authenticate.java
在[1]處，初始化UserLogin對象。
在[2]處，UserCredentials對像被序列化。
在[3]處，消息正在發送到企業服務器，Web後端等待響應。
在[4]處，驗證響應中包含的responseCode。我們希望它等於0。
在[5]處，userLogin.authenticated設置為True。
在[6]處，userLogin.currentUser被設置為包含在responseObject中的對象。
在[7]處，該方法返回userLogin對象。
基本上，響應應該有一個等於0的responseCode。它還應該在responseObject標記中包含一個正確序列化的User對象。
最後，我們分析負責調用doLogin函數的UserBean.loginInner方法的片段。
loginInner.java
在[1]處，調用doLogin方法。它檢索UserLogin類型的對象。
在[2]處，它將this.currentUser設置為userLogin.currentUser。
在[3]處，它設置各種其他設置。
有一件非常重要的事情需要注意：Web後端不會將登錄面板中提供的用戶名與企業服務器檢索到的用戶名進行比較。因此，攻擊者可以：
马云惹不起马云觸髮用戶名為“poc”的身份驗證。
马云惹不起马云贏得攻擊並在響應中提供用戶“amcadmin”。
马云惹不起马云然後攻擊者將被認證為“amcadmin”。
總而言之，攻擊者似乎沒有任何障礙，他的響應應該由WebBackend處理，沒有任何問題。接下來，我們將注意力轉向防禦。
在默認安裝中，EnterpriseServer和InfoRail服務與Web後端位於同一主機上。這使得攻擊條件的利用變得更加困難，因為合法的通信由本地接口處理，這比通過外部網絡接口的通信要快得多。
儘管如此，攻擊者還是有一些優勢。例如，他不必生成動態響應，因為響應負載可以在漏洞利用中進行硬編碼。下表概述了攻擊者和合法EnterpriseServer必須執行的操作。
攻擊者從原始登錄消息中獲取消息ID，並將其放置在標頭中。
發送靜態響應。
企業服務器從原始登錄消息中獲取消息ID並將其放在標頭中。
解密並驗證用戶的憑據。
檢索用戶的詳細信息並創建用戶對象。
動態創建響應。
遠程攻擊者需要執行的操作要少得多，可以更快地準備響應。它使攻擊可以順利進行。
未經身份驗證的攻擊者可以修改Avalanche系統設置。這是由於一個單獨的漏洞允許繞過域身份驗證(ZDI-CAN-15919)。遠程攻擊者可以啟用基於LDAP的身份驗證並為LDAP服務器配置設置任何地址。在這種情況下，合法的EnterpriseServer將首先嘗試訪問這個“非法”身份驗證服務器。這將給攻擊者額外的1 - 2秒時間(如果使用得當，甚至更多)。這樣，攻擊者就可以獲得更多的時間來發起攻擊。