在最近一次滲透測試中，我發現了一個容易受到CVE-2020-1147 影響的SharePoint實例。我被要求在不運行任何命令的情況下構建Web Shell，以避免任何可能部署在主機上的EDR解決方案。由于目標SharePoint服務器以最小的特權在IUSR用戶下運行，因此我們不能簡單地通過利用反序列化漏洞（CVE-2020-1147）在Web目錄中創建Web Shell。我記得以前在運行PowerShell命令時，攻擊很容易被發現，所以需要更隱蔽的方法！
這篇文章說明了當我們存在代碼執行漏洞但Web目錄不可寫時如何創建Web Shell，從理論上講，我們應該能夠執行此操作，因為我們的代碼正在Web應用程序中執行，因此我想出了以下兩種解決方案：
使用C＃創建功能全面的Web Shell
盡管我很喜歡使用Web Shell，但是大多數功能強大的.NET都是HTML和C＃代碼的混合體。因此，清理它們以將其作為純C＃代碼運行非常困難且耗時。我的解決方案是使用aspnet_compiler命令，以便從其臨時編譯文件中獲取ASPX Web Shell的C＃代碼。
另一個問題是，當我們想與嵌入式Web Shell進行交互時，當易受攻擊的頁面和Web Shell期望完全不同的HTTP請求時，我們可能需要利用我們的易受攻擊的功能，這可能會導致沖突或根本不適用。因此，URL和正文中所有與Web Shell相關的參數以及HTTP動詞，內容類型，Cookie和其他自定義標頭都應以某種方式封裝，以便在利用代碼執行之后在服務器端重新創建。盡管自定義JavaScript代碼可能能夠處理某些封裝任務，但是捕獲HTTP請求的所有必需方面可能并不容易。因此，使用代理處理請求似乎是一種更好，更輕松的方法。例如，可以通過編寫Burp Suite擴展程序來完成此操作，該擴展程序可以捕獲對Web Shell的所有請求，這些請求最初是通過利用代碼執行問題加載的。此擴展可以將Web Shell參數封裝在HTTP請求的標頭中，發送該HTTP請求以利用代碼執行問題。使用標頭可能會受到限制，尤其是當Web Shell請求包含較大的參數（例如正在上傳文件時）時。但是，使用代理替換字符串可以保證可以在服務器端重新創建帶有適當參數（例如HTTP正文、內容類型、HTTP動詞和URL參數）的預期HTTP請求，以使Web Shell正常工作。應該注意的是，使HTTP請求中的只讀參數（例如表單參數）可使用反射寫入是相當容易的。另一件需要注意的重要事情是清除任何可能在運行web shell代碼之前創建的HTTP響應，響應還需要在web shell執行后結束，以防止任何意外數據干擾來自web shell的預期響應。
盡管這種技術看起來可行，但我還是沒有使用它，因為它很復雜，而且每次操作都需要向服務器發送大量web請求，以減少潛在的檢測風險。
通過濫用.NET中的虛擬路徑提供程序來創建虛擬文件（ghost文件）
使用.NET，可以定義虛擬路徑，以便為文件系統以外的其他存儲源提供虛擬文件。此功能非常強大，因為它甚至可以用于替換尚未緩存或編譯的現有文件。這意味著通過替換現有的.NET文件（例如.aspx，.svc，.ashx，.asmx等）來顯示攻擊者的預期內容，即使對于網絡釣魚或其他系統攻擊也可以派上用場。 SharePoint本身使用類似的方法來創建ghost頁面和未托管的頁面！
該解決方案對測試人員而言具有最小的復雜性，因為可以將Web Shell直接嵌入初始漏洞利用代碼中。 YSoSerial.Net項目中的GhostWebShell.cs文件顯示了我們創建的用于在易受攻擊的Web應用程序上運行Web Shell的代碼。
為了使用此代碼，可以對Web Shell文件的內容進行base-64編碼并將其存儲在webshellContentsBase64參數中。 webshellType參數包含Web Shell擴展，而targetVirtualPath參數包含將在服務器上創建的虛擬路徑。除了這些參數外，其他參數可以保持不變，如果需要更多的自定義，代碼中的注釋就足夠了。
以下命令顯示了如何使用它來使用YSoSerial.Net生成LosFormatter有效載荷的示例：
- .\ysoserial.exe -g ActivitySurrogateSelectorFromFile -f LosFormatter -c "C:\CoolTools\ysoserial.net\ExploitClass\GhostWebShell.cs;System.dll;System.Web.dll;System.Data.dll;System.Xml.dll;System.Runtime.Extensions.dll"
應該注意的是，在使用ActivitySurrogateSelectorFromFile gadget 之前，應該使用ActivitySurrogateDisableTypeCheckgadget，以便為新版本的.NET Framework啟用它。
以下步驟顯示如何使用此技術在易受CVE-2020-1147攻擊的SharePoint服務器上創建虛擬Web Shell：
1.準備基本有效載荷，其中包含利用遠程代碼執行漏洞所需的DataSet有效載荷：
- POST /_layouts/15/quicklinks.aspx?Mode=Suggestion HTTP/1.1
- uthorization: [ntlm auth header]
- Content-Type: application/x-www-form-urlencoded
- Host: [target]
- Content-Length: [length of body]
- __VIEWSTATE=&__SUGGESTIONSCACHE__=[DataSet payload from YSoSerial.Net]
2.生成并發送數據集有效載荷以禁用ActivitySurrogateSelector的.NET Framework v4.8 +類型保護：
- .\ysoserial.exe -p SharePoint
3.生成并發送數據集有效載荷以運行虛擬Web Shell：
- .\ysoserial.exe -p SharePoint
可以更改GhostWebShell.cs文件，使其更具自定義性，以提供多個文件以及隱藏自身，直到看到特殊的標頭或文件名為止。當尚未編譯現有目錄中的特定文件時，更改IsPathVirtual函數也很方便。目前，它會響應所有傳入的請求，但是你可能希望將其限制為某些名稱，或者檢查文件擴展名以提供不同的內容。
繞過Microsoft.AspNet.FriendlyUrls
從.NET 4.5開始，Web應用程序可以使用友好的URL在指向ASPX頁面時不使用URL中的“.aspx”，這可以阻止我們創建ghost web shell的方法。下面的解決方案可以為使用此功能的Web應用程序覆蓋此設置。
- foreach(var route in System.Web.Routing.RouteTable.Routes)
- {
- if (route.GetType().FullName == "Microsoft.AspNet.FriendlyUrls.FriendlyUrlRoute") {
- var FriendlySetting = route.GetType().GetProperty("Settings", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.Public);
-
- var settings = new Microsoft.AspNet.FriendlyUrls.FriendlyUrlSettings();
- settings.AutoRedirectMode = Microsoft.AspNet.FriendlyUrls.RedirectMode.Off;
-
- FriendlySetting.SetValue(route, settings);
- }
- }
該代碼已包含在GhostWebShell.cs文件中，需要時，該注釋無需取消注釋（創建有效載荷也需要Microsoft.AspNet.FriendlyUrls.dll文件）。
繞過預編譯的限制
當應用程序處于預編譯模式時，.NET中的虛擬路徑提供程序無法注冊。但是，由于我們已經可以在應用程序上執行代碼，因此可以使用反射更改System.Web.Compilation.BuildManager.IsPrecompiledApp屬性。該代碼已包含在YSoSerial.Net項目的GhostWebShell.cs文件中。
結果，即使應用程序處于預編譯模式，也可以創建虛擬Web Shell。
利用其他Web處理程序
當利用代碼執行漏洞時，虛擬文件方法將起作用，該代碼執行漏洞使用另一個Web處理程序，例如用于Web服務的處理程序。盡管他們的響應可能不會顯示虛擬Web Shell的執行，但是仍然可以通過直接在瀏覽器中瀏覽到虛擬Web Shell來訪問它。
虛擬文件檢測機制
盡管虛擬文件僅存在于內存中，但是它們的編譯版本保存在臨時位置中，該臨時位置用于.NET頁的編譯，默認目錄通常采用以下格式：
- C:\Windows\Microsoft.NET\Framework64|Framework\v[version]\Temporary ASP.NET Files\[appname]\[hash]\[hash]\
因此，通過檢測新創建的臨時文件，有可能檢測到惡意編譯文件。應該注意的是，在應用程序的默認目錄中接管未編譯的. net文件是可能的。因此，除非應用程序處于預編譯模式，否則檢測新創建的文件名不能用作安全檢測機制，因此，不應創建新的已編譯文件。
如果你不需要在文件系統上創建任何文件，則可以考慮將本文中討論的第一個解決方案（在C＃中創建可正常運行的Web Shell）作為替代方案。但是，此解決方案具有通過檢測未加密的流量以獲取特定簽名或檢測到從特定來源向特定目標發出的異常大的Web請求的檢測風險。
本文翻譯自：https://www.mdsec.co.uk/2020/10/covert-web-shells-in-net-with-read-only-web-paths/如若轉載，請注明原文地址。
