이 새로운 ASP.NET 보안 취약점은 얼마나 심각하며 어떻게 해결할 수 있습니까?

lottoking 2020. 5. 14. 08:25

이 새로운 ASP.NET 보안 취약점은 얼마나 심각하며 어떻게 해결할 수 있습니까?

방금 ASP.NET에서 새로 발견 된 보안 취약점에 대해 인터넷에서 읽었습니다. 자세한 내용은 여기를 참조하십시오.

문제는 ASP.NET이 AES 암호화 알고리즘을 구현하여 이러한 응용 프로그램이 사용자 세션 중에 정보를 저장하기 위해 생성하는 쿠키의 무결성을 보호하는 방식에 있습니다.

이것은 약간 모호하지만 여기에 더 무서운 부분이 있습니다.

공격의 첫 단계는 수천 건의 요청이 필요하지만 성공하면 공격자가 비밀 키를 받으면 완전히 은밀합니다. 필요한 암호 지식은 매우 기본적입니다.

전반적으로, 나는 이것이 정말로 심각한 지 알기 위해 보안 / 암호화 주제에 익숙하지 않습니다.

따라서 모든 ASP.NET 개발자 는 몇 초 안에 ASP.NET 웹 사이트를 소유 할 수있는 이 기술을 두려워 해야합니까?

이 문제는 평균 ASP.NET 개발자에게 어떤 영향을 줍니까? 그것은 우리에게 전혀 영향을 미칩니 까? 실제로이 취약점의 결과는 무엇입니까? 그리고 마지막으로 :이 취약점을 방지하는 해결 방법이 있습니까?

답변 주셔서 감사합니다!

편집 : 내가받은 응답을 요약 해 드리겠습니다

따라서 이것은 기본적으로 "패딩 오라클"유형의 공격입니다. @Sri 는 이러한 유형의 공격이 무엇을 의미하는지에 대한 훌륭한 설명을 제공했습니다. 이 문제에 대한 충격적인 비디오가 있습니다!

이 취약점의 심각성에 관하여 : 예, 실제로 심각합니다. 공격자는 응용 프로그램의 시스템 키를 알 수 있습니다. 따라서 그는 매우 원치 않는 일 을 할 수 있습니다 .

앱의 머신 키를 소유 한 공격자는 인증 쿠키를 해독 할 수 있습니다.
그보다 더 나쁜 것은 사용자 이름으로 인증 쿠키 를 생성 할 수 있다는 것입니다 . 따라서 그는 사이트의 모든 사람으로 나타날 수 있습니다. 응용 프로그램은 귀하 또는 귀하의 이름으로 인증 쿠키를 생성 한 해커를 구별 할 수 없습니다.
또한 이전 쿠키 만큼 위험하지는 않지만 세션 쿠키 를 해독 (및 생성) 할 수도 있습니다 .
그렇게 심각하지는 않습니다 : 그는 페이지의 암호화 된 ViewState를 해독 할 수 있습니다. (ViewState를 사용하여 자신감있는 데이터를 저장하는 경우 어쨌든 그렇게하지 않아야합니다!)
예상치 못한 공격 : 머신 키에 대한 지식으로 공격자 는 일반적으로 다운로드 할 수없는 파일을 포함하여 웹 응용 프로그램에서 임의의 파일을 다운로드 할 수 있습니다! ( Web.Config 등 포함 )

여기에 내가 가진 좋은 관행의 무리입니다 하지 않는 문제를 해결하지만, 도움이 웹 애플리케이션의 일반적인 보안을 향상은.

이제이 문제에 초점을 맞추겠습니다.

해결책

customErrors를 활성화하고 모든 오류 가 리디렉션 되는 단일 오류 페이지를 만듭니다 . 네, 심지어 404 . (ScottGu에 따르면이 공격에는 404와 500을 구분하는 것이 필수적이라고합니다.) 또한 무작위 지연을 유발하는 코드를 Application_Error넣거나 Error.aspx입력 하십시오 . 임의의 숫자를 생성하고 Thread.Sleep을 사용하여 오랫동안 잠자기 상태로 만듭니다. 그러면 공격자가 서버에서 정확히 무슨 일이 있었는지 결정할 수 없습니다.
어떤 사람들은 3DES로 다시 전환하는 것이 좋습니다. 이론적으로 AES를 사용하지 않으면 AES 구현에서 보안 취약점이 발생하지 않습니다. 결과적으로 이것은 전혀 권장되지 않습니다 .

다른 생각들

것으로 보인다 되지 모두 해결 방법이 좋은 충분하다 생각합니다.

내 질문에 답변 한 모든 사람에게 감사합니다. 이 문제뿐만 아니라 일반적으로 웹 보안에 대해 많이 배웠습니다. @Mikael의 답변을 수락 된 것으로 표시했지만 다른 답변도 매우 유용합니다.

자신을 보호하려면 어떻게해야합니까?

[2010-09-29 업데이트]

Microsoft 보안 게시판

수정 사항을 참조한 KB 기사

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.config는 대상이며 데이터베이스 연결 문자열에 로그인 정보와 같은 민감한 정보를 포함하거나 누군가가 원하지 않는 자동 SQL-Express 데이터베이스에 대한 링크를 포함 할 수 있습니다. 그러나 모범 사례를 따르는 경우 보호 된 구성 을 사용하여 web.config의 모든 중요한 데이터를 암호화합니다.

참조 링크

http://www.microsoft.com/technet/security/advisory/2416728.mspx 에서 취약점에 대한 Microsoft의 공식 의견을 읽어보십시오 . 특히이 문제에 대한 구현 세부 사항은 "해결 방법"부분입니다.

또한 웹 서버에서 취약한 ASP.Net 앱을 찾는 스크립트 를 포함하여 ScottGu의 블로그 에 대한 정보도 있습니다 .

"Padding Oracle Attacks 이해"에 대한 설명은 @ sri 's answer를 참조하십시오 .

기사에 대한 의견 :

Rizzo와 Duong이 ASP.NET 앱에 대해 구현 한 공격에는 웹 사이트의 암호화 구현에 암호문을 보낼 때 텍스트를 해독 할뿐만 아니라 발신자에게 암호문의 패딩 여부에 대한 메시지를 제공 하는 오라클이 있어야합니다. 유효합니다 .

패딩이 유효하지 않으면 발신자가받는 오류 메시지는 사이트의 암호 해독 프로세스 작동 방식에 대한 정보를 제공합니다.

공격이 작동하려면 다음 사항이 충족되어야합니다.

응용 프로그램은 유효하지 않은 패딩에 대한 오류 메시지를 제공해야합니다.
누군가 암호화 된 쿠키 또는 viewstate를 변조해야합니다

따라서 앱에서 "문제가 발생했습니다. 다시 시도하십시오" 와 같이 사람이 읽을 수있는 오류 메시지를 반환 하면 매우 안전해야합니다. 기사에 대한 의견을 조금 읽으면 소중한 정보를 얻을 수 있습니다.

암호화 된 쿠키에 세션 ID 저장
실제 데이터를 세션 상태로 저장 (db에 유지)
오류를 반환하기 전에 사용자 정보가 잘못되었을 때 무작위 대기를 추가하여 시간을 정할 수 없습니다

이렇게하면 하이재킹 된 쿠키를 사용하여 더 이상 존재하지 않거나 무효화 된 세션을 검색 할 수 있습니다.

Ekoparty 컨퍼런스에서 실제로 발표되는 내용을 보는 것이 흥미로울 것이지만 지금은이 취약점에 대해 너무 걱정하지 않습니다.

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 -

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"
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".
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?

Simplest thing - anything sensitive should never be sent to the client, encrypted or no encrypted. Keep it on the server.
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.
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.

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.

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.

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

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

A few significant links:

MS' Security Advisory 2416728 (this is the official information)
Additional information from MS' Security Research & Defence team
- "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)

[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]

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:

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.
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.
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.
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.
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.

'IT' 카테고리의 다른 글

HttpOnly 쿠키는 AJAX 요청과 어떻게 작동합니까? (0)	2020.05.14
cplusplus.com의 문제점은 무엇입니까? (0)	2020.05.14
NoSQL 데이터 저장소를 사용하여 어떤 확장 성 문제가 발생 했습니까? (0)	2020.05.14
NoSQL 데이터 저장소를 사용하여 어떤 확장 성 문제가 발생 했습니까? (0)	2020.05.14
github에서 검색하여 정확히 일치하는 항목을 얻는 방법 (예 : Google의 인용 부호) (0)	2020.05.14

현재글이 새로운 ASP.NET 보안 취약점은 얼마나 심각하며 어떻게 해결할 수 있습니까?

내가 바로 로또왕!

c++, 공연, 행사, 영화순위, 볼거리, spring, DVD순위, 축제, 놀거리, 무비순위, 여행, 연극, 관광, 자바, javascript, Java, jquery, C#, 뮤지컬, spring3,

Today :
Yesterday :

lottoking