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

[David Fifield <david () bamsoftware com>]

On Thu, Mar 07, 2013 at 10:23:04PM +0100, Jesper Kückelhahn wrote:
> The idea behind the 'type' option is that it would be possible to control
> the amount of request the script sends. As I noted in the original post, I
> think it would be great if a shortcut or scan type were to be added, that
> included many of the http scripts already created. In such a scenario,
> 'type' would probably default to 'version', to limit the amount of traffic
> send to the target(s). Maybe 'profile' would be a better naming of this
> option, and the values could then be 'passive', 'aggressive' and
> 'intrusive'.
>
> I'm currently working on a script that is based on this idea. It initially
> makes three requests: index page, error page and favicon. If the
> 'type'/'profile' is 'passive', version detection is only based on these
> three responses. This might detect the type of web app used, but not the
> exact version. If the 'aggressive' type/profile is used, additional probes
> will be requested, but only in cases where matches have been found in the
> first three initial requests. 'Intrusive' type/profile would request all
> the 'aggressive' probes in the database to try and find matches.

I think the structure of this database is very confusing. On the one
hand there are the "passive" fingerprints, which can have one of:
        request="error"
        request="index"
        request="favicon"
I presume that these are three HTTP requests that are run every time
the script is run. Then there are the "aggressive" fingerprints, which
are not the same, because they have url in place of request:
        url="/sitecore/shell/sitecore.version.xml"
        url="/sitecore/shell/sitecore.version.xml"
        url="/sitecore/shell/sitecore.version.xml"
        url="/Documentation.txt"
The fact that so much repetition is needed seems to show that the
database should be differently structured. Furthermore, why have two
ways of saying the same thing:
        request="index" and url="/"

Instead of these:
        { type="string", match="function%s*PMA_focusInput" }
        { type="md5", match="d037ef2f629a22ddadcf438e6be7a325" }
I would rather see
        { string_match="function%s*PMA_focusInput" }
        { md5_match="d037ef2f629a22ddadcf438e6be7a325" }

I think the database should be grouped by URL. For each URL there will
be a list of matches corresponding to that URL, which can be MD5, or
pattern, or perhaps other types of matches. My reasoning for this
suggestion is that URL requests are the only thing we really pay for in
the script--local matching is essentially free. I don't think you should
have a binary passive/aggressive classification; rather, assign each URL
a "rarity" value like we do for version detection. URLs that are likely
to get a match (like index or favicon) will have a low rarity and always
run.

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