[WEB SECURITY] RE: Trustwave's SpiderLabs Security Advisory TWSL2010-001

Chris Weber chris at casabasec.com
Sat Feb 13 02:30:47 EST 2010


This seems a much better description of the problem than the original advisory.  Though I suspected something like this I wasn't clear before that the control was inherently rendering VIEWSTATE data as 'innerHtml'.  Good finding.  

However, the real issue seems to be with the 'controls' being vulnerable, not the viewstate.  After all, VIEWSTATE is still just a delivery mechanism no different than other request or POST data. The controls are what are acting dangerously here.

    "There are other .Net controls that take properties from the view state that may also be vulnerable. 
     Enumerating them is not very helpful   because the solution will always be the same: 
    secure the view state."

Or stated another way - don't unsecure it.  It seems secured by default after all (contrary to MSDN documentation http://msdn.microsoft.com/en-us/library/system.web.ui.page.enableviewstatemac.aspx ).  However I disagree with your take -  there does seem value in enumerating the vulnerable controls.  In the cases where developers need to disable VIEWSTATE's builtin security (which Arian sees as common), it gives them some options:

- avoid using the dangerous controls
- implement overrides for the affected subclasses or methods

Best regards,
Chris Weber

P.S. I see the vulnerable code in reflector but I can't repro using your example.


-----Original Message-----
From: David Byrne [mailto:DByrne at trustwave.com] 
Sent: Friday, February 12, 2010 6:50 PM
To: websecurity at webappsec.org
Subject: [WEB SECURITY] RE: Trustwave's SpiderLabs Security Advisory TWSL2010-001

I respectfully defend our statement as very realistic. The .Net exploit provided in the advisory is all that is required to work; no code-behind is required because the vulnerability related to "innerhtml" lies in the .Net code. 

The specific flaw is actually in System.Web.UI.HTMLControls.HtmlContainerControl class, which is the super class of the HTMLForm control (among others). The bug is easy to spot in the LoadViewState method as revealed in .Net Reflector:


protected override void LoadViewState(object savedState)
{
    if (savedState != null)
    {
        base.LoadViewState(savedState);
        string text = (string) this.ViewState["innerhtml"];
        if (text != null)
        {
            this.Controls.Clear();
            this.Controls.Add(new LiteralControl(text));
        }
    }
}

 
For those not familiar with C#, the .Net class takes the "innerhtml" value from the view state and adds it as a LiteralControl (basically literal HTML) in its "Controls" collection. When the HtmlContainerControl object is rendered, it will take that LiteralControl and place HTML directly into the response body. 

The other .Net-defined subclasses of HtmlContainerControl are listed below:
	HtmlAnchor
	HtmlButton
	HtmlGenericControl
		HtmlHead
	HtmlSelect
	HtmlTable
	HtmlTableCell
		ListViewTableCell
	HtmlTableRow
		ListViewTableRow
	HtmlTextArea


There are other .Net controls that take properties from the view state that may also be vulnerable. Enumerating them is not very helpful because the solution will always be the same: secure the view state.

Regarding the articles you linked to, I am familiar with Scott Mitchell's. It is a great document, but the vulnerabilities he references have to do with custom use of the view state, not specific flaws inherent in the .Net view state. As we mentioned in the advisory, technically this is a known issue in .Net, although a proof of concept attack against the framework has (to our knowledge) not been documented before.

I've also read Michal Zalewski's advisory. It stands out as (I think) the first specific attacks documented against .Net's view state. However, they are of a different nature than the attack documented in our advisory. 

Sacha Faust's post on encoding controls is a useful reference, but isn't directly relevant to view state attacks. The list is of properties that will automatically HTML encode when the programmer sets the value. This isn't necessarily the same as when the value is set in the view state. 


Thanks,
David Byrne
Senior Security Consultant
Trustwave - SpiderLabs, Application Security
Email: dbyrne at trustwave.com



-----Original Message-----
From: full-disclosure-bounces at lists.grok.org.uk [mailto:full-disclosure-bounces at lists.grok.org.uk] On Behalf Of Chris Weber
Sent: Thursday, February 11, 2010 3:43 PM
To: Trustwave Advisories; webappsec at lists.securityfocus.com; websecurity at webappsec.org; full-disclosure at lists.grok.org.uk; bugtraq at securityfocus.com
Subject: [Full-disclosure] (resend) RE: [WEB SECURITY] Trustwave's SpiderLabs Security Advisory TWSL2010-001

The key part of the advisory for me wasn't VIEWSTATE as much as it was the controls, but this statement you made seemed pretty outrageous (with regard to ASP.NET):

   'These vulnerabilities show that unsigned client-side viewstates will ALWAYS result in a vulnerability in the affected products.'

I would disagree - it depends how the software developer implemented use of the VIEWSTATE's content.  In ASP.NET, the interesting part here was that you appeared to be controlling an innerhtml property of a Form control through the VIEWSTATE.  What your example didn't show, I'm assuming, is some code behind that pulled out the <IndexedString> and set the value in the form's innerHtml property/attribute. That's just dangerous coding, akin to trusting client-side input and no different than acting on client input that came from any method, form input, JSON, etc.  Your repro was a bit confusing/misleading without that part.  Otherwise, were you saying that some controls inherently populate their properties/attributes from VIEWSTATE content automagically?  

There have been past discussions on VIEWSTATE's security:

Scott Mitchell documented tampering VIEWSTATE in a 2004 article:
http://msdn.microsoft.com/en-us/library/ms972976.aspx#viewstate_topic12

Michal Zalewski reported some exploit scenarios with replay and DoS through VIEWSTATE.
http://seclists.org/bugtraq/2005/May/27

You made a reference to how other controls are also vulnerable to this attack.  I think that data would be more useful in the advisory.  

Yes there do exist ASP.NET controls which don't properly encode, and I would refer readers to Sacha Faust's FxCop rule which finds those dangerous controls:

http://blogs.msdn.com/sfaust/archive/2008/09/18/fxcop-htmlspotter-spotting-asp-net-xss-using-fxcop-and-html-encoding-document.aspx


Best regards,
Chris Weber




----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA


----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list