[WEB SECURITY] RE: 02/2009 WASC WAF thread

[Andre Gironda]

On Mon, Feb 9, 2009 at 9:44 PM, Arian J. Evans
<arian.evans at anachronic.com> wrote:
> I have solved attack mitigation on some fairly complicated
> business logic issues with WAFs before, and sometimes using
> simple techniques like parameter checksums and replacement,
> or parameter correlation in a back-end database (for business
> logic/semantic flaws that flow across multiple applications
> plugged together).

This sounds like an enormous waste of time, especially with an expert
like yourself as a resource.  I picture you sweating in the desert,
trying to build a pyramid -- only to have it burned down a few days
later.

Attack chaining prevention, especially with AuthZ, almost *has* to be
done as a manual code review activity, if not way before then as a
risk analysis activity.

> I believe the top-tier providers (F5, Breach, Imperva, and
> maybe the Citrix solution) are *capable* of preventing most
> successful compromises I have seen of a web applications
> (and web servers, for that matter).

And I believe that if the table and view privileges for the db user
are revoked, and instead permissions are granted as execute-only on
specific stored-procedures used by the application - then it would be
impossible for a successful compromise.  We discussed this at a recent
local owasp chapter meeting.  Most IIS/SQL-Server setups usually have
all permissions between everything -- it's no wonder xp_cmdshell is so
easy to pop for pen-testers.  The reason is often connection pooling
for performance, but there are many ways around this and it's often
unnecessary.

Total cost: one change control request and one admin.

Your total cost: a gagillion dollars, five hundred thousand man-hours,
several projects that lead into completely new change control policies
and headcount, and the additional of several layers of
points-of-failure and packet-latency, destroying performance, and
ruinage of the application.

EPIC FAIL.

> Putting aside discussions about deployablity, stability, and
> maintainability (which are equally important, but not the point
> of this question)...I would like to see real-world examples of
> exploitable flaws that mainstream WAFs cannot protect.

This is a joke, right?  Um, how about every domain logic problem that
doesn't have to do with hidden form fields, parameters, and "standard"
AuthN or AuthZ?

As above, they also might be able to protect some really advanced
things, but at what cost to time and resources?  Compare to risk
analysis that combines aspects of unit testing, code inspection,
functional testing, security code review analysis inspection, and
manual code review.  We're talking days instead of years.  One
person-resource instead of thousands.  $20k instead of $100k CAPEX.

> Obviously most WAFs will not do much out-of-the box.

Das Blinkenlichten!

> Besides the above vendors, there are tier two and three
> vendors of WAFs I am excluding in this discussion. Some of
> the software widgets I've seen over the years don't even inspect
> POST requests so they are necessarily limited given today's
> threat landscape (e.g. LHF Bots can POST forms).

Seriously?  Bots can POST forms?  Can they spoof referers, too?
Welcome to 1997.

And we care ... because?  Monitoring the app layer is all well and
good, but monitoring yourself getting owned over and over again is
purely stupid.  Last time I checked, a software widget called tcpdump
appeared to work find at capturing POST or any HTTP method.

> Fact: WAFs can solve most issues that lead to compromise
> if they are properly configured.

Fact: Configuring your web server and database can solve most issues
that lead to compromise if they are properly configured.

> I am painfully well aware of limitations in WAFs, particularly
> in areas like dealing with canonicalization. I ran a lab with 9
> WAFs in it at one point and my colleagues and I could virtually
> always find a way through the WAFs using encoding and charset
> tricks like have been discussed. (Heck, as late as 2005 a
> few main WAFs did not support UTF-8 :). Yet...

I'm pretty well aware of specific protection proscriptions against
canonicalization attacks, not even including OWASP ESAPI.  Microsoft
recently wrote 211 words discussing how their SDL protects against
CWE-73.

> Mitigation Fact: I have found very few classes of real-world
> compromises of web applications that could not have been
> trivially blocked by a WAF with simple configuration, if the
> issues were known & understood by the WAF operator.

Unless it was an insider or second-order attack.  Then the WAF
wouldn't necessarily be inline to stop said compromise.

I have always found it funny that the SAME people who brought up an
enormous stink around firewall technology -- how man-in-the-browser
and client-side attacks such as XSS proxy scanning, Flash/Java-applet
scanning, and CSRF lay waste to everything we know about firewalls --
are also the SAME people claiming that "web application" FIREWALL
technology doesn't suffer the same sort of eventual fate.

Oh... you don't remember?  Let me remind you so you can bathe yourself
in the irony:
"There are no good metrics for how many intranet Websites there are,
or how vulnerable they are. That's a big unknown in the industry,"
Grossman says. "It's a whole other world inside the firewall."

HACKING INTRANETS ring a bell?

> If anyone has examples or is willing to provide factual evidence
> of compromises that cannot be blocked by a WAF -- please share.

Yes, in a similar vein, if anyone can provide factual evidence of
compromises that cannot be blocked by tweaking a configuration on a
set of web servers and database servers -- please also share.

> "The WAFs you see (which ones?) do not help your customers because
> of technical limitations, namely focusing on HTTP requests and not
> inspecting/ filtering HTTP responses."
>
> I have seen where this is an issue in some cases. I also believe that most
> cases I have seen can be addressed on input if the problem is properly
> described to the WAF.

Or they can just use Microsoft AntiXSS SRE.  I heard this same concept
can be easily applied to JSF, just not Servlets.

The Microsoft Security Runtime Engine (SRE) includes a tool that will
scan your ASP.NET source code, identify the existing controls that are
NOT properly encoded (or using the latest, safe encoding rules from
AntiXSS), and then add JUST (only) those to a configuration file that
IIS loads from an IHttpModule via a small web.config change (which
affects the HTTP pipeline).  The performance hit can't be noticed by
humans (or even by dogs when the latency deviation is given a resonant
pitch).

The "WAF HTTP response problem" has been talked about at length, for
years, by me (and possibly a few others).  For the commercial WAF
vendors to avoid it this long -- I believe it is well deserved that
someone like Microsoft put them out of business with an freely
available automated tool that requires a simple one-line web.config
change, but applies in all scenarios (except the ones noted in the
documentation... this only applies to ASP.NET controls and obviously
not Reponse.Write).

Since the WAF vendors aren't really here to defend themselves against
my personal attack (i.e hoping that they go out of business), then I
wish to have those specific words excluded from this email by the
moderator and re-posted anonymously in order to protect my identity in
case one of those WAF vendors eventually becomes the only company in
the entire world and somehow refuse to hire me based on this
mailing-list post.

> Let's extend this discussion beyond "WAF vendors". (I am doing this
> for a reason :)

Great idea!  I was getting myself into trouble in the above paragraphs.

> IDS and IPS also commonly have this limitation. Ignoring responses is
> a trick used to increase the performance numbers of IDS/IPS widgets.
> So as IDS and IPS vendors dig into this realm, we will probably have
> to accept that as a limitation.

I don't like network tricks.  In network-land, we call these "hacks"
or "stupid".  In operator-land, we call these "vendors trying to put
lipstick on a pig and sell it as a supermodel".

You should understand that analogy, Arian, because I hear that you
land talent in the real world with the motorcycles and the rockstar
attitude.  Notice how this is a compliment ;>

> I have said before and will say again: if IPS vendors decide to come
> after the WAF market, I think they can and will crush it through
> marketing simply by saying "we do that too".

So you admit that both WAF and IPS technology are useless and cost a
ridiculous amount of money for nothing?

Jeremiah Grossman talks about how PCI-DSS 6.6 can be met with Nessus
version 2.0 on his blog (and I think he's stating that this is somehow
WRONG in principle), but you are here saying it's inevitable that IPS
vendors will do the same to WAF vendors.  Hrmn.

> XSS and SQLi? Technically they *could* but I think most of
> us on the list know they don't do this in an effective enough
> manner to stop the attacks we see today IRL.

Everyone knows that XSS and SQLi by themselves are crap.  Point the
world's best XSS pen-tester at an average app -- he will find one.
Point the world's best SQLi pen-tester at the same app -- she'll find
one of those, too.  But point an expert that knows Attack Chaining at
any app, with any protections -- and he'll find something that will
blow your mind away.

> This said: the IPS vendors could play here if they wanted to.
>
> 2010 prediction: They will.

2010 prediction: Organizations will continue to spend money on crap
security products that are epic fail.

> WAF market is blossoming. I would like to see Sourcefire
> and Palo Alto networks step into this area. They appear to
> be the two fastest growing IDS/IPS and UTM players.

Well it's good to know that somebody is making money ripping people
off in this downed economy besides the criminals!

Sourcefire makes a very expensive commercial IDS based on snort, which
is a FOSS tool.  Palo Alto makes a Cisco PIX with a pretty interface
and that shows pretty stuff happening at the app layer, but Ourmon
does better and it's FOSS.  What a serious waste of money these
devices are.

> Seriously, though, I have never found a customer that did not
> want help resolving challenging issues involving mitigation
> and remediation. As my cell phone bill can attest -- I find that
> I am usually one of the first people called in the event of a compromise
> for mitigation and containment strategies, even when I have
> only been playing the role of "auditor". I find it valuable to be
> able to offer people a wide range of tactical and strategic steps
> to contain their issues, from permissions auditing to WAF configuration
> log analysis to developer training and SDL suggestions. etc.

Wow I agree with everything in the above paragraph, but replace WAF with SRE.

> Firewalls didn't work so well in the early days, and neither did IDS.

Do they today?

> Pen testers were often inexperienced or clueless about the
> the "issues" they would find and report as exploitable.

Aren't they still this way?

> Marcus Ranum preached for years that penetrate and patch
> (or block) would never work. He advocated that the answer
> was to "build secure networks". It is really easy, Marcus would
> explain, to contain your threat landscape and remove your
> attack surface if you rebuild your network from the ground up
> to be secure, and train your developers to program more securely.
>
> While that may be the right answer --  it does not appear to
> be an answer that has found widespread acceptance, or success.

I stopped listening to Marcus Ranum and started listening to Dinis Cruz.

Cheers,
Andre

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA