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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 9 Feb 2010 16:07:20 -0800
From: "Arian J. Evans" <arian.evans@...chronic.com>
To: Trustwave Advisories <TrustwaveAdvisories@...stwave.com>
Cc: "webappsec@...ts.securityfocus.com" <webappsec@...ts.securityfocus.com>,
	"websecurity@...appsec.org" <websecurity@...appsec.org>,
	"full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
	"bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: Re: [WEB SECURITY] Trustwave's SpiderLabs Security Advisory 
	TWSL2010-001

Hidden Form Fields and Cookie values are also sometimes vulnerable to
these attack techniques.

Encrypting hidden form fields and cookies usually protects them from
tampering. Same problem; same solution.

Viewstates typically have the advantage over cookies and hidden FFs,
from a security control standpoint, of having native encryption and
checksumming facilities provide by the programming
environment/framework.

These controls are as easy to turn on as flicking a switch. Super
simple remediation. Most frameworks do not offer easy, native controls
like this for cookies or hidden FFs.

Would you agree that the issue here is RTFM?

Many developers using Viewstates aren't aware they are using
Viewstates. Think "Newbie Visual Studio Jockey" developers. They are
using a control in their IDE and have no idea it's passing off stuff
in b64 strings to the web-browser/client that can be decoded and/or
modified.

The most common scenario where developers disable native Viewstate
controls is in multi-websever deployments when they start
load-balancing. The Viewstate keys don't match across servers; the app
breaks; the developers Google just enough info to decide to turn off
Viewstate encryption/checksums (or the server admin does it).

The fix for Viewstate load balancing issues is also super simple:
Share Viewstate MAC/checksum or encryption keys. But it is fairly
common not to do this until after a security assessment. Usually for
the same reasons I outlined above: they aren't really even sure what
Viewstate is doing.

So good work. Nicely written advisories.

Questions:

1) Did you find any unpublished new vulns in these specific products?

2) Are the core issues "if you turn off your compensating control your
vulnerabilities are still vulnerable?"

3) Do most vendors enable Viewstate controls by default (like
Microsoft does)? If not - I think you should highlight and underscore
that. Certainly a default checksum would be smart.

Ciao

---
Arian Evans
Solipsistic Software Security Statistician