这个新的 ASP.NET 安全漏洞有多严重? 我该如何解决它？

我该怎么保护自己？

[更新2010-09-29]

微软安全公告

关于修复的 KB 文章

ScottGu 有下载的链接

[更新2010-09-25]

虽然我们正在等待修复，昨天 ScottGu后置更新关于如何添加一个额外的步骤，以保护您的网站与自定义 URLScan 规则。

此外，在错误页面中添加一个随机时间睡眠，以防止攻击者从 计算反应时间中获取添加的攻击信息。

在 web.config 中

<configuration>
<location allowOverride="false">
<system.web>
<customErrors mode="On" defaultRedirect="~/error.html" />
</system.web>
</location>
</configuration>

这将把任何错误重定向到用200状态码返回的自定义页面。这样，攻击者就无法查看错误代码或错误信息，以获取进一步攻击所需的信息。

设置 customErrors mode="RemoteOnly"也是安全的，因为这将重定向“真正的”客户端。只有从本地主机浏览才会显示内部。净错误。

重要的部分是确保将所有错误配置为返回相同的错误页面。这需要您在 <customErrors>部分显式设置 defaultRedirect属性，并确保不设置每个状态代码。

什么利害攸关？

如果攻击者设法使用上述漏洞，他/她可以从你的 web 应用程序中下载内部文件。通常，web.config 是一个目标，可能包含一些敏感信息，比如数据库连接字符串中的登录信息，或者甚至链接到一个自动化的 sql-Express 数据库，您不希望有人获得这些信息。但是如果您遵循的是最佳实践，那么可以使用 受保护的配置来加密 web.config 中的所有敏感数据。

引用链接

阅读微软关于 http://www.microsoft.com/technet/security/advisory/2416728.mspx漏洞的官方评论，特别是关于这个问题的实现细节的“解决方案”部分。

还有一些关于 斯科特 · 古的博客的信息，包括一个 剧本，它可以在你的网络服务器上找到易受攻击的 ASP.Net 应用程序。

有关“理解填充 Oracle 攻击”的解释，请参阅 @ sri 的回答。

对这篇文章的评论:

Rizzo 和 Duong 对 ASP.NET 应用实施的攻击需要加密 在网站上的实现具有一个 Oracle，当发送密文时，它不仅会解密文本 但是 给发送方一条关于密文中的填充是否有效的消息。

如果填充无效，发送方得到的错误消息将提供有关站点解密过程工作方式的一些信息。

为了使攻击发挥作用，必须做到以下几点:

• 应用程序必须提供关于填充无效的错误消息。
• 必须有人篡改您的加密 Cookie 或视图状态

所以，如果你返回人类可读的错误消息在你的应用程序，如 “出了问题，请再试一次”，那么你应该是相当安全的。阅读一些关于这篇文章的评论也可以提供有价值的信息。

• 在加密的 cookie 中存储会话 ID
• 将实际数据存储在会话状态(保存在数据库中)
• 当用户信息错误时，在返回错误之前添加一个随机等待，因此无法计时

这样，被劫持的 cookie 只能用于检索一个很可能不再存在或无效的会话。

看看 Ekoparty 会议上到底展示了什么将会很有趣，但是现在我并不太担心这个漏洞。

理解填充 Oracle 攻击

让我们假设您的应用程序接受一个加密的字符串作为参数-无论这个参数是一个 cookie、一个 url 参数还是其他什么都是无关紧要的。当应用程序试图解码它时，有3种可能的结果-

1. 结果1 : 加密的字符串被正确解密，应用程序能够理解它。也就是说，如果加密的字符串是一个10位数的帐号，解密后应用程序会发现类似于“1234567890”而不是“ abcd1213ef”

2. 结果2 : 填充是正确的，但解密后获得的字符串是胡言乱语，应用程序无法理解。例如，字符串解密为“ abcd1213ef”，但应用程序只期待数字。大多数应用程序会显示类似“无效帐号”的信息。

3. 结果3 : 填充不正确，应用程序抛出了某种错误消息。大多数应用程序会显示类似“发生了一些错误”的通用消息。

为了使填充 Oracle 攻击成功，攻击者必须能够发出几千个请求，还有必须能够将响应分类到上述3个桶中的一个而不出错。

如果满足这两个条件，攻击者最终可以解密消息，然后使用他希望的任何方式重新加密消息。只是时间问题。

可以采取什么措施来防止这种情况发生？

1. 最简单的事情-任何敏感的东西都不应该发送到客户端，加密或没有加密。保存在服务器上。

2. 确保向攻击者提供上面列表 看起来一模一样中的结果2和结果3。应该没有办法区分两者。不过，这并不那么容易——攻击者可以使用某种定时攻击进行区分。

3. 作为最后一道防线，建立一个网络应用层防火墙。填充 Oracle 攻击需要创建几个看起来几乎相似的请求(一次更改一个位) ，因此 WAF 应该可以捕获并阻止这样的请求。

附注: 在 这篇博文中可以找到关于填充 Oracle 攻击的很好的解释。免责声明: 这不是我的博客。

这里 是 MS 响应。这一切都归结为“使用自定义错误页面”，你不会给出任何线索。

剪辑
这里 是来自 Scottgu 的一些更详细的信息。

一些重要的链接:

• MS’Security Advisory 2416728 (这是官方信息)
• 来自 MS 安全研究与防御团队的更多信息
  • 「认识 ASP.NET 的漏洞」(2010-09-17)
  • “关于 ASP.NET 漏洞的其他信息”(2010-09-20)
• Scott Gu: “重要: ASP.NET 安全漏洞”(2010-09-18)

[回答这个问题的严肃性方面(已发表的内容和解决办法都包含在其他答案中)。]

被攻击的密钥用于保护视图状态和会话 Cookie。通常这个密钥是由 ASP.NET 在每个 web 应用程序的新实例中在内部生成的。这将把损坏的范围限制在工作进程的生命周期内，当然对于繁忙的应用程序来说，损坏的时间可能是几天(也就是说，没有太大的限制)。在此期间，攻击者可以更改(或注入) ViewState 中的值并更改它们的会话。

更严重的是，如果你希望会话能够跨工作进程生命周期，或者允许 web 农场(即农场中的所有实例都可以处理任何用户会话)的关键需要硬编码，这是在 web.config中完成的:

[...]
<system.web>
<machineKey
decryption="AES"
validation="SHA1"
decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
/>

当然，这些是新创建的密钥，我使用以下 PowerShell 来访问 Windows 加密随机数生成器:

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

(验证使用的数组长度为20，解密密钥使用的数组长度为16。)

除了修改公共错误页面以避免泄漏特定错误之外，现在似乎是更改上述键(或者循环辅助进程(如果它们已经运行了一段时间)的好时机。

[编辑2010-09-21: 添加到顶部的链接]

加入 ScottGu 在 http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx讨论中的回应

是否影响自定义 IHttpModule 而不是 customError？

问: 我没有在 web.config 中声明元素，而是在节中声明了一个 IHttpModule。该模块记录错误并重定向到搜索页面(404页)或错误页面(500页)。我很脆弱吗？

答: 我建议暂时更新模块，以便总是重定向到搜索页面。这种攻击的工作方式之一是寻找404和500个错误之间的区别。总是返回相同的 HTTP 代码并将它们发送到相同的地方是帮助阻止它的一种方法。

请注意，当修补程序出来修复这个问题时，您不需要这样做(并且可以恢复到原来的行为)。但就目前而言，我建议客户不要区分404和500。

对于404和500错误，我是否可以继续使用不同的错误？

问: 我认为我们仍然可以定义一个自定义的404页面，除了缺省的错误重定向，而不违反上面描述的原则？

答: 没有——直到我们为真正的修复发布了一个补丁，我们才建议使用上述同质化所有错误的解决方案。这种攻击的工作方式之一是寻找404和500个错误之间的区别。总是返回相同的 HTTP 代码并将它们发送到相同的地方是帮助阻止它的一种方法。

请注意，当修补程序出来修复这个问题时，您不需要这样做(并且可以恢复到原来的行为)。但是现在你不应该对客户区分404和500。

这是如何允许公开 web.config 的？

问: 这如何允许 web.config 的暴露？这似乎只能解密 ViewState，是否还有其他相关的漏洞也允许信息披露？有没有白皮书详细说明这次袭击以便更好地解释发生了什么？

答: 公开显示的攻击依赖于 ASP.NET 中的一个特性，该特性允许下载文件(通常是 javascript 和 css) ，并且用作为请求的一部分发送的密钥保护它。不幸的是，如果您能够伪造一个密钥，您可以使用这个特性来下载应用程序的 web.config 文件(但不能下载应用程序外部的文件)。我们当然会为此发布一个补丁-直到上面的解决方案关闭攻击向量。

编辑: 在 http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx的第二篇博客文章中可以找到更多的常见问题

NetMVC 也受到这个问题的影响(Sharepoint 也是如此，... ...)

我已经在这里介绍了修复 MVC 的方法: NET MVC 是否容易受到 Oracle 填充攻击？

国际海事组织认为，这方面没有全面的预防措施，需要根据具体情况进行处理:

Http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html

在对这个问题做了额外的研究之后，我刚刚发布了我对这个 在我的博客里的全部看法。我认为很重要的一点是要弄清楚为什么他们要造一个 auth cookie。

只是想弄清楚一些事实:

1. 攻击不会让你直接得到机器密钥。也就是说，它非常像它，因为它允许解密消息，并修改重新加密新的。
2. 获取实际密钥的方法是使用它们修改 re/crypt 的能力，如1所示，并获取 web.config。不幸的是，有些人将这些键放在站点级别的 web.config 中是有原因的(不同的讨论) ，在示例视频中，DotnetNuke 的默认设置让他们受益匪浅。
3. 要获得 web.config all，需要指出他们正在使用 webresources. axd 和/或 scriptresources. axd。我以为这些只对嵌入式资源有用，但看起来不是这样的。
4. 如果应用程序是 asp.net MVC，我们就不需要 webresources. axd 和/或 scriptresources. axd，这样就可以关闭它们。我们也不使用 viewstate。也就是说，我并不清楚 asp.net 的其他特性是否提供了不同的信息，也就是说，我不知道是否填充错误地给出了无效的结果，而在忽略的认证票据中填充了有效的结果(不知道是否是这种情况) ... 同样的分析应该适用于会话 cookie。
5. Net 成员资格提供者“缓存”cookie 中的角色，关闭它。

大约1，假的加密消息不可能100% 任意地需要容忍消息中某个地方的一小块垃圾，因为消息中有1个块的解密值是无法控制的。

最后，我想说的是，这个问题是 ms 在这种情况下没有遵循自己的指导的结果: 一个特性依赖于发送给客户端的某些东西是防篡改的。

更多关于:

我不知道在忽略的身份验证票据中填充有效的结果时，填充是否会给出错误的无效结果(不知道是否是这种情况) ... 同样的分析应该适用于会话 cookie。

Auth cookie 是签名的，根据文件中的信息，如果他们没有得到实际的密钥(就像他们在视频中伪造 auth cookie 之前所做的那样) ，他们就不应该能够生成签名 cookie。

正如 Aristos 提到的，对于 cookie 中的会话 ID，对于用户会话来说是随机的，因此必须从具有目标安全级别的用户那里进行嗅探，并在该会话处于活动状态时进行破解。即便如此，如果您依赖于身份验证来分配/授权用户操作，那么影响将是最小的/这将在很大程度上取决于在该应用程序中使用 Session 的目的。

这个 bug 的补丁已经在 WindowsUpdate 上发布: Http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx