如何严重的是这种新的ASP.NET安全漏洞，我该怎么解决方法呢？ [英] How serious is this new ASP.NET security vulnerability and how can I workaround it?

问题描述

我刚刚读网有关ASP.NET中新发现的安全漏洞。 你可以在这里阅读详细信息。

  

问题在于方式   ASP.NET实现了AES加密   算法保护的完整性   饼干这些应用程序   生成期间存储信息   用户会话。<​​/ P>

这是一个有点模糊，但这里是一个更可怕的部分：

  

攻击的第一阶段需要   几千请求，但一旦它   成功，攻击者得到   密钥，这是完全stealthy.The   需要密码知识   非常基本的。

所有的一切，我不会与安全/ cryptograpy受到足够的熟悉，知道这是不是真的那么严重。

所以，应该都是ASP.NET开发人员担心这种技术的的可以根据自己在几秒钟内任何ASP.NET网站的还是什么？

如何这个问题影响到平均ASP.NET开发人员？它会影响我们呢？ 在现实生活中，什么是此漏洞的后果是什么？而且，最后：是有一些解决方法，prevents此漏洞

？

谢谢您的回答！

---

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

所以，这基本上是一个填充神谕类型的攻击。 <一href="http://stackoverflow.com/questions/3720720/how-serious-is-this-new-asp-net-security-vulnerability-and-how-can-i-workaround-i/3721473#3721473">@Sri提供什么呢这种类型的攻击平均的很好的解释。 下面是有关该问题的一个令人震惊的视频！

关于此漏洞的严重性：是的，这确实很严重。 它可以让攻击者了解应用程序的机器密钥。的这样，他就可以做一些非常不需要的东西。

• 在应用程序的计算机密钥的posession，攻击者可以解密身份验证Cookie。
• 甚至更糟糕的是，他能生成身份验证Cookie 与任何用户名。因此，他可以出现在任何人的网站。该应用程序无法您或谁产生你的名字为自己的身份验证cookie中的黑客来区分。
• 这也让他解密（也产生）会话cookie ，虽然这并不像previous一个作为危险。
• 没那么严重：他可以解密的网页加密的ViewState。 （如果你使用ViewState中存储保密的数据，你不应该这样做反正！）
• 颇为意外：随着计算机密钥的知识，攻击者的可以从你的web应用程序下载任意文件，甚至包括那些通常不能下载！ （包括 Web.config中等）

下面是一大堆我得到的不要解决这个问题，但有助于提高Web应用程序的总体安全。

良好做法

• 可以加密与保护配置
• 使用HTTP只有饼干
• prevent DoS攻击

现在，让我们关注这个问题。

• <一个href="http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx">Scott格思里发表了一篇关于它在自己的博客
条目
• <一个href="http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx">ScottGu's有关漏洞的常见问题解答博客帖子
• <一个href="http://weblogs.asp.net/scottgu/archive/2010/09/24/update-on-asp-net-vulnerability.aspx">ScottGu's更新漏洞
• 微软关于它的安全公告
• <一个href="http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx">Understanding该漏洞
• <一个href="http://blogs.technet.com/b/srd/archive/2010/09/20/additional-information-about-the-asp-net-vulnerability.aspx">Additional有关漏洞的信息

解决方案

• 启用的customErrors，使一个单一的错误页，所有错误被重定向。是的，甚至404 。 （ScottGu说，404和500系列之间的区别是这次攻击是必不可少的。）此外，到的Application_Error 或 Error.aspx 把一些code，使一个随机延迟。 （生成一个随机数，并使用了Thread.Sleep睡了多久了点。）这将使它无法攻击者来决定到底发生了什么你的服务器上。
• 在一些人建议切换回3DES。从理论上讲，如果你不使用AES，你没有遇到的AES实现的安全弱点。事实证明，这是不建议在所有

一些其他的想法

• 看来，不是 <一个href="http://blogs.microsoft.co.il/blogs/linqed/archive/2010/09/19/padding-oracle-asp-net-vulnerability-explanation.aspx">everyone认为解决办法是不够好。

谢谢大家谁回答我的问题。我学到了很多关于不仅仅是这个问题，但网络安全一般。标志着我@了Mikael的回答为接受，但其他的答案也非常有用。

解决方案

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

[更新：2010-09-29]

微软安全公告

知识库文章参照修复

<一个href="http://weblogs.asp.net/scottgu/archive/2010/09/28/asp-net-security-update-now-available.aspx">ScottGu有链接进行下载

[更新2010-09-25]

虽然我们正在等待修复，昨天ScottGu的 postet如何添加一个额外的步骤来保护你的站点自定义URLScan的规则更新。

---

基本上确保您提供自定义错误页，使攻击者不暴露内部的.Net错误，你应该这样做反正在发布/生产方式。

此外，在错误页面从添加一个随机时间睡眠prevent攻击时间响应，以增加攻击信息。

在web.config中

 ＆lt;结构＆GT;
 ＆LT;位置有的allowOverride =假＆GT;
   ＆LT;的System.Web＆GT;
     ＆LT;的customErrors模式=开的defaultRedirect =〜/的error.html/＆GT;
   ＆LT; /system.web>
 ＆LT; /地点＆gt;
＆LT; /结构＆gt;
 

这将重定向任何错误，以200状态code返回的自定义页面。这样，攻击者无法查看错误code或错误信息，需要进一步的攻击信息。

这也是安全设置的customErrors模式=仅限远程，因为这将重定向真实的客户端。只有从本地主机浏览显示内部净误差。

重要的部分是，以确保所有的错误被配置为返回相同的错误页面。这需要你明确地设置的defaultRedirect 属性上的＆LT;的customErrors＆GT; 部分，并确保没有按状态codeS设置。

什么是危机？

如果攻击者设法用提到利用时，他/她可以从你的web应用程序中下载的内部文件。通常情况下的web.config目标，且可能含有像一个数据库连接字符串的登录信息，甚至是链接到你不希望有人来弄个的automouted SQL-EX preSS数据库中的敏感信息。但是，如果你是以下最佳实践使用保护配置所有的敏感数据进行加密在您的网页。配置。

链接引用

阅读微软的有关漏洞的官方评论，在<一个href="http://www.microsoft.com/technet/security/advisory/2416728.mspx">http://www.microsoft.com/technet/security/advisory/2416728.mspx.特别是变通办法部分关于这个问题的实施细则。

另外在<一的一些信息href="http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx">ScottGu's博客，其中包括脚本来找到你的Web服务器上脆弱的ASP.Net应用程序。

有关谅解填充甲骨文攻击的解释，阅读<一个href="http://stackoverflow.com/questions/3720720/how-serious-is-this-new-asp-net-security-vulnerability-and-how-can-i-workaround-i/3721473#3721473">@sri's回答。

---

评论文章：

  

这佐和平阳已对ASP.NET应用程序中实现的攻击需要加密   实现对网站有Oracle，当发送密文，不仅将文解密   但给发件人的邮件约在密文填充是否有效。

     

如果填充是无效的，发件人得到错误信息会给他有关该网站的解密过程的工作方式的一些信息。

为了对此次袭击事件上班必须满足以下条件：

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

所以，如果你在你的应用程序一样返回人类可读的错误信息的出事了，请重试的，那么你应该是pretty的安全。读了一下就上文章的评论也给了有价值的信息。

• 存储会话ID的加密的cookie中
• 存储在会话状态的真实数据（保存在一个数据库）
• 添加一个随机等待时，用户信息是错误的返回错误之前，所以你不能计算准确

这种方式被劫持cookie只能被用于获取会话其中最有可能不再是present或无效。

这将是有趣的，看看什么是真正$ psented在Ekoparty会议p $，但现在我不是太担心这个漏洞。

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.

• You can encrypt sensitive data with Protected Configuration
• Use HTTP Only cookies
• Prevent DoS attacks

Now, let's focus on this issue.

• Scott Guthrie published an entry about it on his blog
• ScottGu's FAQ blog post about the vulnerability
• ScottGu's update on the vulnerability
• Microsoft has a security advisory about it
• Understanding the vulnerability
• Additional information about the vulnerability

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屋！