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

["Ivan Ristic" <ivan.ristic@xxxxxxxxx>]

I agree, your approach of attempting to identify the changes between
Core Rules versions sounds plausible to me.


On Sun, Jul 13, 2008 at 4:09 PM, Andres Riancho
<andres.riancho@xxxxxxxxx> wrote:
> 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
>

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