IIS Security Issue - Ability to view encrypted ViewState data

[bakedjake]

If you're not using custom error pages on IIS/ASP.net, you need to be concerned.

Microsoft is investigating a new public report of a vulnerability in ASP.NET. An attacker who exploited this vulnerability could view data, such as the View State, which was encrypted by the target server, or read data from files on the target server, such as web.config. This would allow the attacker to tamper with the contents of the data. By sending back the altered contents to an affected server, the attacker could observe the error codes returned by the server.

Vulnerability in ASP.NET Could Allow Information Disclosure [microsoft.com]

ScottGu's got more here [weblogs.asp.net]. Note that he recommends a single, solitary custom error page regardless of error returned. He also has a script to check if your are vulnerable or not.

Kaspersky has a video of the exploit being run on threatpost [threatpost.com].

No fix currently except the workaround mentioned above. Note that an attacker could use the vulnerability to read application configuration files containing keys or database passwords, so it's serious enough you should check it out as soon as possible.

[marcel]

Thanks for the info Jake.

[lavelle72]

"he recommends a single, solitary custom error page regardless of error returned"

What HTTP status? What are the implications of this for SEO?

[andyll]

200. The exploit counts on the different statuses.

It's also a .Net issue and not an IIS issue.

[mattglet]

Don't return a 200 for a status. Return a 500, with a customized error page. RTFA.

[bwnbwn]

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

Throw a 404 is the best option for all errors

[andyll]

Don't return a 200 for a status. Return a 500, with a customized error page. RTFA.

Scott Guthrie's workaround... which is in the advisory... returns a 200.

<customerrors/> by default returns a 200. ( or 302 200 if redirect is used)

As long as all error conditions return the same code it's fine.

Since this is a short term workaround ( I hope ) I personally decided not to send an error condition ever.

[mattglet]

Sorry andyll... looks *I* need to RTFA :)

I made that comment off of memory, and looks like my memory ain't all that good!

[andyll]

NP... you forced me to do a better header check and I found some conditions still returning a 404.

i couldn't decide what to return so I just decided on 200.

[g1smd]

Check your site for reported "soft 404 errors" in Google WMT.

[marcel]

ScottGu has posted an update:
[weblogs.asp.net...]

...This additional step can be done at a server-wide level, and should take less than 5 minutes to implement. Importantly, this step does not replace the other steps in the original workaround, rather it should be done in addition to the steps already in it...

[marcel]

An out of band Security Update addressing this issue will be released today:
ASP.NET Security Update Shipping Tuesday, Sept 28th [weblogs.asp.net]

[bwnbwn]

I haven't seen evidence of this being released has anyone seen the update?

Found it.
[microsoft.com...]