Ugh, don't get me started on "security audits". Most vendors are extremely
diligent about releasing patches to security issues. The problem is, they
often do it by backporting the security fixes to the release that they're
running. This is often much preferable to releasing the updated software,
as that may introduce changes that you don't want.
The big problem with this is that when "Security consultants" run
their automated scanners against a server, they see the banner for "Sendmail
8.x.x" and they say that we're running a vulnerable version of sendmail.
I get handed this report with red alarm bells all over it, and I have to
explain, yet again, that we are not running a vulnerable version of X
software, it's just that whatever team of "security consultants" that the
client hired are a bunch of con men who charge through the nose to run a
TCP scan, and don't actually do any penetration testing at all.
Or there's the time that the security team from a Fortune 500 high-tech firm
ran a scan against
our webserver and reported hundreds of perl, and php scripts that just do
not exist anywhere on our webserver, we got a list of URLs that looked
something like this.
http://:443/cgi-bin/guestbook.pl
There were hundreds of them, all of them exploitable web scripts, most of
them were actually familiar and I knew that none of them had ever existed
on this java webserver. But they were all responding to the request with
weird garbage. It took me over an hour of going over the webserver config
before I realized that the garbage they were getting back was encrypted
http, because they were requesting http over the https port. So the
garbage they were getting back was an encrypted 404 message.
Published
09 February 2008