当前位置： 文江博客话题详情

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

发布于 2024-09-18 23:44:02 字数 3598 浏览 6 评论 0原文

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

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

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

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

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

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

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

感谢您的回答！

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

所以，这基本上是一种“填充预言”类型的攻击。 @Sri 对这种类型的攻击的含义提供了很好的解释。 这是有关此问题的令人震惊的视频！

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

  • 拥有应用程序的机器密钥后，攻击者可以解密身份验证 cookie。
  • 更糟糕的是，他可以使用任何用户的名称生成身份验证cookie。因此，他可以以任何人的身份出现在网站上。该应用程序无法区分您或使用您的名字生成身份验证 cookie 的黑客。
  • 它还允许他解密（并生成）会话 cookie，尽管这不像前一个那样危险。
  • 没那么严重：他可以解密页面的加密ViewState。 （如果您使用 ViewState 来存储机密数据，无论如何您都不应该这样做！）
  • 非常意外：凭借机器密钥的知识，攻击者可以下载任意任意内容从您的网络应用程序中下载文件，即使是那些通常无法下载的文件！ （包括Web.Config等）

这里有一些我得到的良好实践，不能解决问题，但有助于提高Web应用程序的总体安全性。

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

解决方案

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

其他一些想法

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

原文

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.

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（10）

裂开嘴轻声笑有多痛 2024-09-25 23:44:02

我应该做什么来保护自己？

[更新 2010-09-29]

Microsoft安全公告

参考修复的知识库文章

ScottGu 有下载链接

< strong>[更新 2010-09-25]

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

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.

另外，在错误页面中添加随机时间睡眠，以防止攻击者对响应进行计时攻击信息。

在 web.config 中，

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

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

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

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

有什么危险？

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

参考链接

请阅读 Microsoft 关于该漏洞的官方评论，网址为 http://www.microsoft .com/technet/security/advisory/2416728.mspx。具体来说，“解决方法”部分提供了有关此问题的实施细节。

还有一些关于 ScottGu 的< /a> 博客，包括一个脚本，用于查找易受攻击的 ASP.Net 应用程序你的网络服务器。

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

文章评论：

Rizzo 和 Duong 针对 ASP.NET 应用程序实施的攻击要求加密
网站上的实现有一个预言机，当发送密文时，它不仅会解密文本
但向发送者提供有关密文中的填充是否有效的消息。

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

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

  • 您的应用程序必须给出有关填充无效的错误消息。
  • 一定有人篡改了您的加密 cookie 或视图状态

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

  • 在加密的cookie中存储一个会话id
  • 将真实的数据存储在会话状态中（持久化在数据库中）
  • 当用户信息错误时在返回错误之前添加随机等待，这样你就无法计时

这样一个被劫持的cookie只能是用于检索很可能不再存在或失效的会话。

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

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.

回复 原文
白色秋天 2024-09-25 23:44:02

了解 Padding Oracle 攻击

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

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

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

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

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

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

可以采取什么措施来防止这种情况？

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

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

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

PS 关于 Padding Oracle 攻击的详细解释可以在 这篇博文。免责声明：这不是我的博客。

Understanding Padding Oracle Attacks

Lets assume your application accepts an encrypted string as a parameter - whether the parameter is a cookie, a url parameter or something else is immaterial. When the application tries to decode it, there are 3 possible outcomes -

  1. Outcome 1 : The encrypted string decrypted properly, and the application was able to make sense of it. Meaning, if the encrypted string was an 10 digit account number, after decryption the application found something like "1234567890" and not "abcd1213ef"

  2. Outcome 2 : The padding was correct, but after decryption the string obtained was gibberish that the app couldn't understand. For example, the string decrypted to "abcd1213ef", but the app was expecting only numbers. Most apps will show a message like "Invalid account number".

  3. Outcome 3 : The padding was incorrect, and the application threw some kind of error message. Most apps will show a generic message like "Some error occurred".

In order for a Padding Oracle attack to be successful, the attacker must be able to make several thousands of requests, and must be able to classify the response into one of the above 3 buckets without error.

If these two conditions are met, the attacker can eventually decrypt the message, and then re-encrypt it with whatever he wishes. Its just a question of time.

What can be done to prevent it?

  1. Simplest thing - anything sensitive should never be sent to the client, encrypted or no encrypted. Keep it on the server.

  2. Make sure that outcome 2 and outcome 3 in the above list appear exactly the same to the attacker. There should be no way to figure out one from the other. This is not all that easy, though - an attacker can discriminate using some kind of timing attack.

  3. As a last line of defence, have a Web Application Firewall. The padding oracle attack needs to make several requests that look almost similar (changing one bit at a time), so it should be possible for a WAF to catch and block such requests.

P.S. A good explanation of Padding Oracle Attacks can be found in this blog post. Disclaimer: Its NOT my blog.

回复 原文
固执像三岁 2024-09-25 23:44:02

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

该攻击允许某人解密
嗅探 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 并使用该用户名登录网站吗？

如何检查攻击来自何处并且不返回信息。我在这里写了一个简单的方法来防止填充无效并同时记录以追踪攻击者： cannot-be-removed-and-validation-o/2551810#2551810">CryptographicException：填充无效且无法删除且视图状态 MAC 验证失败

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

更新1。

我已经下载了假设可以找到密钥并解密数据的工具，正如我所说，它的陷阱 上面的代码检查视图状态。根据我的测试，该工具还有很多需要修复的地方，例如无法按原样扫描压缩视图状态以及在我的测试中崩溃。

如果有人尝试使用此工具或此方法，上面的代码可以追踪他们，您可以使用像这样的简单代码将他们阻止在您的页面之外 “防止拒绝服务 (DOS)”，或 喜欢此代码以防止拒绝服务。

更新2

从我到目前为止所读到的内容来看，唯一认为真正需要的是不返回有关错误的信息，而只是放置一个自定义错误页面，如果您愿意，您可以创建此页面并随机延迟。

关于此问题的一个非常有趣的视频。

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

视图状态跟踪只是发现攻击的又一项措施。

From what I read until now...

The attack allows someone to decrypt
sniffed cookies, which could contain
valuable data such as bank balances

They need the encrypted cookie of a user that have been already logged in, on any account. They also need to find data in cookies - I hope that developers do not store critical data in cookies :). And there is a way that I have below to not let asp.net store data in the login cookie.

How can someone get the cookie of a user that is online if he doesn't get his hands on the browser data? Or sniff the IP packet ?

One way to prevent that is to not allow cookies to transport without ssl encryption.

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

Also one more measure is to prevent storing Roles in cookies.

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

Now about the cookies that are not secure for the regular pages, this needs some more thinking what you left your user do and what not, how you trust him, what extra check you can do (for example if you see a change on the ip, maybe stop trust him until relogin from security page).

Reference:
Can some hacker steal the cookie from a user and login with that name on a web site?

How to check from where attacks come and not give back informations. I wrote here a simple way to prevent the padding is invalid and logging at the same time to track down attackers: 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 !

Update 1.

I have download the tool that suppose that's find the KEY and decrypt the data, and as I say its trap on the above code that's check the viewstate. From my tests this tool have many more to fix, for example can not scan compressed view state as it is and its crash on my tests.

If some one try to use this tool or this method the above code can track them down and you can block them out of your page with simple code like this one "Prevent Denial Of Service (DOS)", or like this code for preventing Denial of service.

Update 2

Its seems from what I read until now that the only think that is really need it to not give information back about the error, and just place a custom error page and if you like you can just create and a random delay to this page.

a very interesting video on this issue.

So all the above its more measure for more protections but not 100% necessaries for this particular issue. For example to use ssl cookie is solve the snif issue, the not cache the Roles in cookies it good to not send and get back big cookies, and to avoid some one that have all ready crack the code, to just place the admin role on the cookie of him.

The viewstate track its just one more measure to find attack.

回复 原文
凉风有信 2024-09-25 23:44:02

此处 是 MS 响应。这一切都归结为“使用自定义错误页面”，并且您不会泄露任何线索。

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

Here is the MS response. It all boils down to "use a custom error page" and you won't be giving away any clues.

EDIT
Here is some more detailed info from scottgu.

回复 原文
奢华的一滴泪 2024-09-25 23:44:02

添加 ScottGu 在 http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

改为自定义 IHttpModule受影响的自定义错误数？

问：我的 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

Adding ScottGu's responses taken from discussion at http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

Is custom IHttpModule instead of customErrors affected?

Q: I don't have a element declared in my web.config, I have instead an IHttpModule inside the section. This module logs the error and redirects to either a search page (for 404's) or to an error page (for 500's). Am I vulnerable?

A: I would recommend temporarily updating the module to always redirect to the search page. One of the ways this attack works is that looks for differentiation between 404s and 500 errors. Always returning the same HTTP code and sending them to the same place is one way to help block it.

Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior). But for right now I'd recommend not differentiating between 404s and 500s to clients.

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

Q: I take it we can still have a custom 404 page defined in addition to the default redirect on error, without violating the principles described above?

A: No - until we release a patch for the real fix, we recommend the above workaround which homogenizes all errors. One of the ways this attack works is that looks for differentiation between 404s and 500 errors. Always returning the same HTTP code and sending them to the same place is one way to help block it.

Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior). But for right now you should not differentiate between 404s and 500s to clients.

How does this allow exposure of web.config?

Q: How does this allow exposure of web.config? This seems to enable decrypting of ViewState only, is there another related vulnerability that also allows the information disclosure? Is there a whitepaper that details the attack for a better explanation of what's going on?

A: The attack that was shown in the public relies on a feature in ASP.NET that allows files (typically javascript and css) to be downloaded, and which is secured with a key that is sent as part of the request. Unfortunately if you are able to forge a key you can use this feature to download the web.config file of an application (but not files outside of the application). We will obviously release a patch for this - until then the above workaround closes the attack vector.

EDIT: additional FAQ available in the second blogpost at http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

回复 原文
绿阴红影里的.如风往事 2024-09-25 23:44:02

IMO，对此没有全面的预防措施，需要根据具体情况进行处理：

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

IMO, there is no across-the-board prevention for this, it needs to be handled on a case-by-case basis:

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

回复 原文
可爱暴击 2024-09-25 23:44:02

一些重要的链接：

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

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

更严重的是，如果您希望会话能够跨越工作进程的生命周期，或者允许 Web 场（即场中的所有实例都可以处理任何用户会话），则需要对密钥进行硬编码，这是在 web.xml 中完成的。 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：添加链接到顶部]

A few significant links:

[To answer the seriousness aspect of this (what has been published and workarounds are covered by other answers).]

The key being attacked is used to protect both view state and session cookies. Normally this key is generated internally by ASP.NET with each new instance of the web app. This will limit the scope of damage to the lifetime of the worker process, of course for a busy application this could be days (i.e. not much of a limit). During this time the attacker can change (or inject) values into the ViewState and change their session.

Even more seriously if you want sessions to be able to span worker process lifetimes, or allow web farms (i.e. all instances in the farm can handle any user session) the key needs to be hard coded, this is done in web.config:

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

Those are, of course, newly created keys, I use the following PowerShell to access Windows cryptographic random number generator:

$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}

(Using an array length of 20 for the validation and 16 for the decryption keys.)

As well as modifying the public error pages to not leak the specific error, it would seem a good time to change the above keys (or cycle worker processes if they have been running for a while).

[Edit 2010-09-21: Added links to top]

回复 原文
冬天旳寂寞 2024-09-25 23:44:02

我刚刚发布了对此的完整看法 在我的博客中，经过对这个问题的额外研究。我认为弄清楚他们为什么要伪造身份验证 cookie 很重要。

只是想弄清楚一些事实：

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

关于1，据我所知，加密的消息不能100%任意，需要容忍消息中某处的一小块垃圾，因为消息中有1个块解密了无法控制的值。

最后我想说，这个问题是微软在这种情况下没有遵循自己的指导的结果：某个功能依赖于发送给客户端的防篡改内容。

更多关于：

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

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

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

I just posted my full take on this in my blog, after extra research on the issue. I think its important clearing out why they are getting as far as forging an auth cookie.

Just want to get some facts straight:

  1. attack doesn't let you get the machine key directly. That said, its pretty much like it had, as it allows to decrypt the messages, and modify re/encrypt new ones.
  2. the way the get the actual keys is by using their ability to modify re/encrypt as in 1 and get the web.config. Unfortunately there are reasons why some put these keys in the web.config at the site level (different discussion), and in the sample video they benefit from that being the default of DotnetNuke.
  3. to get the web.config all out there points to that they are using webresources.axd and/or scriptresources.axd. I thought these worked only with embedded resources, but it seems that's just not the case.
  4. if the app is asp.net MVC we don't really need webresources.axd and/or scriptresources.axd, so those can be turned off. We also don't use viewstate. That said, its unclear to me if any of the other asp.net features gives different info with the workaround in place i.e. I don't know if padding gives invalid results in error while padding valid results in ignored authentication ticket (don't know if its or not the case) ... the same analysis should apply to the session cookie.
  5. asp.net membership provider 'caches' roles in cookies, turn that off.

About 1, afaik the encrypted messages can't be 100% arbitrary need to tolerate a tiny piece of garbage somewhere in the message, as there is 1 block in the message which decrypt value that can't be controlled.

Finally I would like to say that this issue is the result of ms not following its own guidance in this case: a feature relies on something sent to the client being tamper proof.

More on:

I don't know if padding gives invalid results in error while padding valid results in ignored authentication ticket (don't know if its or not the case) ... the same analysis should apply to the session cookie.

The auth cookie is signed, and from the info in the paper they shouldn't be able to generate a signed cookie if they don't get to the actual keys (as they did in the video before forging the auth cookie).

As Aristos mentioned, for the session id in the cookie, that's random for the user session, so it'd have to be sniffed from an user with the target security level and cracked while that session is active. Even then if you are relying in authentication to assign/authorize the user operations, then the impact would be minimal / it'd depends a lot in what Session is used for in that app.

回复 原文
鸠魁 2024-09-25 23:44:02

Asp.Net MVC 也受到这个问题的影响（Sharepoint 也是如此，...）

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

Asp.Net MVC is also affected by this problem (as is Sharepoint, ...)

I've covered the fix for MVC here: Is ASP.NET MVC vulnerable to the oracle padding attack?

回复 原文
~没有更多了~

关于作者

别靠近我心

暂无简介

0 文章
0 评论
22 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

留蓝

文章 0 评论 0

18790681156

文章 0 评论 0

zach7772

文章 0 评论 0

Wini

文章 0 评论 0

ayeshaaroy

文章 0 评论 0

初雪

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文