Re: False positives scanning Red Hat servers running Apache

[Wyman Miles <wm63 () CORNELL EDU>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In general, the DoS risk isn't that severe.  And, you're not the only
person in the world who can cause one.  If you are, you probably don't need
to bother with vulnerability scanning.

Take various recent OpenSSL bugs, which pop up in our vulnerability reports
all the time, on the basis of reported version.  A real, hard test of NULL
cipher, SSLv2 rollback, etc, is truly benign, but vastly more informative.
Plenty of accurate, reliable tests can be performed without clobbering the
service -- I'd say most of the ambiguity we see in our server farm scans
could be turned into a black and white test without risking the service.

The risk of gentle checks is as much false negatives as false positives.
We can't expect to send sys admins off looking at every "There appears to
be an FTP server running on this port." but we sure can send them off
chasing, "I just exploited ProFTPD."


- --On Thursday, April 26, 2007 8:57 AM -0700 Allison Henry
<akhenry () BERKELEY EDU> wrote:

> Yes we see this problem with many vendors that backport patches --
> Apple, Ubuntu, RedHat, etc. And it is also possible that the sysadmin
> has taken other actions to mitigate the vulnerability, such as disabling
> the affected Apache modules, and we can't detect that either with
> version checking scans. We add a short disclaimer to our vulnerability
> notices:
>
>     Be aware that in some cases the "vulnerability" shown points
>     only to a potential problem:  for example, the scanner may have
>     detected a version of software that would be vulnerable only if
>     not patched, yet it cannot tell that a patch has been applied.
>
> While our scanner is capable of intrusive checks, I believe it is best
> to pass on the information we collect to the sysadmins for
> investigation, rather than risk running a DoS attack on our own network.
> It is a minor inconvenience to the sysadmins to check out a potential
> vulnerability than to restore a service brought down by the scanners.
>
> Allison Henry
> System and Network Security
> University of California, Berkeley
> http://security.berkeley.edu
>
> Clifford Collins wrote:
> > I've recently been scanning some servers on our campus that have
> > returned known vulnerabilities for Apache. I forwarded the results to
> > our Linux systems administrator. He investigated the claims and declared
> > them as false positives. His explanation was that Red Hat "backports"
> > patches to stable versions rather than deploying the newer version
> > because newer versions can introduce new features or changes that render
> > an existing server non-functional.  He was also critical of the scanner
> > for failing to detect the patches and relying on the reported version
> > number from a web query.
> >
> > Has anybody encountered this problem? Is there a solution or a product
> > that can detect undeclared patches on a Red Hat server without actually
> > doing a penetration test? Is there a query that will yield the patch
> > level? Your suggestions and comments are welcome!
> >
> > Clifford A. Collins
> > Network Security Administrator
> > Franklin University
> > 201 South Grant Avenue
> > Columbus, Ohio 43215
> > "Security is a process, not a product"



Wyman Miles
Senior Security Engineer
Cornell University, Ithaca, NY
(607) 255-8421
-----BEGIN PGP SIGNATURE-----
Version: Mulberry PGP Plugin v3.0
Comment: processed by Mulberry PGP Plugin

iQA/AwUBRjDN/8RE6QfTb3V0EQIvlACeMCOjYQhZpwCoNNW+GxZyLm0ohUcAoPlz
52bwK+HbdTCcxRTbtLwsOPPb
=uBi0
-----END PGP SIGNATURE-----