Re: [Full-disclosure] Trustwave's SpiderLabs Security Advisory TWSL2010-001

[David Byrne <DByrne@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx



-----Original Message-----
From: full-disclosure-bounces@xxxxxxxxxxxxxxxxx 
[mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Chris Weber
Sent: Thursday, February 11, 2010 3:43 PM
To: Trustwave Advisories; webappsec@xxxxxxxxxxxxxxxxxxxxxxx; 
websecurity@xxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxxx; 
bugtraq@xxxxxxxxxxxxxxxxx
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



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/