.net core EPPlus npoi_在.NET中隐藏帶有隻讀Web路徑的Web shell

在最近一次滲透測試中，我發現了一個容易受到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直接嵌入初始漏洞利用代碼中。 項目中的檔案顯示了我們建立的用于在易受攻擊的Web應用程式上運作Web Shell的代碼。

為了使用此代碼，可以對Web Shell檔案的内容進行base-64編碼并将其存儲在webshellContentsBase64參數中。 webshellType參數包含Web Shell擴充，而targetVirtualPath參數包含将在伺服器上建立的虛拟路徑。除了這些參數外，其他參數可以保持不變，如果需要更多的自定義，代碼中的注釋就足夠了。

以下指令顯示了如何使用它來使用生成LosFormatter有效載荷的示例：

.\ -g ActivitySurrogateSelectorFromFile -f LosFormatter -c "C:\CoolTools\\ExploitClass\;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/ HTTP/ uthorization: [ntlm auth header] Content-Type: application/x-www-form-urlencoded Host: [target] Content-Length: [length of body] __VIEWSTATE=&__SUGGESTIONSCACHE__=[DataSet payload from ] 

2.生成并發送資料集有效載荷以禁用ActivitySurrogateSelector的.NET Framework v4.8 +類型保護：

.\ -p SharePoint  

3.生成并發送資料集有效載荷以運作虛拟Web Shell：

.\ -p SharePoint  

可以更改檔案，使其更具自定義性，以提供多個檔案以及隐藏自身，直到看到特殊的标頭或檔案名為止。當尚未編譯現有目錄中的特定檔案時，更改IsPathVirtual函數也很友善。目前，它會響應所有傳入的請求，但是你可能希望将其限制為某些名稱，或者檢查檔案擴充名以提供不同的内容。

繞過

從.NET 4.5開始，Web應用程式可以使用友好的URL在指向ASPX頁面時不使用URL中的“.aspx”，這可以阻止我們建立ghost web shell的方法。下面的解決方案可以為使用此功能的Web應用程式覆寫此設定。

foreach(var route in ) {     if (().FullName == ".FriendlyUrlRoute") {         var FriendlySetting = ().GetProperty("Settings",  | System.Reflection.BindingFlags.Public);           var settings = new .FriendlyUrlSettings();          = .RedirectMode.Off;           (route, settings);         } } 

該代碼已包含在檔案中，需要時，該注釋無需取消注釋(建立有效載荷也需要.dll檔案)。

繞過預編譯的限制

當應用程式處于預編譯模式時，.NET中的虛拟路徑提供程式無法注冊。但是，由于我們已經可以在應用程式上執行代碼，是以可以使用反射更改屬性。該代碼已包含在項目的檔案中。

結果，即使應用程式處于預編譯模式，也可以建立虛拟Web Shell。

利用其他Web處理程式

當利用代碼執行漏洞時，虛拟檔案方法将起作用，該代碼執行漏洞使用另一個Web處理程式，例如用于Web服務的處理程式。盡管他們的響應可能不會顯示虛拟Web Shell的執行，但是仍然可以通過直接在浏覽器中浏覽到虛拟Web Shell來通路它。

虛拟檔案檢測機制

盡管虛拟檔案僅存在于記憶體中，但是它們的編譯版本儲存在臨時位置中，該臨時位置用于.NET頁的編譯，預設目錄通常采用以下格式：

C:\Windows\\Framework64|Framework\v[version]\Temporary  Files\[appname]\[hash]\[hash]\ 

是以，通過檢測新建立的臨時檔案，有可能檢測到惡意編譯檔案。應該注意的是，在應用程式的預設目錄中接管未編譯的. net檔案是可能的。是以，除非應用程式處于預編譯模式，否則檢測新建立的檔案名不能用作安全檢測機制，是以，不應建立新的已編譯檔案。

如果你不需要在檔案系統上建立任何檔案，則可以考慮将本文中讨論的第一個解決方案(在C＃中建立可正常運作的Web Shell)作為替代方案。但是，此解決方案具有通過檢測未加密的流量以擷取特定簽名或檢測到從特定來源向特定目标發出的異常大的Web請求的檢測風險。