Re: [WEB SECURITY] Re: Comparisons of Web ApplicationFirewalls

["Andres Riancho" <andres.riancho@xxxxxxxxx>]

Ivan,

On Tue, Jul 8, 2008 at 1:32 PM, Ivan Ristic <ivan.ristic@xxxxxxxxx> wrote:
> As far as I know the ModSecurity detection mechanism (in w3af) does
> not actually do anything.

You are completely right, actually, this is the code for the mod
security ""detection"" =)

    def _identifyModSecurity(self,  fuzzableRequest):
        '''
        Try to verify if mod_security is installed or not AND try to
get the installed version.
        '''
        pass

This was mostly a method stub to be completed in the future, but
mainly because we didn't found a good way to identify mod_security we
left it as it is. In the future, we are going to perform a more
detailed analysis and may come up with something meaningful.

> I would say the following rules of thumb apply:
>
>  - Passive or embedded WAFs cannot be detected when deployed in
> non-blocking mode.

Unless they add some header.

>  - Reverse proxies (WAFs or not) can almost always be detected and
> fingerprinted. (Not sure if one could detect an Apache reverse proxy
> sitting in front of an Apache web server; I would have to try to be
> sure.)
>
>  - WAFs in blocking mode can be detected and almost certainly
> fingerprinted. Here you would actually be fingerprinting the
> configuration, probably not the products directly.

One of the ways I thought that the w3af team could identify
mod_security was by having our own knowledge base of the different
versions of the core rules, for example core_rules_v1 = [a,b,c,d] ;
core_rules_v2 = [a,b,c,d,e,f] and core_rules_v3 = [a,b,c,d,e,f,x,y,z].
Then, the detectModSecurity method would try to identify the version
of mod_security core ruleset by first requesting something that
triggers x, y, z. If we don't get blocked, then we continue with
requests that trigger e,f ; if we didn't got blocked, we request
a,b,c,d which should block us if the remote end has v1 installed. This
works fairly good and allows us to identify the core ruleset that is
running on the remote mod_security. Configuration
customization/changes don't affect this algorithm as much as you may
think because the number of rules that are added from one version to
the other is rather big, and if the user disables one or two of the
new rules, we'll identify the ruleset by the other new ones. This
hasn't been implemented nor tested, but sounds like something worthy
of trying =)

One problem that I just found is that this may trigger a lot of false
positives in the cases were the remote end has a WAF, but not a
mod_security one.

>
> The bottom line is: configuration

Yes, in the case of mod_security we haven't found a way to identify it
rather than using the above algorithm; which discovers the core
ruleset being used, which may give you some clue of the mod_security
version being used.

Just for the record, after this thread we added some more signatures
to identify the following WAFs:

URLScan
SecureIIS
Airlock
Barracuda
DenyAll
F5ASM
HyperGuard

The code can be read here:

http://w3af.svn.sourceforge.net/viewvc/w3af/trunk/plugins/discovery/detectWAF.py?revision=1418&view=markup

Cheers,

> On Tue, Jul 8, 2008 at 2:40 AM, Brian Shura <bshura@xxxxxxxxxxxxx> wrote:
>> W3AF has a plug-in called "detectWAF" that tries to fingerprint WAFs.
>>
>> It currently attempts to detect URLScan, ModSecurity, and SecureIIS.
>>
>> http://w3af.sourceforge.net/pluginDesc.php#detectWAF
>>
>>
>> Brian
>>
>> -----Original Message-----
>> From: Jeremiah Grossman [mailto:jeremiah@xxxxxxxxxxxxxxx]
>> Sent: Monday, July 07, 2008 6:25 PM
>> To: Achim
>> Cc: WASC Forum
>> Subject: Re: [WEB SECURITY] Re: Comparisons of Web ApplicationFirewalls
>>
>>
>> On Jul 7, 2008, at 3:56 PM, Achim wrote:
>>
>>>
>>> !! Anyone want to make an open source WAF fingerprinter? :) Now
>>> would be a great
>>> !! time!
>>>
>>> LOL
>>> which WAF cannot be identified by it's cookie --which are most
>>> likely not
>>> changed in the configuration, (un)fortunatelly?
>>>
>>>   1. ModSecurity (as it doesn't use cookies ;-)
>>>   2. ..
>>>   ..
>>>
>>>
>>
>>
>>
>> There should be a few ways in addition to cookies actually.
>>
>> Some of them encrypt or sign cookies, perhaps that could be
>> fingerprinted if a consistent format could be identified. They also
>> might respond consistently with particular malformed requests
>> differently than a web server would. Response codes, length, or even
>> an HTML error message. Some of them also scrub particular data types
>> in the response like internal IPs, credit card numbers, etc. With a
>> content spoofing vuln, these might be injected on the fly to see if
>> they magically vanish.
>>
>> Just a few ideas. The tough part is getting a test-bed.
>>
>> Jeremiah-
>>
>> ----------------------------------------------------------------------------
>> 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
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com
>> Version: 8.0.138 / Virus Database: 270.4.6/1539 - Release Date: 7/7/2008
>> 6:35 PM
>>
>>
>> ----------------------------------------------------------------------------
>> 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
>>
>>
>
>
>
> --
> Ivan Ristic
>
> ----------------------------------------------------------------------------
> 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
>
>



-- 
Andres Riancho
http://w3af.sourceforge.net/
Web Application Attack and Audit Framework

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