这个新的 ASP.NET 安全漏洞有多严重,我该如何解决? [英] How serious is this new ASP.NET security vulnerability and how can I workaround it?

查看:43
本文介绍了这个新的 ASP.NET 安全漏洞有多严重,我该如何解决?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

<块引用>

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

这有点含糊,但这里有一个更可怕的部分:

<块引用>

攻击的第一阶段需要几千个请求,但一旦它成功,攻击者获得秘密钥匙,它是完全隐蔽的.所需的密码知识是非常基础.

总而言之,我对安全/加密主题不够熟悉,不知道这是否真的那么严重.

那么,所有 ASP.NET 开发人员是否应该害怕这种可以在几秒钟内拥有任何 ASP.NET 网站的技术?

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

感谢您的回答!

<小时>

让我总结一下我得到的回复

所以,这基本上是一种padding oracle"类型的攻击.@Sri 很好地解释了这种类型的攻击意味着什么.这是有关该问题的令人震惊的视频!

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

  • 拥有应用的机器密钥后,攻击者可以解密身份验证 cookie.
  • 更糟糕的是,他可以生成带有任何用户名的身份验证 cookie.因此,他可以作为网站上的任何人出现.该应用程序无法区分您或为自己生成带有您姓名的身份验证 cookie 的黑客.
  • 它还可以让他解密(并生成)会话 cookie,尽管这不像前一个那样危险.
  • 没那么严重:他可以解密页面的加密视图状态.(如果您使用 ViewState 存储机密数据,则无论如何都不应该这样做!)
  • 出乎意料:利用机器密钥的知识,攻击者可以下载您的网络应用程序中的任意文件,甚至是那些通常无法下载的文件!(包括Web.Config等)

以下是我得到的一系列良好做法,它们不会解决问题,但有助于提高网络应用程序的总体安全性.

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

解决办法

  • 启用 customErrors 并制作一个错误页面,所有错误都重定向到该页面.是的,甚至 404.(ScottGu 说区分 404 和 500 对这次攻击至关重要.)此外,在您的 Application_ErrorError.aspx 中放入一些可产生随机延迟的代码.(生成一个随机数,然后使用 Thread.Sleep 休眠那么长时间.)这将使攻击者无法确定您的服务器上究竟发生了什么.
  • 有些人建议改回 3DES.理论上,如果您不使用 AES,您就不会遇到 AES 实现中的安全弱点.事实证明,根本不推荐这样做.

其他一些想法

感谢所有回答我问题的人.我不仅学到了很多关于这个问题的知识,还学到了很多关于网络安全的知识.我将@Mikael 的答案标记为已接受,但其他答案也非常有用.

解决方案

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

[更新 2010-09-29]

微软安全公告

参考修复的知识库文章

ScottGu 有下载链接

[更新 2010-09-25]

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


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

另外在错误页面中添加随机时间睡眠以防止攻击者计时响应 用于添加攻击信息.

在 web.config 中

<预><代码><配置><location allowOverride="false"><system.web><customErrors mode="On" defaultRedirect="~/error.html"/></system.web></位置></配置>

这会将任何错误重定向到带有 200 状态代码的自定义页面.这样攻击者就无法通过查看错误代码或错误信息来获取进一步攻击所需的信息.

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

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

有什么利害关系?

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

参考文献链接

http://www.microsoft 阅读 Microsoft 对该漏洞的官方评论.com/technet/security/advisory/2416728.mspx.特别是有关此问题的实施细节的解决方法"部分.

还有一些关于ScottGu 的 博客,包括用于查找易受攻击的 ASP 的脚本.您的网络服务器上的网络应用.

有关了解填充 Oracle 攻击"的说明,请阅读 @sri 的回答.

<小时>

对文章的评论:

<块引用>

Rizzo 和 Duong 对 ASP.NET 应用程序实施的攻击要求加密网站上的实现有一个oracle,当发送密文时,不仅会解密文本但是给发送者一个关于密文中的填充是否有效的消息.

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

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

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

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

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

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

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

I've just read on the net about a newly discovered security vulnerability in ASP.NET. You can read the details here.

The problem lies in the way that ASP.NET implements the AES encryption algorithm to protect the integrity of the cookies these applications generate to store information during user sessions.

This is a bit vague, but here is a more frightening part:

The first stage of the attack takes a few thousand requests, but once it succeeds and the attacker gets the secret keys, it's totally stealthy.The cryptographic knowledge required is very basic.

All in all, I'm not familiar enough with the security/cryptograpy subject to know if this is really that serious.

So, should all ASP.NET developers fear this technique that can own any ASP.NET website in seconds or what?

How does this issue affect the average ASP.NET developer? Does it affect us at all? In real life, what are the consequences of this vulnerability? And, finally: is there some workaround that prevents this vulnerability?

Thanks for your answers!


EDIT: Let me summarize the responses I got

So, this is basically a "padding oracle" type of attack. @Sri provided a great explanation about what does this type of attack mean. Here is a shocking video about the issue!

About the seriousness of this vulnerability: Yes, it is indeed serious. It lets the attacker to get to know the machine key of an application. Thus, he can do some very unwanted things.

  • In posession of the app's machine key, the attacker can decrypt authentication cookies.
  • Even worse than that, he can generate authentication cookies with the name of any user. Thus, he can appear as anyone on the site. The application is unable to differentiate between you or the hacker who generated an authentication cookie with your name for himself.
  • It also lets him to decrypt (and also generate) session cookies, although this is not as dangerous as the previous one.
  • Not so serious: He can decrypt the encrypted ViewState of pages. (If you use ViewState to store confidental data, you shouldn't do this anyways!)
  • Quite unexpected: With the knowledge of the machine key, the attacker can download any arbitrary file from your web application, even those that normally can't be downloaded! (Including Web.Config, etc.)

Here is a bunch of good practices I got that don't solve the issue but help improve the general security of a web application.

Now, let's focus on this issue.

The solution

  • Enable customErrors and make a single error page to which all errors are redirected. Yes, even 404s. (ScottGu said that differentiating between 404s and 500s are essential for this attack.) Also, into your Application_Error or Error.aspx put some code that makes a random delay. (Generate a random number, and use Thread.Sleep to sleep for that long.) This will make it impossible for the attacker to decide what exactly happened on your server.
  • Some people recommended switching back to 3DES. In theory, if you don't use AES, you don't encounter the security weakness in the AES implementation. As it turns out, this is not recommended at all.

Some other thoughts

  • Seems that not everyone thinks the workaround is good enough.

Thanks to everyone who answered my question. I learned a lot about not only this issue, but web security in general. I marked @Mikael's answer as accepted, but the other answers are also very useful.

解决方案

What should I do to protect myself?

[Update 2010-09-29]

Microsoft security bulletin

KB Article with reference to the fix

ScottGu has links for the downloads

[Update 2010-09-25]

While we are waiting for the fix, yesterday ScottGu postet an update on how to add an extra step to protect your sites with a custom URLScan rule.


Basically make sure you provide a custom error page so that an attacker is not exposed to internal .Net errors, which you always should anyways in release/production mode.

Additionally add a random time sleep in the error page to prevent the attacker from timing the responses for added attack information.

In web.config

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

This will redirect any error to a custom page returned with a 200 status code. This way an attacker cannot look at the error code or error information for information needed for further attacks.

It is also safe to set customErrors mode="RemoteOnly", as this will redirect "real" clients. Only browsing from localhost will show internal .Net errors.

The important part is to make sure that all errors are configured to return the same error page. This requires you to explicitly set the defaultRedirect attribute on the <customErrors> section and ensure that no per-status codes are set.

What's at stake?

If an attacker manage to use the mentioned exploit, he/she can download internal files from within your web application. Typically web.config is a target and may contain sensitive information like login information in a database connection string, or even link to an automouted sql-express database which you don't want someone to get hold of. But if you are following best practice you use Protected Configuration to encrypt all sensitive data in your web.config.

Links to references

Read Microsoft's official comment about the vulnerability at http://www.microsoft.com/technet/security/advisory/2416728.mspx. Specifically the "Workaround" part for implementation details on this issue.

Also some information on ScottGu's blog, including a script to find vulnerable ASP.Net apps on your web server.

For an explanation on "Understanding Padding Oracle Attacks", read @sri's answer.


Comments to the article:

The attack that Rizzo and Duong have implemented against ASP.NET apps requires that the crypto implementation on the Web site have an oracle that, when sent ciphertext, will not only decrypt the text but give the sender a message about whether the padding in the ciphertext is valid.

If the padding is invalid, the error message that the sender gets will give him some information about the way that the site's decryption process works.

In order for the attack to work the following must be true:

  • Your application must give an error message about the padding being invalid.
  • Someone must tamper with your encrypted cookies or viewstate

So, if you return human readable error messages in your app like "Something went wrong, please try again" then you should be pretty safe. Reading a bit on the comments on the article also gives valuable information.

  • Store a session id in the crypted cookie
  • Store the real data in session state (persisted in a db)
  • Add a random wait when user information is wrong before returning the error, so you can't time it

That way a hijacked cookie can only be used to retrieve a session which most likely is no longer present or invalidated.

It will be interesting to see what is actually presented at the Ekoparty conference, but right now I'm not too worried about this vulnerability.

这篇关于这个新的 ASP.NET 安全漏洞有多严重,我该如何解决?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆