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

我刚刚在网上阅读了有关ASP.NET中新发现的安全漏洞的信息。您可以在此处阅读详细信息。

问题在于ASP.NET实施AES加密算法以保护这些应用程序在用户会话期间生成的用于存储信息的cookie的完整性。

这有点含糊，但这是一个更令人恐惧的部分：

攻击的第一阶段需要数千个请求，但是一旦成功，攻击者获得了秘密密钥，就完全是秘密的。所需的密码知识非常基础。

总而言之，我对安全性/加密图主题还不够熟悉，无法知道这是否真的那么严重。

那么，所有ASP.NET开发人员都应该担心这种可以在几秒钟之内拥有任何ASP.NET网站的技术吗？

此问题如何影响普通的ASP.NET开发人员？它对我们有影响吗？在现实生活中，此漏洞的后果是什么？最后，是否有防止该漏洞的解决方法？

感谢您的回答！

编辑：让我总结一下我得到的答复

因此，这基本上是一种“ padding oracle”攻击。@Sri对这种攻击的含义提供了很好的解释。这是有关此问题的令人震惊的视频！

关于此漏洞的严重性：是的，确实是严重的。它使攻击者可以了解应用程序的机器密钥。因此，他可以做一些非常不需要的事情。

• 拥有应用程序的机器密钥后，攻击者可以解密身份验证Cookie。
• 甚至更糟糕的是，他可以使用任何用户的名称生成身份验证cookie。因此，他可以在网站上以任何人的身份出现。该应用程序无法区分您还是使用您自己的名字生成身份验证Cookie的黑客。
• 它还使他能够解密（并生成）会话cookie，尽管这不像前一个那么危险。
• 不太严重：他可以解密页面的加密ViewState。（如果您使用ViewState存储机密数据，则无论如何都不应该这样做！）
• 出乎意料：借助机器密钥，攻击者可以从您的Web应用程序下载任何文件，甚至通常无法下载的文件也是如此！（包括Web.Config等）

这是我得到的很多好的实践，它们不能解决问题，但有助于提高Web应用程序的总体安全性。

• 您可以使用受保护的配置加密敏感数据
• 使用仅HTTP cookie
• 防止DoS攻击

现在，让我们集中讨论这个问题。

• 斯科特·格思里（Scott Guthrie）在他的博客上发布了关于它的条目
• ScottGu的有关该漏洞的FAQ博客文章
• ScottGu关于漏洞的更新
• Microsoft对此有安全建议
• 了解漏洞
• 有关漏洞的其他信息

解决方案

• 启用customErrors并创建一个将所有错误都重定向到的错误页面。是的，甚至是404s。（ScottGu说，区分404和500是此攻击的必要条件。）此外，在您的代码中Application_Error或Error.aspx放置一些会造成随机延迟的代码。（生成一个随机数，并使用Thread.Sleep睡眠那么长时间。）这将使攻击者无法确定服务器上到底发生了什么。
• 有人建议切换回3DES。从理论上讲，如果您不使用AES，就不会遇到AES实现中的安全漏洞。事实证明，根本不建议这样做。

其他一些想法

• 似乎并非 每个人都认为解决方法足够好。

感谢所有回答我的问题的人。我不仅从这个问题中学到了很多知识，而且从总体上学到了网络安全方面的知识。我将@Mikael的答案标记为已接受，但其他答案也非常有用。

我该怎么做才能保护自己？

[2010-09-29更新]

Microsoft安全公告

有关修复的知识库文章

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"，因为这将重定向“真实”客户端。仅从本地主机浏览将显示内部.Net错误。

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

有什么危险？

如果攻击者设法使用了所提到的漏洞，则可以从您的Web应用程序中下载内部文件。通常，web.config是目标，并且可能在数据库连接字符串中包含敏感信息，例如登录信息，甚至链接到您不希望有人掌握的自动安装的sql-express数据库。但是，如果您遵循最佳实践，则可以使用“ 受保护的配置”来加密web.config中的所有敏感数据。

参考链接

在http://www.microsoft.com/technet/security/advisory/2416728.mspx上阅读Microsoft对该漏洞的官方评论。特别是“解决方法”部分，以获取有关此问题的实现详细信息。

另外，ScottGu博客上的一些信息，包括在您的Web服务器上查找易受攻击的ASP.Net应用程序的脚本。

有关“了解Oracle攻击的填充”的说明，请阅读@sri的答案。

对文章的评论：

Rizzo和Duong对ASP.NET应用程序实施的攻击要求网站上的加密实现具有一个oracle，该oracle在发送密文时不仅会解密文本，还会向发送方发送有关是否在密文中填充的消息。是有效的。

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

为了使攻击起作用，必须满足以下条件：

• 您的应用程序必须给出有关填充无效的错误消息。
• 有人必须篡改您的加密cookie或viewstate

因此，如果您在应用中返回人类可读的错误消息，例如“出现问题，请重试”，那么您应该很安全。稍微阅读一下文章中的评论也会提供有价值的信息。

• 将会话ID存储在加密的Cookie中
• 将实际数据存储在会话状态（持久化在数据库中）
• 当用户信息错误时添加随机等待，然后返回错误，因此您无法计时

这样，被劫持的Cookie只能用于检索最有可能不再存在或无效的会话。

看看Ekoparty会议上实际介绍的内容将很有趣，但是现在我不太担心此漏洞。

了解填充Oracle攻击

假设您的应用程序接受加密的字符串作为参数-该参数是cookie，url参数还是其他无关紧要的参数。当应用程序尝试对其进行解码时，有3种可能的结果-

1. 结果1：加密的字符串已正确解密，应用程序能够理解它。这意味着，如果加密的字符串是10位数字的帐号，则在解密后，应用程序会发现类似“ 1234567890”而不是“ abcd1213ef”的内容

2. 结果2：填充是正确的，但解密后获得的字符串是乱码，应用程序无法理解。例如，该字符串解密为“ abcd1213ef”，但该应用程序仅期望数字。大多数应用会显示类似“无效帐号”的消息。

3. 结果3：填充不正确，应用程序引发了某种错误消息。大多数应用会显示一条通用消息，例如“发生某些错误”。

为了使Padding Oracle攻击成功，攻击者必须能够发出数千个请求，并且必须能够将响应分类为上述3个存储桶之一，并且没有错误。

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

可以采取什么预防措施？

1. 最简单的事情-绝不应该将任何敏感内容发送到客户端，无论是加密还是不加密。将其保留在服务器上。

2. 确保上面列表中的结果2和结果3 对攻击者看起来完全相同。应该没有办法找出另一个。但是，这并不是那么容易-攻击者可以使用某种定时攻击来进行区分。

3. 作为最后一道防线，请使用Web应用程序防火墙。padding oracle攻击需要发出几个看起来几乎相似的请求（一次更改一位），因此WAF应该有可能捕获并阻止此类请求。

PS可以在此博客文章中找到有关填充Oracle Attacks的很好解释。免责声明：这不是我的博客。

从我读到现在为止...

该攻击使某人可以解密嗅探的cookie，其中可能包含有价值的数据，例如银行余额

他们需要在任何帐户上已经登录的用户的加密cookie。他们还需要在cookie中查找数据-我希望开发人员不要在cookie中存储关键数据:)。而且我下面有一种方法可以让asp.net不在登录cookie中存储数据。

如果某人不使用浏览器数据，该如何获取在线用户的Cookie？还是嗅探IP数据包？

防止这种情况发生的一种方法是不使用ssl加密就不允许cookie传输。

<httpCookies httpOnlyCookies="true" requireSSL="true" />

另外一种措施是防止将角色存储在cookie中。

<roleManager enabled="true" cacheRolesInCookie="false">

现在，关于常规页面上不安全的cookie，这需要更多地考虑您留下给用户的内容和不做的事情，您如何信任他，可以执行哪些额外的检查（例如，如果在ip上看到更改） ，也许不要再信任他，直到从安全页面重新登录为止。

参考：
某些黑客可以从用户那里窃取Cookie并在网站上使用该名称登录吗？

如何检查攻击从何而来而不提供信息。我在这里写了一个简单的方法来防止填充无效，并同时记录日志以跟踪攻击者：CryptographicException：填充无效并且无法删除，并且视图状态MAC验证失败

跟踪攻击者的方法是检查填充无效。通过一个简单的过程，您就可以跟踪并阻止它们-他们需要在页面上数千次调用才能找到密钥！

更新1。

我已经下载了假设可以找到KEY并解密数据的工具，正如我所说的，它位于检查viewstate的上述代码中。根据我的测试，此工具还有很多要修复的功能，例如无法按原样扫描压缩的视图状态及其在我的测试中崩溃。

如果有人尝试使用此工具或这种方法，则上面的代码可以对其进行跟踪，您可以使用简单的代码（例如“防止拒绝服务（DOS）”）或类似的代码将其阻止出您的页面，以防止拒绝服务。

更新2

从我到目前为止阅读的内容来看，似乎唯一需要的是不要提供有关错误的信息，只是放置一个自定义错误页面，如果愿意，您可以创建并随机延迟该页面。

关于这个问题的非常有趣的视频

因此，上述所有措施都将采取更多措施来提供更多保护，但对于此特定问题，并非100％必要。例如，使用ssl cookie可以解决snif问题，不要将角色缓存在cookie中，最好不要发送并取回大的cookie，并避免某些已经准备好破解代码的人，只需将admin角色放在他的饼干。

viewstate仅跟踪发现攻击的一种措施。

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

编辑
这里是scottgu的一些更详细的信息。

添加来自http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx上讨论的ScottGu的回复

自定义IHttpModule而不是customErrors是否受到影响？

问：我的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上第二个博文中提供了其他常见问题解答。

IMO，对此没有全面的预防措施，需要逐案处理：

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

一些重要的链接：

• MS的安全建议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：添加到顶部的链接]

在对该问题进行了额外的研究之后，我刚刚在博客上发表了自己的观点。我认为，重要的是要弄清楚他们为什么要伪造auth cookie。

只想弄清楚一些事实：

1. 攻击无法让您直接获取机器密钥。就是说，它非常类似于它，因为它允许解密消息，并修改重新/加密新消息。
2. 获取实际密钥的方法是使用它们的能力（如1所示）修改re / encrypt并获取web.config。不幸的是，有一些原因使某些人将这些密钥放在站点级别的web.config中（不同的讨论），并且在示例视频中，它们受益于DotnetNuke的默认设置。
3. 要获得所有的web.config，则表明它们正在使用webresources.axd和/或scriptresources.axd。我认为这些仅适用于嵌入式资源，但事实并非如此。
4. 如果应用程序是asp.net MVC，则我们实际上并不需要webresources.axd和/或scriptresources.axd，因此可以将其关闭。我们也不使用viewstate。就是说，我不清楚是否有其他任何asp.net功能通过适当的解决方法提供了不同的信息，即我不知道填充在错误的身份验证票中填充有效结果时是否给无效结果提供错误（不知道如果是这样的话...）相同的分析应应用于会话Cookie。
5. asp.net成员资格提供程序在cookie中“缓存”角色，请将其关闭。

大约1，afaik加密的消息不能100％任意地需要在消息中的某个地方容忍一小段垃圾，因为消息中有1个块无法解密值。

最后，我想说的是，此问题是由于ms在这种情况下未遵循其自身指导的结果：功能依赖于发送给客户端的某些东西以防篡改。

更多关于：

我不知道填充是否会给无效的结果提供错误的结果，而填充有效的结果是否会被忽略的身份验证票证（不知道是否是这种情况）...相同的分析应该应用于会话cookie。

身份验证Cookie已签名，如果他们没有获得实际的密钥（如在伪造身份验证Cookie之前的视频中所做的那样），则他们不应该从论文中的信息生成签名的Cookie。

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

Windows Update已发布了针对该错误的补丁程序：http : //weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Asp.Net MVC也受此问题影响（Sharepoint等也是如此）

我在这里介绍了MVC的修复程序：ASP.NET MVC是否容易受到oracle填充攻击？