Re: Nmap Fingerprint Submitter 2.0

[doug () hcsw org]

Hi Fyodor,

I've updated the interface. It's still at its temporary location:

http://hoytech.com/temp/private/A03FCB37B9C1079D56C91935B8FA1EF5/

On Mon, Jun 11, 2007 at 02:24:04AM -0700 or thereabouts, Fyodor wrote:

> Hi Doug!  I played with the new system some tonight and love it so
> far!  This should definitely make submitting fingerprints easier, and
> produce more accurate data for us when we integrate them.

Thanks!

> o The "submit" button currently gives me a 404 error, so I wasn't able
>   to test beyond playing with the form fields.

Ya sorry it's not plugged into the backend yet. I'll get back to you soon.

> o The number in parens in the OS classification section should
>   probably be the total number of fingerprints matching the vendor/os
>   family.  Right now it is just the number of "child" choices.  For
>   example, "Linux" as the Vendor should probably say "(264)" rather
>   than "(1)" as it says now.

Good idea, that does make a lot more sense. Done.

> o The "Enter your name and e-mail address" field should probably give
>   an example of the format people should use.  E.g. "Fydoor
>   <fyodor () insecure org>".  The exact format people use may not matter
>   much, but an example keeps people from wondering whether the format
>   they use is OK.

Done.

> o At least for OS detection (might be useful for version too), I'd
>   like to see a question like "How do you know the system is running
>   this OS?".

Done for OS detection; probably not as useful for version.

> o I'd like to be able to ask more questions based on what they choose
>   for the "OS Name" field.  For example, if they choose Windows I'd
>   like to add a field for winver results.  And if they specified
>   Linux, I'd like to ask for uname -a and the distribution name and
>   version.  I'd like the uname -a results for other UNIX systems as
>   well.  All of the questions would be single-line form fields, so
>   maybe that limitation would help in adding a generic system for
>   doing this.

Done. It asks for winver on windows, uname -a/distribution on linux,
and uname -a for several other unix systems. I've also abstracted
this into a customisable javascript DSL:

var uname_long_desc = 'The results of running the command "uname -a" on the target (feel free to remove the hostname 
before submitting)';

var extra_os_field_info = [
  // OS Name, Question title, Question instructions
  ['Windows', 'Winver', 'The results of running the command "winver" on the target'],
  ['AIX', 'uname -a', uname_long_desc],
  ['Linux', 'uname -a/distro', uname_long_desc + ' and the Linux distribution if not mentioned in the uname results'],
  ...

This makes it easy to customise an extra question based on the results
of the OS Name field. This could be extended even further, of course.

> o For the version fingerprint submissions system, you might find it
>   useful to have a checkbox in the OS section which says something
>   like "This application is _not_ supported on other operating
>   systems" than the one they specified.  If this is checked (and the
>   user is correct), the generated signature can be augmented with the
>   OS line.

Hm that could help a bit for service detection integration but it's so
easy to look up (and I generally scan the product's website for info
anyways) that I don't think it's worth bothering the user over a fairly
complex question.

> o One the bottom of the page you can note that problems/bug reports
>   should be sent to nmap-dev () insecure org .

Done.

Oh, and it should work with IE now. WOW that was a painful experience but
I think it should run in all IE versions now - MS idiocy notwithstanding.
The main problem was discovering, then convincing myself to believe, IE's
brain-dead javascript array notation.

While mozilla sensibly interprets the following as an array of length 3:

[1, 2, 3, ]

IE's javascript reader, contrary to essentially every programming language
ever designed and every possible train of rational thought, treats it as an
array of length 4 equivalent to:

[1, 2, 3, undefined]

The solution was to remove trailing commas from the JSON data structures
generated from the nmap data files. Note this is just one of numerous
reasons to NOT SEPARATE TOKENS WITH COMMAS. A far better solution is
to NOT automatically eval()uate these forms and USE WHITESPACE INSTEAD.

When your lists look like this:

(1 2 3)

and your arrays like this:

#(1 2 3)

you don't ever need to consider commas.

I also removed all needless whitespace from the JSON file. All the data we
need out of the nmap data files (and it's quite a bit - see the features of
the web interface) is encoded into less than 40k of JavaScript Object
Notation.

If anyone has any comments on this revision of the interface and/or wouldn't
mind testing it against different browsers, please send to the list!

Best,

Doug

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org