Re: [NSE] isakmp aggressive mode and version detection

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

For the information extraction script I was thinking the output being something like:

"
Aggressive mode:
        Supported / Not supported
Suported transforms:
        Encryption: DES,                Hash: MD5,      Auth: PSK,      DH: 1
        Encryption: 3DES,       Hash: SHA1,     Auth: PSK,      DH: 1
        Encryption: DES,                Hash: MD5,      Auth: PSK,      DH: 2
        Encryption: 3DES,       Hash: SHA1,     Auth: PSK,      DH: 2
ID:
        ID_FQDN, ID_IPV4_ADDR, ID_USER_FQDN
Vendor IDs:
        Cisco Unity
        Dead Peer Detection v1.0
        XAUTH
"

Often the ID field contains the external IP address, but in some cases, this can be the internal address, hostname or a 
user id. The following is output from ike-scan where the internal IP is leaked:

"
        HDR=(CKY-R=69fc23de525b4c1f)
        SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
        VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
        VID=9c3b84c3525a4c1f1b964cdcf878cd7d
        VID=09002689dfd6b712 (XAUTH)
        KeyExchange(128 bytes)
        ID(Type=ID_IPV4_ADDR, Value=192.168.7.45)
        Nonce(20 bytes)
        Hash(20 bytes)
"


- Jesper


On Dec 22, 2012, at 7:30 AM, David Fifield <david () bamsoftware com> wrote:
> On Fri, Dec 21, 2012 at 05:29:03PM +0100, Jesper Kückelhahn wrote:
> > 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........',
> > });
>
> Yes, that is more like what I would expect. The cpe (and any other field
> not filled in) should be set to nil or simply not set.
>
> > 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'.
>
> Okay. I'm having trouble seeing how this information would appear in the
> output. Can you give an example?
>
> > 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.
>
> Relying on order is fine. That's the same thing we do in
> nmap-service-probes.
>
> David Fifield

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