(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 -Original Message- From: Trustwave Advisories [mailto:trustwaveadvisor...@trustwave.com] Sent: Tuesday, February 09, 2010 2:41 PM To: webapp...@lists.securityfocus.com; websecur...@webappsec.org; full-disclos...@lists.grok.org.uk; bugtraq@securityfocus.com Subject: [WEB SECURITY] Trustwave's SpiderLabs Security Advisory TWSL2010-001 Trustwave's SpiderLabs Security Advisory TWSL2010-001: Multiplatform View State Tampering Vulnerabilities Published: 2010-02-08 Version: 1.1 SpiderLabs has documented view state tampering vulnerabilities in three products from separate vendors. View states are used by some web application frameworks to store the state of HTML GUI controls. View states are typically stored in hidden client-side input fields, although server-side storage is widely supported. The affected vendors generally recommend that client-side view states are cryptographically signed and/or encrypted, but specific exploits have not been previously documented. These vulnerabilities show that unsigned client-side view states will ALWAYS result in a vulnerability in the affected products. Credit: David Byrne of Trustwave's SpiderLabs === Vendor: Microsoft (http://www.microsoft.com) Product: ASP.Net (http://www.asp.net) Versions affected: .Net 3.5 is confirmed vulnerable; previous versions are likely to be vulnerable as well. Description: ASP.Net is a web-application development framework that provides for both user interfaces, and back-end functionality. The ASP.Net view state is typically stored in a hidden field named __VIEWSTATE. When a page's view state is not cryptographically signed, many standard .Net controls are vulnerable to Cross-Site Scripting (XSS) through the view state. It is well documented that using an unsigned view state is bad, but most previous advisories focus on vaguely described threats or vulnerabilities introduced by custom use of the view state. To the best of Trustwave's knowledge, this is the first time a proof of concept attack of this nature has been demonstrated against the view state. A vulnerability was alluded to in a 2004 Microsoft article on troubleshooting view state problems [1]. However, other Microsoft documents recommend disabling view state signing if performance is a key consideration, [2, 3, 4] or for various other reasons [5, 6]. Realistically, unsigned view states should never be used in a production environment. The following code is vulnerable to a XSS attack against the form control. Note that the ValidateRequest setting does not prevent the attack. %@ Page EnableViewStateMac=False ValidateRequest=True % html runat=server form runat=server/ /html If the following request is sent to the server, the response will contain JavaScript that calls an alert box. xss.aspx?__VIEWSTATE=/wEPDwUKLTgzNDA2NzgyMA9kFgJmD2QWAgIBDxY CHglpbm5lcmh0bWwFHTxzY3JpcHQ%2BYWxlcnQoJ3hzcycpPC9zY3JpcHQ%2 BZGQ= The view state's XML equivalent is below: ?xml version=1.0 encoding=utf-16? viewstate Pair Pair String-834067820/String Pair
[tool release] Watcher v1.0.0 - passive Web-app security testing and compliance auditing
Watcher is a runtime passive-analysis tool for HTTP-based Web applications. It complements static code analysis and manual security reviews by providing painless verification of operational and code-level issues at runtime. Watcher works seamlessly with todays complex Web 2.0 applications by running silently in the background while you drive your browser and interact with the Web-application. It is being released for free under an Open Source license, the binaries and source are available through CodePlex at http://websecuritytool.codeplex.com/. A screenshot of the reporting screen is also there. This tool provides pen-testers hot-spot detection for vulnerabilities, developers quick sanity checks, and auditors PCI compliance auditing. It looks for issues related to mashups, user-controlled payloads, cookies, comments, HTTP headers, SSL, Flash, Silverlight, referrer leaks, information disclosure, Unicode, and more. Major Features: 1. Silent and passive detection of security, privacy, and PCI compliance issues in HTTP, HTML, Javascript, and CSS 2. Works seamlessly with complex Web 2.0 applications while you drive the Web browser 3. Non-intrusive, will not raise alarms or damage production sites 4. Real-time analysis and reporting - findings are reported as theyre found, exportable to XML 5. Configurable domains with wildcard support 6. Extensible framework for adding new checks Watcher is built as a plugin for the Fiddler HTTP debugging proxy available at www.fiddlertool.com. Its built in C# as a small framework with 30+ checks already included. New checks can be easily created to perform custom audits specific to your policies, or to perform more general-purpose security assessments. Examples of the types of issues Watcher will currently identify: Cross-domain stylesheet and javascript references User-controllable cross-domain references User-controllable attribute values such as href, form action, etc. Cross-domain form POSTs Insecure cookies which don't set the HTTPOnly or secure flags Open redirects which can be abused by spammers and phishers Insecure Flash object access through allowScriptAccess Insecure Flash crossdomain.xml Insecure Silverlight clientaccesspolicy.xml Charset declarations which could introduce vulnerability (non-UTF-8) User-controllable charset declarations Dangerous context-switching between HTTP and HTTPS Insufficient use of cache-control headers when private data is concerned (e.g. no-store) Potential HTTP referer leaks of sensitive user-information Potential information leaks in URL parameters Source code comments worth a closer look Hidden debugging messages from Web and Database servers Insecure authentication protocols like Digest and Basic SSL certificate validation errors SSL insecure protocol issues (allowing SSL v2) Unicode issues with invalid byte streams more . Reducing false positives is a high priority, suggestions are welcome. Right now each check takes steps to reduce false positives, some better than others, and checks can be individually disabled if theyre generating too much noise. E.g. we know that only certain cookies such as session cookies need HttpOnly set, but figuring this out automatically has proven difficult without requiring the user to specify the cookie name. New checks are being planned, and new check ideas or contributions are very welcome. For example: Unicode transformation hot-spot detection (planned) User-controllable javascript events (planned) Contact me with any questions, bugs, or suggestions. -Chris Weber
