Message-ID: <E64731F3ABEB554E8591AFD1DC20DEE1128FF06071@SKYVS1.trustwave.com>
Date: Fri, 12 Feb 2010 20:50:22 -0600
From: David Byrne <DByrne@...stwave.com>
To: "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: 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@...stwave.com



-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Chris Weber
Sent: Thursday, February 11, 2010 3:43 PM
To: Trustwave Advisories; webappsec@...ts.securityfocus.com; websecurity@...appsec.org; full-disclosure@...ts.grok.org.uk; bugtraq@...urityfocus.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

Powered by blists - more mailing lists