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

Question

我刚刚在网上看到了ASP.NET中新发现的安全漏洞.你可以在这里阅读详细信息.

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

这有点模糊,但这里有一个更令人恐惧的部分:

攻击的第一阶段需要几千个请求,但一旦成功并且攻击者获得了密钥,它就完全是隐秘的.所需的加密知识是非常基本的.

总而言之,我对安全性/密码学不够熟悉,但要知道这是否真的那么严重.

那么,是否所有ASP.NET开发人员都担心这种技术可以在几秒钟内拥有任何ASP.NET网站或者什么？

这个问题如何影响普通的ASP.NET开发人员？它会影响我们吗？在现实生活中,这个漏洞的后果是什么？最后:是否有一些可以防止此漏洞的解决方法？

谢谢你的回答!

---

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

所以,这基本上是一种"填充oracle"类型的攻击.@Sri提供了一个很好的解释,说明这种类型的攻击是什么意思.这是一个关于这个问题的令人震惊的视频!

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

• 在应用程序的机器密钥的位置,攻击者可以解密身份验证cookie.
• 更糟糕的是,他可以使用任何用户的名称生成身份验证cookie.因此,他可以像网站上的任何人一样出现.应用程序无法区分您或为您自己生成身份验证cookie的黑客.
• 它还允许他解密(并生成)会话cookie,尽管这不像前一个那样危险.
• 不那么严重:他可以解密加密的ViewState页面.(如果您使用ViewState存储确信数据,则不应该这样做!)
• 非常意外:凭借对机器密钥的了解,攻击者可以从您的Web应用程序下载任意文件,即使是那些通常无法下载的文件!(包括Web.Config等)

以下是一些我没有解决问题的良好实践,但有助于提高Web应用程序的一般安全性.

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

现在,让我们关注这个问题.

• Scott Guthrie在他的博客上发表了一篇关于它的文章
• 关于漏洞的ScottGu的FAQ博客文章
• ScottGu关于漏洞的更新
• 微软有一个关于它的安全公告
• 了解漏洞
• 有关此漏洞的其他信息

解决方案

• 启用customErrors并创建一个错误页面,重定向所有错误.是的,甚至404s.(ScottGu说,区分404s和500s对于这次攻击至关重要.)另外,进入你的Application_Error或者Error.aspx放一些随机延迟的代码.(生成一个随机数,并使用Thread.Sleep长时间休眠.)这将使攻击者无法确定您的服务器上究竟发生了什么.
• 有些人建议切换回3DES.理论上,如果您不使用AES,则不会遇到AES实现中的安全漏洞.事实证明,根本不建议这样做.

其他一些想法

• 似乎并非 所有人都认为解决方法已经足够好了.

感谢所有回答我问题的人.我不仅了解了这个问题,还了解了网络安全性.我将@ Mikael的答案标记为已被接受,但其他答案也非常有用.

Answer 1

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

[更新2010-09-29]

Microsoft安全公告

知识库文章参考了修复

ScottGu有下载链接

[更新2010-09-25]

在我们等待修复的同时,昨天ScottGu发布了有关如何使用自定义URLScan规则添加额外步骤以保护您的网站的更新.

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

此外,在错误页面中添加随机时间睡眠,以防止攻击者对响应添加攻击信息.

在web.config中

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

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

设置也是安全的customErrors mode="RemoteOnly",因为这将重定向"真实"客户端.只有从localhost浏览才会显示内部.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,当发送密文时,它不仅会解密文本,而且会向发送者发送关于密文中是否填充的消息是有效的.

如果填充无效,则发件人获取的错误消息将为他提供有关网站解密过程的工作方式的一些信息.

为了使攻击有效,必须遵循以下规则:

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

因此,如果您在应用中返回人类可读的错误消息,例如"出错了,请再试一次",那么您应该非常安全.阅读有关该文章的评论也会提供有价值的信息.

• 将会话ID存储在加密的cookie中
• 将实际数据存储在会话状态(持久存储在数据库中)
• 在返回错误之前,在用户信息错误时添加随机等待,这样您就无法计时

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

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

Answer 2

了解填充Oracle攻击

让我们假设您的应用程序接受加密的字符串作为参数 - 参数是cookie,url参数还是其他不重要的东西.当应用程序尝试解码时,有3种可能的结果 -

1. 结果1:加密的字符串正确解密,应用程序能够理解它.意思是,如果加密的字符串是一个10位数的帐号,解密后应用程序发现类似"1234567890"而不是"abcd1213ef"

2. 结果2:填充是正确的,但在解密后,获得的字符串是应用程序无法理解的乱码.例如,字符串解密为"abcd1213ef",但应用程序只期待数字.大多数应用都会显示"无效的帐号"等消息.

3. 结果3:填充不正确,应用程序抛出了某种错误消息.大多数应用都会显示一般信息,例如"发生了一些错误".

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

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

可以采取哪些措施来防止它？

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

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

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

PS在这篇博客文章中可以找到Padding Oracle Attacks的一个很好的解释.免责声明:不是我的博客.

Answer 3

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

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

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

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

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

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

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

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

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

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

如何检查攻击的来源,而不是回馈信息.我在这里写了一个简单的方法来防止填充无效并同时记录以跟踪攻击者:CryptographicException:填充无效且无法删除并且验证viewstate MAC失败

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

更新1.

我已经下载了假设找到KEY并解密数据的工具,正如我在上面的代码中所说的那样检查视图状态.从我的测试中,这个工具还有很多东西要修复,例如无法扫描压缩视图状态,以及它在我的测试中崩溃.

如果有人试图使用这个工具或这个方法,上面的代码可以跟踪它们,你可以使用像"防止拒绝服务(DOS)"这样的简单代码阻止它们,或者像这个代码一样防止拒绝服务.

更新2

它似乎从我读到的,直到现在,唯一的想法是真的需要它不提供有关错误的信息,并且只是放置一个自定义错误页面,如果你喜欢你可以创建和随机延迟到这个页面.

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

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

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

Answer 4

这是MS的回复.这一切都归结为"使用自定义错误页面",你不会泄露任何线索.

编辑
以下是来自scottgu的更详细信息.

Answer 5

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

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

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

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

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

我可以继续为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