Asp.net EnableViewStateMac 和恶意代码【12 月安全更新】 [英] Asp.net EnableViewStateMac and malicious code [December security updates]

问题描述

在最新的 Asp.Net 2013 年 12 月安全更新 Microsoft 发布了 ASP.Net 补丁 - 不安全的 ASP.NET Web 窗体 (.aspx) 配置可能允许远程代码执行".相关知识库是 2905247

In the latest Asp.Net December 2013 Security updates Microsoft released a patch for ASP.Net - 'Insecure ASP.NET Web Forms (.aspx) configuration could allow remote code execution'. Related KB is 2905247

据我所知，ViewStateMac 过去只是用来确定这个 ViewState 是由服务器生成的，而不是由攻击者生成的.但在安全更新文章中，他们说:

As I know ViewStateMac just used to be sure that this ViewState was generated by server, and not an attacker. But in security updates article they say:

如果 Web 开发人员为他的任何页面设置了 EnableViewStateMac=false站点，攻击者可以利用它来上传和调用任意网络服务帐户上下文中的可执行代码.这是远程代码执行 (RCE) 攻击示例.

If a web developer sets EnableViewStateMac=false for any page in his site, an attacker could leverage this to upload and invoke arbitrary executable code within the context of the web service account. This is an example of a remote code execution (RCE) attack.

例如，如果我禁用了某些 aspx 页面的 EnableViewStateMac，它如何允许攻击者在我的 Web 应用程序的上下文中执行恶意代码?据我了解，在最坏的情况下，攻击者可以欺骗 ViewState 以获取一些假数据\事件\验证.但它只会影响这个页面.而且我无法通过将执行的 ViewState 上传任何恶意 C# 代码.在这种情况下，RCE 攻击是什么意思?

For example if I disable EnableViewStateMac for some aspx page, how it allows attacker to execute malicious code in context of my web application? As I understand in the worst case an attacker can spoof ViewState for some fake data\events\validation. But it will affect just this page. And I can't upload any malicious C# code via ViewState that will be executed. What are they mean by RCE attack in that case?

推荐答案

我找不到此漏洞的更多详细信息，因此我的回答仅推测了可能的攻击向量.

I can't find any further details of this vulnerability, so my answer only speculates to a possible attack vector.

MAC 是 ViewState 值的签名，使用 EnableViewStateMac=true ASP.NET 将检查 MAC 签名是否实际将 ViewState 值签名为真实的.这意味着 __VIEWSTATE 隐藏字段中从客户端发送的 ViewState 值已被验证为来自服务器.

The MAC is a signature of the ViewState value, and with EnableViewStateMac=true ASP.NET will check whether the MAC signature actually signs the ViewState value as authentic. This means that the ViewState value sent from the client in the __VIEWSTATE hidden field has been verified to come from the server.

现在想象一下，处理 ViewState 值的代码容易受到对象反序列化的影响.Microsoft 公告指出:

Now imagine that the code processing the ViewState value is vulnerable to say object deserialisation. The Microsoft advisory states:

未经身份验证的攻击者可以将特制的 HTTP 内容发送到目标服务器，这可能允许攻击者在 ASP.NET 站点上运行的服务帐户的上下文中在服务器上运行代码.

An unauthenticated attacker could send specially crafted HTTP content to the targeted server, potentially allowing the attacker to run code on the server in the context of the service account running on the ASP.NET site.

使用 EnableViewStateMac=true 时，无法利用此漏洞，因为在处理 ViewState 值之前验证 MAC.任何不是来自服务器的值都会遇到 Validation of viewstate MAC failed 异常消息.

With EnableViewStateMac=true this vulnerability cannot be exploited because the MAC is validated before the ViewState value is processed. Any value that has not come from the server will be met with a Validation of viewstate MAC failed exception message.

但是，如果使用 EnableViewStateMac=false，攻击者可以操纵整个 ViewState 值来利用 缓冲区溢出/使用权限提升/escape 攻击并执行任意作为有效负载注入 __VIEWSTATE 字段的代码.

However, with EnableViewStateMac=false the whole ViewState value could be manipulated by an attacker to exploit the buffer overflow/escape attack with privilege escalation and execute arbitrary code that is injected as a payload into the __VIEWSTATE field.

总而言之，由于不再验证 ViewState 值，它打开了这个未公开的攻击向量攻击的领域.

So in summary, as the ViewState value is no longer being validated it opens up the field to attack by this unpublicised attack vector.

这篇关于Asp.net EnableViewStateMac 和恶意代码【12 月安全更新】的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！