Re: [WEB SECURITY] Re: [Webappsec] Comparisons of Web Application Firewalls

["Ryan Barnett" <rcbarnett@xxxxxxxxx>]

------=_Part_11277_16507754.1215122219235
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I have presented many times on the concept of Virtual Patching (mainly
focusing on ModSecurity) and there are two main issues to factor in with
regards to this type of WAF rule writing:

1) Most false positives/negatives arise due to either a weakness in the WAF
parsing engine (meaning that it just can't properly handle the data or it
handles it in a way that is different from the back-end web app) or there
are limitations of the rules language API itself that prevent the
attack/vulnerability from being precisely defined.

2) The rule writer is either ignorant of the exact underlying
vulnerabilities (and writes an exploit-specific patch) or is just plain
sloppy with the rule creation or testing.  This includes factoring in
possible evasion attempts such as different encodings, etc...

Martin, I am assuming that the WAF you were going against had one or both of
these problems.

There are many philosophical approaches that one can take with Virtual
Patches (meaning negative security filters vs. positive security profiles)
with each having their own benefits and drawbacks, however from a purely
security perspective the best method is positive security.  Doing this sort
of thing manually for an entire site is not really feasible, however you can
certainly do targeted positive security rulesets once a vuln has been
identified.  The most difficult challenge is usually identifying that a vuln
exists, at that point, just do a positive ruleset to protect that resource.

This is where I believe that many WAF virtual patches fail.

-- 
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache

On Thu, Jul 3, 2008 at 4:31 PM, Martin O'Neal <martin.oneal@corsaire.com>
wrote:

>
> > I don't want to start a flame
> > war here - but there is not
> > a single, competent review of
> > WAFs for public consumption as
> > of today.
>
> My own personal experience of assessing many of applications protected
> by all the major WAF vendors is that in practice (like IDS/IPS) they
> offer very little real-world value.  Most are installed by the
> vendor/tin-pimp as out-of-the-box, and the ones that aren't are
> generally in log-only mode and unmonitored.
>
> One recent project had a broken app protected by an F5 WAF.  The client
> (against our advice) decided that they would fix the problems using the
> F5 (whilst waiting for the app vendor to refactor).  The general process
> for this is that the F5 pimp analyses the last set of successful vectors
> we used, tinkers with the WAF rules, says it is fixed, then we come back
> and vary the attacks just enough to bypass the rules.  All a complete
> waste of money and time.  I think we are on fourth of fifth re-test now,
> and no end is in site.
>
> WAF does have some merit as a dynamic patch for quick and dirty fixes,
> but they do very little (if anything) to protect a broken application
> from a skilled attacker.
>
> Martin...
>
>
>
>
> ----------------------------------------------------------------------------
> 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
>
>

------=_Part_11277_16507754.1215122219235
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I have presented many times on the concept of Virtual Patching (mainly focusing on ModSecurity) and there are two main issues to factor in with regards to this type of WAF rule writing:<br><br>1) Most false positives/negatives arise due to either a weakness in the WAF parsing engine (meaning that it just can&#39;t properly handle the data or it handles it in a way that is different from the back-end web app) or there are limitations of the rules language API itself that prevent the attack/vulnerability from being precisely defined.<br>
<br>2) The rule writer is either ignorant of the exact underlying vulnerabilities (and writes an exploit-specific patch) or is just plain sloppy with the rule creation or testing.&nbsp; This includes factoring in possible evasion attempts such as different encodings, etc...<br>
<br>Martin, I am assuming that the WAF you were going against had one or both of these problems.<br><br>There are many philosophical approaches that one can take with Virtual Patches (meaning negative security filters vs. positive security profiles) with each having their own benefits and drawbacks, however from a purely security perspective the best method is positive security.&nbsp; Doing this sort of thing manually for an entire site is not really feasible, however you can certainly do targeted positive security rulesets once a vuln has been identified.&nbsp; The most difficult challenge is usually identifying that a vuln exists, at that point, just do a positive ruleset to protect that resource.<br>
<br>This is where I believe that many WAF virtual patches fail.<br><br>-- <br>Ryan C. Barnett<br>ModSecurity Community Manager<br>Breach Security: Director of Application Security<br>Web Application Security Consortium (WASC) Member<br>
CIS Apache Benchmark Project Lead<br>SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC<br>Author: Preventing Web Attacks with Apache<br><br><div class="gmail_quote">On Thu, Jul 3, 2008 at 4:31 PM, Martin O&#39;Neal &lt;<a href="mailto:martin.oneal@corsaire.com";>martin.oneal@corsaire.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
&gt; I don&#39;t want to start a flame<br>
&gt; war here - but there is not<br>
&gt; a single, competent review of<br>
&gt; WAFs for public consumption as<br>
&gt; of today.<br>
<br>
</div>My own personal experience of assessing many of applications protected<br>
by all the major WAF vendors is that in practice (like IDS/IPS) they<br>
offer very little real-world value. &nbsp;Most are installed by the<br>
vendor/tin-pimp as out-of-the-box, and the ones that aren&#39;t are<br>
generally in log-only mode and unmonitored.<br>
<br>
One recent project had a broken app protected by an F5 WAF. &nbsp;The client<br>
(against our advice) decided that they would fix the problems using the<br>
F5 (whilst waiting for the app vendor to refactor). &nbsp;The general process<br>
for this is that the F5 pimp analyses the last set of successful vectors<br>
we used, tinkers with the WAF rules, says it is fixed, then we come back<br>
and vary the attacks just enough to bypass the rules. &nbsp;All a complete<br>
waste of money and time. &nbsp;I think we are on fourth of fifth re-test now,<br>
and no end is in site.<br>
<br>
WAF does have some merit as a dynamic patch for quick and dirty fixes,<br>
but they do very little (if anything) to protect a broken application<br>
from a skilled attacker.<br>
<font color="#888888"><br>
Martin...<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
----------------------------------------------------------------------------<br>
Join us on IRC: <a href="http://irc.freenode.net"; target="_blank">irc.freenode.net</a> #webappsec<br>
<br>
Have a question? Search The Web Security Mailing List Archives:<br>
<a href="http://www.webappsec.org/lists/websecurity/archive/"; target="_blank">http://www.webappsec.org/lists/websecurity/archive/</a><br>
<br>
Subscribe via RSS:<br>
<a href="http://www.webappsec.org/rss/websecurity.rss"; target="_blank">http://www.webappsec.org/rss/websecurity.rss</a> [RSS Feed]<br>
<br>
Join WASC on LinkedIn<br>
<a href="http://www.linkedin.com/e/gis/83336/4B20E4374DBA"; target="_blank">http://www.linkedin.com/e/gis/83336/4B20E4374DBA</a><br>
<br>
</div></div></blockquote></div><br>

------=_Part_11277_16507754.1215122219235--