Re: [NSE] IKE information extraction

[David Fifield <david () bamsoftware com>]

On Thu, May 23, 2013 at 12:40:46AM +0200, Jesper Kückelhahn wrote:
> I guess I missed your point about using a mutex; I initially didn't think
> about implementing it in the ike lib, which makes more sense. I've attached
> a patch against SVN that includes mutex. Thanks again for the pointer.
>
> I've also attached an updated ike-info.nse that extracts more information,
> specifically the use of aggressive mode authentification and pre-shared
> keys (CVE-2002-1623).

I've applied parts of the ike.lua patch in a series of revisions
starting with r30968. The remaining uncommitted changes are attached.

Please don't mix up a lot of unrelated changes in one patch in the
future. In particular, you changed the name of some constant tables and
changed their formatting, while also adding elements to them. This makes
it take longer to evaluate your changes.

>   if row.vendor  ~= nil then debug_string = debug_string .. row.vendor .. ' ' end
>   if row.version ~= nil then debug_string = debug_string .. row.version       end
>   stdnse.print_debug(2, "IKE: Fingerprint: %s matches %s", vendor_id,  debug_string)
> + table.insert(info.matches, { ['vid'] = vendor_id, ['match'] = debug_string} )

I see that you are storing a list of vendor IDs. I also see that
info.vendor is being stored only for the first match. Wouldn't it be
better to store all the information for each match? That is, store the
equivalent of info.vendor for each entry in info.matches? Continue to
store the first match as info.vendor for backward compatibility.

Why are you storing something called debug_string in a data table? Is it
really debug info (in which case don't store it), or does it have some
meaning to the caller (in which case call it something different from
debug_string).

Could you add comments explaining what appears in the matches array, and
what typical values for the vendor ID and match string are?

David Fifield

Attachment: ike.lua.patch
Description:

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