Re: [NSE] http-enum and http-fingerprints enhancement suggestions

[David Fifield <david () bamsoftware com>]

On Sun, Feb 03, 2013 at 03:08:15PM +0100, Jesper Kückelhahn wrote:
> The http-enum script currently displays the results in the standard
> script output area regardless of whether the information found is
> version related. I'd like to modify the script and fingerprint file,
> such that it is possible to add fingerprinted web applications to the
> 'extra info' field of the ports table. I think that this extra
> information in the standard nmap output would make sense and would add
> value to the service detection.

I agree, it's nice if http-enum is allowed to set version fields. You
should use your ike-fingerprints design as a model.

> These modifications would require some general changes to the
> information stored in the fingerprint file. I've listed the properties
> I think would be needed/make sense to include:
>
>   - type: [version, comprehensive, intrusive]
>   - rarity: [?]
>   - method: [HEAD, GET, OPTION]
>   - favicon: md5 hash
>   - page_hash: md5 hash
>   - probe: url
>   - match: regex
>   - output: string
>   - source: [Nikto, Blindelephant, ...]
>   - cpe: cpe:/a:...
>
> I've included favicon here as I think it would be a good way of
> centralising data, and possibly joining the scripts. Also adding a
> rarity field would allow for limiting the amount of data sent during
> the fingerprinting. This could be based on the popularity, port
> number, etc. I haven't figured out the best way of doing this, or if
> it's actually a good idea. The page_hash is inspired by
> BlindElephant[2] and [3]. I've added a source property in case
> fingerprints were included from other sources. 

I don't understand the "type" of version, comprehensive, or intrusive.
This part feels underspecified to me. How does the user interface for
this part work? How do users choose which types of probes they run, and
do they care? Is is possible to remove this part?

I disagree with giving favicon any special treatment. Isn't it just a
matter of defining a probe and having a list of match hashes?

Rarity is a good idea, but it should apply only to probes, not to
matches. Once we've done the probe, we have few enough matches that we
can regard matching patterns against the page text as free.

I don't see any fields above for vendor, version, extra info? Isn't that
one of the main ideas?

I think it would help if you could show us examples of real probes and
matches using this system.

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