Re: [NSE] isakmp aggressive mode and version detection

[Jesper Kückelhahn <dev.kyckel () gmail com>]

Hi David,

Thanks for the feedback. Regarding the structure, I was trying to duplicate the same structure used in 
http-fingerprints.lua, which seems to not have been that successful :) 
I gather that you suggest creating entries like the following:

table.insert(fingerprints, {
        category = 'fingerprint',
        product = 'Checkpoint Firewall-1',
        version = '4.1 Base',
        ostype = 'SecurePlatform',
        devicetype = 'VPN',
        cpe =   '',
        fingerprint = '^f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000020000000000000000........',
});

table.insert(fingerprints, {
        category = 'fingerprint',
        product = 'Checkpoint Firewall-1',
        version = '4.1 SP1',
        ostype = 'SecurePlatform',
        devicetype = 'VPN',
        cpe =   '',
        fingerprint = '^f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000030000000000000000........',
});

If this is correct, then a side effect is that the search for a given fingerprint should be little bit easier/cleaner, 
which is nice.

In general Vendor IDs can be divide into three groups (from what I've seen):

        1) Vendor specific VID, which enables a client to determine the vendor of the service
        2) General attributes supported by the service (Dead Peer Detection, etc)
        3) Vendor specific attributes for vendor clients (seen in Cisco devices)

The difference between the categories 'fingerprint' and 'attribute' is that 'fingerprint' includes only the VIDs in the 
first of the above groups, while 'attribute' only includes VIDs from the second. Fingerprints that are not vendor 
specific could be removed, but I think that they should kept, as I hoping to create a script that can extract more 
information, which would make use of these VIDs. I see that the naming of the categories in the fingerprint database, 
might not be descriptive enough, and should probably be changed to 'vendor_specific' and 'general_attribute'.

Often the VIDs are MD5 sums of some string, so this should minimise the chance of two vendors using the same vendor 
specific VID. In the current implementation of script,  version detection stops after the first hit. This is to deal 
with fingerprints seen below:

        1) f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d0000000000000000...…..       
        2) f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d........00000000........

This means that the ordering of the fingerprints matter, but I've only seen this kind of near match in VID's from the 
same vendor, so the case of two matching Vendor specific VID's from different vendors should be minimal.



- Jesper


On Dec 21, 2012, at 5:39 AM, David Fifield <david () bamsoftware com> wrote:

> On Mon, Dec 17, 2012 at 09:17:39PM +0100, Jesper Kückelhahn wrote:
> > Hmmm, it seems I have some issues attaching files. I'll try attaching them
> > once again.
>
> This looks nice. In a version script, you should set product, vendor,
> version, etc. separately, and not put all the information in the product
> field. Check the XML output to see how it breaks down.
>
> The structure of the fingerprints file seems funny to me. Here is a
> sample entry:
>
> table.insert(fingerprints,{
>        category = 'fingerprint',
>        vendor = 'Checkpoint',
>        version = 'Firewall-1',
>        vids = {
>                ['4.1 Base']            = 
> '^f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000020000000000000000........',
>                ['4.1 SP1']                     = 
> '^f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000030000000000000000........',
>                ['4.1 SP2-SP6']         = 
> '^f4ed19e0c114eb516faaac0ee37daf2807b4381f0000000100000fa20000000000000000........',
>                ['NG Base']                     = 
> '^f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000013880000000000000000........',
>                ['NG FP1']                      = 
> '^f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000013890000000000000000........',
>                ['NG FP2']                      = 
> '^f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138a0000000000000000........',
>                ['NG FP3']                      = 
> '^f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138b0000000000000000........',
>                ['NG AI R54']           = 
> '^f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c0000000000000000........',
>                ['NG AI R55']           = 
> '^f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d0000000000000000........',
>        }
> });
>
> The way I think of such a database is as a list of byte patterns, each
> one having an associated set of data like product, vendor, and version.
> This format seems to use a common vendor and "version" (I guess this
> "version" is what Nmap usually calls the "product") for a list of actual
> version numbers. Maybe it makes sense to use a common block of data for
> multiple fingerprints, but this format is confusing. Suppose a certain
> fingerprint matches two different vendors, how do you represent that?
>
> For each fingerprint, you should store all the information that you can
> potentially set about a port. In other words, these fields:
>       http://nmap.org/book/nse-api.html#scripting-tbl-port-version-values
> In particular, it should be possible to set "cpe" in the fingerprints
> file.
>
> What's the difference between category='fingerprint' and
> category='attribute'?
>
> David Fifield

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/