[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200509272123.j8RLNkMZ023377@turing-police.cc.vt.edu>
Date: Tue Sep 27 22:24:04 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: CORE-Impact license bypass
On Tue, 27 Sep 2005 17:53:58 +0200, Bernhard Mueller said:
> so what use is a pentest if the consultant isn't even talented enough to
> find / create exploits for unknown vulnerabilities?
Quite a bit, actually.
Consider every pen test ever done by a consultant who wasn't that talented, but
who found and reported *actual* security holes in the target network anyhow.
Are you saying all those pentests were worthless?
> any average admin can install and run an automatic security scanner.
Right. Sometimes, it's just the convenience factor - the fact that I *can* change
the oil, spark plugs, and brake pads on a car doesn't mean that I'd *rather* do
it myself than pay somebody else $20 to do it for me. Similarly, my servers
running Red Hat have software maintenance contracts on them, even though I
*could* debug software myself, simply because (a) sometimes it's a trivial
bug and I can't be bothered to track it down because I'm busy doing something
more interesting that instant or (b) it's a major issue and I don't have the
time to get up to speed on all the ins and outs of how a particular RAID
controller interacts with a particular kernel driver.
And then you get to the place where the consultant can be a value-added:
> furthermore, a common nessus report contains 99% useless garbage. and
> most of the time, you can not apply generic exploits like these from
> metasploit to a specific customer situation.
The average admin does *not* have the skills/time needed to sort out the 99%
useless garbage. And in the network-wide sense, there are often transitivity
problems where D has a known-but-difficult-to-fix hole, but is only reachable
from C - and nobody realizes that a minor issue on B can let somebody on A
leapfrog to C and then hit D.
Found a box once that had at one time a 3rd party package, since removed.
The package removal had left a line in /etc/hosts.equiv for *one specific host*,
also since departed from the DNS. And the box had a packet filter ruleset
to only accept DNS from the "real" DNS servers. (You can see where this is
heading, right? :) Well, the admin of the box could see it *once it was
pointed out to them*. Didn't mean that they had the time to find it themselves.
> in my experience, nearly all sites have some serious security flaws even
> if tools like nessus say the contrary. there may be self-coded
> applications or software that is not widely known or tested so they're
> not found in any vulnerability database. or, if that is not the case,
> you may even find new flaws in well-established software.
Notice that most home-grown apps have issues - and the people who wrote
them are usually unqualified to find them, simply because they have a big
blind spot because they're too close - "forest for the trees" time. A
fresh set of eyes from outside can help a lot here.
And note also that "finding a hole" and "be talented enough to create an
exploit" are *totally* distinct. I found a rather nasty rootable hole in
Sendmail a while back (read the release notes for 8.10.1 and the relevant
manpages for the system linker - that gives enough info to figure out what the
bug was). Never did create a working exploit for it - I fooled with it for an
afternoon and only got as far as proving that if somebody were to spend more
than an afternoon on it, they *could* produce a working exploit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050927/56d38db4/attachment.bin
Powered by blists - more mailing lists