RE: Trustwave's SpiderLabs Security Advisory TWSL2010-001

[David Byrne <DByrne () trustwave com>]

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 () trustwave com



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