> Within 15 minutes of
> manual testing we found the web server to be
vulnerable to both the UTF-8
> and double decode vulnerabilities. The reason
for this was simply that the
> tools (which I will not name) presumed that
Windows NT is always installed
> in a directory called winnt, when in this case
it was installed in a
> directory called winnt40. This was enough to
throw the automated tools way
> off of the scent.
Which is a great argument for vulnerability
assessments. Yes, many tools are scriptable, but
even Nessus doesn't go as far in Win32
environments as you _can_ go with the right tools.
Generally (and in order to set the playing field
here) a pen test is done in the blind, or with
very little information. The more prior knowledge
a pen tester has, the less 'fair' the test is
going to be. However, the lack of prior knowledge
can extend the time of the pen test, depending on
what was contracted.
Vulnerability assessments are done internally,
with the full cooperation of the admins. This
means interviews of key personnel, and consultants
have admin accounts in the domain in order to run
their tools (NOTE: Observing closely how the
admin account is set up and then taken down will
tell the consultant quite a bit about the
organization).
Given that, information such as which directory NT
or 2K is installed in will be available on a
per-machine basis. I've written tools like this,
it's not all that difficult.
> Also, what about custom CGIs, ASPs etc, they may
be vulnerable to /../
> attacks, SQL injection etc etc, but there isn't
(to my knowledge) any 100%
> sure fire reliable way to test for these
automatically in this scenario. To
> do the test properly you need to apply the
methodology to the custom
> environment.
Or do a code review. Doing a code review in a
test environment allows the consultant to test and
verify his findings before presentation. Very few
systems are set up identically, so a vulnerability
in a script may mean one thing to one
infrastructure, quite another to someone else.
> I think a more suitable question is why would
you pay a 'Consultant' good
> money to hit a big green go button and print the
results?
You don't. A drunken monkey can do this (I've
seen it! Just kidding...sorry, KoKo). But that
is what many organizations do. It's not up to the
consultants to meet an arbitrary standard based on
someone else's moral code...they're in it for the
money, and have a business model to follow. It's
up to the company who hires and ultimately pays
for the consultant to vet these organizations and
find one that is suitable.
One way of doing it is to ask the consulting firm
for references...but they'd be fools to give you
negative references, wouldn't they? So when
you're talking to them, find out what their model
is, how they go about doing things.
In the end, it's a crap shoot, really. That's b/c
whatever the sales guy tells you in your meetings,
there is no legal requirement that the deliverable
be anything but an ISS report printed on company
letterhead.
The key differentiator is analysis...how does one
measure that before hand?
----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/
Received on Sep 10 2001
Intro
