.NET Framework HTTP用戶端代理設計缺陷，結合WSDL匯入可構成RCE攻擊鏈

WatchTowr Labs資安研究人員公開SOAPwn研究，揭露.NET Framework內建HTTP用戶端代理HttpWebClientProtocol及其衍生的SoapHttpClientProtocol存在設計缺陷，微軟多次將相關回報標記為不修補，但實際測試證實，攻擊者可結合Web服務描述語言（Web Services Description Language，WSDL）匯入機制，在多款企業級產品上建構可重複利用的遠端程式碼執行攻擊鏈，部分產品情境甚至在無需額外使用者操作的情況下即可觸發。

研究人員指出，這類簡單物件存取協定（Simple Object Access Protocol，SOAP）用戶端代理名義上用於透過HTTP存取XML Web服務，但實作上會根據網址前綴自動選擇不同通訊元件。也就是說，只要攻擊者有辦法更動代理的URL設定，就能把原本指向HTTP服務的網址，改成指向本機檔案路徑或SMB分享路徑。因此原本要當成SOAP請求送出去的內容，反而可能被寫進伺服器檔案系統，或被送到攻擊者控制的檔案分享點，前者帶來任意位置寫入檔案的風險，後者則造成NTLM雜湊外洩。

不少.NET應用允許管理者輸入WSDL網址，程式會透過ServiceDescriptionImporter自動產生並呼叫SOAP用戶端代理。當WSDL由攻擊者提供時，攻擊者可以在WSDL裡動手腳，把服務位址改成伺服器上的檔案路徑，並設計好SOAP內容的結構，讓代理在指定路徑寫入ASPX或CSHTML等可執行檔案。對外看起來如同正常呼叫Web服務，實際上則是在伺服器指定路徑寫入一個Webshell或其他惡意腳本檔案，讓攻擊者後續得以遠端執行程式碼。

在已公開的案例中，研究人員在Barracuda Service Center RMM與Ivanti Endpoint Manager等產品中驗證完整攻擊流程，前者漏洞編號CVE-2025-34392，並以2025.1.1熱修補更新處理，後者則對應CVE-2025-13659。研究人員並指出，Umbraco 8 CMS、Microsoft PowerShell與SQL Server Integration Services也存在可利用情境，代表這並非單一實作疏失，而是.NET SOAP HTTP用戶端代理設計在實務使用下衍生的系統性問題。

研究人員提到，微軟主張不應讓不受信任輸入控制URL或WSDL來源，因而將問題界定為應用程式與使用者層級。在缺乏框架端修補的前提下，研究人員建議廠商與企業團隊主動盤點是否使用SoapHttpClientProtocol與ServiceDescriptionImporter等元件，特別是允許外部匯入WSDL並動態產生代理的功能，並在應用層限制僅接受HTTP與HTTPS協定，同時為WSDL來源設定明確信任邊界。