Welcome to WebmasterWorld Guest from 54.162.76.55

Forum Moderators: ocean10000

Message Too Old, No Replies

IIS Security Issue - Ability to view encrypted ViewState data

     
3:28 pm on Sep 20, 2010 (gmt 0)

Administrator from CA 

WebmasterWorld Administrator bakedjake is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month

joined:Apr 8, 2003
posts:3878
votes: 57


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.
5:30 pm on Sept 20, 2010 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Feb 1, 2005
posts:732
votes: 0


Thanks for the info Jake.
3:52 am on Sept 23, 2010 (gmt 0)

New User

5+ Year Member

joined:Dec 10, 2008
posts: 11
votes: 0


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

What HTTP status? What are the implications of this for SEO?
9:28 pm on Sept 23, 2010 (gmt 0)

Junior Member

10+ Year Member

joined:Jan 30, 2004
posts:127
votes: 0


200. The exploit counts on the different statuses.

It's also a .Net issue and not an IIS issue.
11:18 pm on Sept 23, 2010 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Nov 12, 2002
posts:1482
votes: 0


Don't return a 200 for a status. Return a 500, with a customized error page. RTFA.
5:42 am on Sept 24, 2010 (gmt 0)

Senior Member

WebmasterWorld Senior Member bwnbwn is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month

joined:Oct 25, 2005
posts:3541
votes: 19


"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
7:03 am on Sept 24, 2010 (gmt 0)

Junior Member

10+ Year Member

joined:Jan 30, 2004
posts:127
votes: 0



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.
11:58 am on Sept 24, 2010 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Nov 12, 2002
posts:1482
votes: 0


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

I made that comment off of memory, and looks like my memory ain't all that good!
5:23 pm on Sept 24, 2010 (gmt 0)

Junior Member

10+ Year Member

joined:Jan 30, 2004
posts:127
votes: 0


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.
6:39 pm on Sept 24, 2010 (gmt 0)

Senior Member

WebmasterWorld Senior Member g1smd is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month

joined:July 3, 2002
posts:18903
votes: 0


Check your site for reported "soft 404 errors" in Google WMT.
7:04 am on Sept 27, 2010 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Feb 1, 2005
posts:732
votes: 0


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...
7:44 am on Sept 28, 2010 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Feb 1, 2005
posts:732
votes: 0


An out of band Security Update addressing this issue will be released today:
ASP.NET Security Update Shipping Tuesday, Sept 28th [weblogs.asp.net]
1:26 pm on Sept 29, 2010 (gmt 0)

Senior Member

WebmasterWorld Senior Member bwnbwn is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month

joined:Oct 25, 2005
posts:3541
votes: 19


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

Found it.
[microsoft.com...]