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

10 回答

• 58

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

  Is custom IHttpModule instead of customErrors affected?

  问：我的web.config中没有声明一个元素，而是在该部分中有一个IHttpModule . 此模块记录错误并重定向到搜索页面（对于404）或错误页面（对于500） . 我很脆弱吗？

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

  请注意，当修补程序出来修复此问题时，您不需要执行此操作（并且可以恢复为旧行为） . 但就目前而言，我建议不要将404s和500s区分给客户 .

  Can I continue using different errors for 404 and 500 errors?

  问：我认为除了默认的重定向错误外，我们仍然可以定义自定义404页面，而不违反上述原则？

  答：不 - 在我们发布真正修复的补丁之前，我们建议使用上述解决方法来均衡所有错误 . 此攻击的工作方式之一是寻找404和500错误之间的区别 . 始终返回相同的HTTP代码并将它们发送到同一位置是帮助阻止它的一种方法 .

  请注意，当修补程序出来修复此问题时，您不需要执行此操作（并且可以还原旧的行为） . 但就目前而言，您不应将404和500区分为客户 .

  How does this allow exposure of 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

  回复于 2024-05-19T00:58:36+08:00
• 13

  Asp.Net MVC也受此问题影响（正如Sharepoint，...）

  我在这里介绍了MVC的修复：Is ASP.NET MVC vulnerable to the oracle padding attack?

  回复于 2024-05-19T00:58:36+08:00
• 1

  从我读到现在......

  攻击允许某人解密嗅探的cookie，其中可能包含有 Value 的数据，如银行余额

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

  如果他没有掌握浏览器数据，有人如何获得在线用户的cookie？或者嗅探IP数据包？

  防止这种情况的一种方法是不允许cookie在没有ssl加密的情况下传输 .

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

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

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

  现在关于常规页面不安全的cookie，这需要更多的思考你离开你的用户做什么，不做什么，你如何信任他，你可以做多少检查（例如，如果你看到ip的变化，也许停止相信他，直到从安全页面重新登录） .

  参考：
  Can some hacker steal the cookie from a user and login with that name on a web site?

  How to check from where attacks 过来不回馈信息 . 我在这里写了一个简单的方法来防止填充无效并同时记录以追踪攻击者：CryptographicException: Padding is invalid and cannot be removed and Validation of viewstate MAC failed

  The way to track the attacker is to check the padding is invalid. With a simple procedure you can track them down and block them - they need some thousands of call on your page to find the key !

  更新1 .

  我已经下载了假设找到KEY并解密数据的工具，正如我在above code that's check the viewstate上所说的陷阱 . 从我的测试中，这个工具还有很多东西要修复，例如无法扫描压缩视图状态，以及它在我的测试中崩溃 .

  如果有人尝试使用此工具或此方法，则上述代码可以跟踪它们，您可以使用简单的代码阻止它们离开您的页面，例如"Prevent Denial Of Service (DOS)"或like this code for preventing Denial of service .

  更新2

  它似乎从我读到的直到现在 the only think that is really need it to not give information back about the error ，只是place a custom error page and if you like you can just create and a random delay to this page.

  a very interesting video关于这个问题 .

  所以上面所说的更多的措施是为了更多的保护而不是100％的必需品来解决这个问题 . 例如，使用ssl cookie解决了snif问题，没有缓存cookie中的角色很好，不发送和获取大cookie，并避免一些已经准备好破解代码，只需将管理员角色放在上面他的 Cookies .

  该视图状态跟踪其仅一个发现攻击的措施 .

  回复于 2024-05-19T00:58:36+08:00
• 12

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

  [Update 2010-09-29]

  Microsoft security bulletin

  KB Article with reference to the fix

  ScottGu有下载链接

  [Update 2010-09-25]

  虽然我们正在等待修复，但昨天ScottGu postet an update关于如何使用自定义URLScan规则添加额外步骤来保护您的网站 .

  ---

  基本上确保提供自定义错误页面，以便攻击者不会暴露于内部.Net错误，在发布/ 生产环境 模式下，您始终应该这样做 .

  此外，在错误页面中添加随机时间睡眠，以防止攻击者timing the responses添加攻击信息 .

  在web.config中

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

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

  设置 customErrors mode="RemoteOnly" 也是安全的，因为这将重定向"real"客户端 . 只有从localhost浏览才会显示内部.Net错误 .

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

  有什么危险？

  如果攻击者设法使用上述漏洞，他/她可以从您的Web应用程序中下载内部文件 . 通常，web.config是一个目标，可能包含敏感信息，如数据库连接字符串中的登录信息，甚至链接到您不希望有人获取的自动调试的sql-express数据库 . 但是，如果您遵循最佳实践，则使用Protected Configuration加密web.config中的所有敏感数据 .

  参考链接

  阅读微软的官方评论关于http://www.microsoft.com/technet/security/advisory/2416728.mspx的漏洞 . 具体来说"Workaround"部分是关于这个问题的实现细节 .

  还有一些关于ScottGu's博客的信息，包括script，以便在您的网络服务器上找到易受攻击的ASP.Net应用程序 .

  有关"Understanding Padding Oracle Attacks"的说明，请阅读@sri's answer .

  ---

  对文章的评论：

  Rizzo和Duong针对ASP.NET应用程序实施的攻击要求网站上的加密实现有一个oracle，当发送密文时，它不仅会解密文本，而且会向发送者发送有关填充是否填充的消息 . 密文有效 . 如果填充无效，则发件人获取的错误消息将为他提供有关网站解密过程的工作方式的一些信息 .

  为了使攻击有效，必须遵循以下规则：

  • 您的应用程序必须提供有关填充无效的错误消息 .

  • 有人必须篡改您的加密Cookie或查看状态

  因此，如果您在应用中返回人类可读的错误消息，如"Something went wrong, please try again"那么您应该非常安全 . 阅读有关该文章的评论也会提供有 Value 的信息 .

  • 将会话ID存储在加密的cookie中

  • 将实际数据存储在会话状态（持久存储在数据库中）

  • 在返回错误之前，在用户信息错误时添加随机等待，因此您无法计时

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

  看看Ekoparty Session 上实际呈现的内容会很有趣，但是现在我并不太担心这个漏洞 .

  回复于 2024-05-19T00:58:36+08:00
• 4

  Here是MS的回复 . 这一切归结为"use a custom error page"，你不会泄露任何线索 .

  EDIT
  Here是来自scottgu的一些更详细的信息 .

  回复于 2024-05-19T00:58:36+08:00
• 40

  一些重要的链接：

  • MS' Security Advisory 2416728（这是官方信息）

  • 来自MS'安全研究和国防团队的补充信息

  • "Understanding the ASP.NET Vulnerability" (2010-09-17)

  • "Additional Information about the ASP.NET Vulnerability" (2010-09-20)

  • Scott Gu: "Important: ASP.NET Security Vulnerability" (2010-09-18)

  [回答这个问题的严重性（已发表的内容和其他答案涵盖的解决方法） . ]

  被攻击的密钥用于保护视图状态和会话cookie . 通常，此密钥由ASP.NET在内部生成，每个新的Web应用程序实例 . 这将限制对工作进程生命周期的损害范围，当然对于繁忙的应用程序，这可能是几天（即没有太大的限制） . 在此期间，攻击者可以将值更改（或注入）到ViewState并更改其会话 .

  更严重的是，如果您希望会话能够跨越工作进程生命周期，或者允许Web场（即服务器场中的所有实例都可以处理任何用户会话），则需要对密钥进行硬编码，这在_258108中完成：

  [...]
    <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：添加到顶部的链接]

  回复于 2024-05-19T00:58:36+08:00
• 12

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

  回复于 2024-05-19T00:58:36+08:00
• 2

  Understanding Padding Oracle Attacks

  让我们假设你的应用程序接受一个加密的字符串作为参数 - 参数是cookie，url参数还是别的东西都是无关紧要的 . 当应用程序尝试解码时，有3种可能的结果 -

  • Outcome 1 ：加密的字符串正确解密，应用程序能够理解它 . 这意味着，如果加密的字符串是一个10位数的帐号，解密后应用程序发现"1234567890"而不是"abcd1213ef"

  • Outcome 2 ：填充是正确的，但在解密后，获得的字符串是应用程序无法理解的乱码 . 例如，字符串解密为"abcd1213ef"，但应用程序只期待数字 . 大多数应用都会显示如"Invalid account number"的消息 .

  • Outcome 3 ：填充不正确，应用程序抛出了某种错误消息 . 大多数应用都会显示像"Some error occurred"这样的通用消息 .

  为了使Padding Oracle攻击成功，攻击者必须能够发出数千个请求， and 必须能够将响应分类到上述3个桶中的一个而不会出错 .

  如果满足这两个条件，攻击者最终可以解密该消息，然后用他想要的任何内容重新加密它 . 这只是一个时间问题 .

  What can be done to prevent it?

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

  • 确保上述列表中的结果2和结果3与攻击者完全相同 . 应该没有办法从另一个中找出一个 . 这不是全部但是很容易 - 攻击者可以使用某种定时攻击进行区分 .

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

  附：填充Oracle攻击的一个很好的解释可以在this blog post中找到 . 免责声明：这不是我的博客 .

  回复于 2024-05-19T00:58:36+08:00
• 2

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

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

  回复于 2024-05-19T00:58:36+08:00
• 3

  在对该问题进行额外研究之后，我刚刚发表了对这个in my blog的全部看法 . 我认为重要的是清除他们为什么要伪造一个auth cookie .

  ---

  只想直接了解一些事实：

  • 攻击不允许您直接获取机器密钥 . 也就是说，它非常像它，因为它允许解密消息，并修改重新加密/加密新消息 .

  • 获取实际密钥的方式是使用他们修改re / encrypt的能力，如1和获取web.config . 不幸的是，有些原因使得某些人将这些密钥放在网站级别的web.config中（不同的讨论），并且在示例视频中他们从中受益于DotnetNuke的默认值 .

  • 获取web.config所有指向他们正在使用webresources.axd和/或scriptresources.axd . 我认为这些只适用于嵌入式资源，但似乎并非如此 .

  • 如果应用程序是asp.net MVC，我们不要使用viewstate . 也就是说，我不清楚，如果任何其他asp.net功能提供不同的信息与现有的解决方法，即我不知道是否的情况）...相同的分析应适用于会话cookie .

  • asp.net会员提供商'caches'在cookies中的角色，关闭它 .

  大约1，afaik加密消息不能100％任意需要容忍消息中某处的一小块垃圾，因为消息中有1个块解密了无法控制的值 .

  最后，我想说这个问题是ms在这种情况下不遵循自己的指导的结果：一个功能依赖于发送给客户端的东西是防篡改的 .

  ---

  更多关于：

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

  auth cookie已签名，如果他们没有获得实际密钥，他们就不应该从文件中的信息生成签名cookie（就像他们在伪造auth cookie之前在视频中所做的那样） .

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

  回复于 2024-05-19T00:58:36+08:00