Andres Riancho <andres.rian...@gmail.com> wrote
> I agree with the way of fixing this, but the question should be...
> do we want to fix it? I'll leave you a question to think about: What
> would happen if we fix this issue? What happens with the old
> fingerprints?
Old fingerprints can remain -- they still contain useful info. The
matching function would need to know if it matches the collected
fingerprint against a v1.0 fingerprint (which would be the current
scheme), or a v1.1 fingerprint, and make the necessary adjustments. (So
files need to get a version number in one way or another.) For example,
a 'NO_RESPONSE_CODE' in v1.0 would signal a result that comes from a
different response parser, and for that reason would need to be
translated into, say, a 'PROTOCOL_ERROR|*' pattern to match a
'PROTOCOL_ERROR|STATUS_501|NO_REASON' from an imagined v1.1 response parser.
However ... after playing around with the hmap plugin I'm not sure
that it's worth it ... there are other things that affect hmap and w3af
in more important ways that the NO_RESPONSE_CODE thing.
Actually, adding a nmap-based fingerprinter would probably be a faster
and easier way to produce good web server fingerprints without any of
the drawbacks hmap has. (That's my general conclusion -- the rest of
this letter is just how I got there.)
A few days ago, while trying to fingerprint IIS/2 and IIS/3 servers, I
found that it wasn't possible: something in the fingerprinting crashed
the server -- and those were single-thread, single-instance servers:
crash it, and you have to restart it manually to get your web back. They
can't be fingerprinted (completely) with the current set of probes. So
the hmap plugin essentially performs a DoS attack on the server/webapp
w3af is meant to be evaluating. Not a good thing, even if those servers
happen to be obsolete.
Embedded web servers (in printers, for example) show similar
behaviour: just to be weird I hmap'ed a HP laser printer the other day.
It reset continually during the fingerprinting, and once hmap reported
it was finished, the printer had switched operator language from english
to french, and was unreachable from the network. I didn't get a useful
fingerprint out of that attempt either -- mainly 'NO_RESPONSE'. Printers
are perhaps marginal cases, but as the admin interface is pretty much of
a web app, I think this is a problem that falls within the area of w3af.
And yesterday I discovered that it took more than 25 minutes to
fingerprint a third server -- a more ordinary one. That wait held up a
vulnerability scan, which was the main job, and the result was just not
worth it: there was an exception failure in hmap, and so no fingerprint.
(I ended up using nmap and httprint instead -- result back in less than
one minute.)
I think those things need fixing more than the basic fingerprint
response parsing. But fixing those will very probably also affect
fingerprints and fingerprinting.
The original implementation of hmap didn't have efficiency as a goal:
collecting all possible data points was not seen as a problem. However,
in a plugin to w3af, I think that must change. Ideally, hmap should not
send more requests than are necessary to come up with a reasonably good
identification, or the conclusion that the server can't be identified
well enough. (Collecting the fingerprint is another matter, of course.)
I think it could be done by chewing on the existing fingerprint files
to identify requests that help separate groups of servers, and then
order those into a decision tree based on requests and responses.
However, the current fingerprint file format is not perfect for this --
headers, for example, are collected from a full fingerprinting session,
so if there is a unique header from a particular server, it's not known
how to produce it easily: at worst the entire set of probes need to be
done. Associating headers with specific requests would make this more
efficient.
Nor did the original hmap have lack of negative impact (DoSing) as a
design consideration. 'NO_RESPONSE' could identify some probes, but when
a server crashes, so typically does hmap, so there is no record of hmap
fingerprinting making a server die., and thus no warning if someone
tries to scan IIS/2.0 or HP laser printers.
That one needs some basic redesign, I think. Perhaps a fingerprint
file containing the Server: banner and a 'ask user before scanning --
here's what might happen' indicator, followed by a short description of
identified effects, and perhaps as much of a fingerprint that has been
possible to collect.
But at the end of the day, using nmap and/or httprint produces a
decent identification much faster and without any of the mishaps that
hmap entails.
Reusing Nmap probes in hmap to flesh out the existing fingerprints
would be nice -- but that would almost certainly mean a redesign of
structure. Nmap seems to get by with a few probes in this order: NULL
('for some SORRY web servers'), GenericLines (just \r\n\r\n),
GetRequest, HTTPOptions and the FourOhFourRequest (GET of a non-existing
page). (Perhaps the OfficeScan also, but that's unique so it could
probably be ignored.)
But they can't be added to the current scheme, unless requests and
responses (or grep expressions matching responses) are collected
together. And that breaks fingerprints files again.
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop
