CVE-2009-3555 and PCI Compliance

[gameman.pdcmail at myworkarea.net (gameman733)]

Sorry for bringing up an older topic, but this is one I've run into. One of
our clients was using Security Metrics (definitely agree with Jack Daniel as
far as the quality/results of the scan) who would continuously fail. Some of
the reasons were things like "Version X.Y.Z of $softwarepackage has a
security hole in this configuration. Please update."  The problem was two
fold however, 1) they weren?t using that configuration (example being a
specific module in Apache for example). 2) Redhat, from what I have
researched, backports all of their security updates. For example, Verison
2.1.4 of apache has some vulnerability, it gets fixed in 2.1.5. Red hat will
then take that fix, patch 2.1.4, and leave the version number alone. The
scan sees version 2.1.4, and flips out, making you as failing. Short of
completely moving to a totally different distribution (to my knowledge..),
there isn't much you can do short of compiling your own version. 

I was curious, in this situation, what would be the proper method of
resolving the issue? I assume there's a better way than fooling the scanner
(hackish solution, just needed it to pass as quickly as possible, etc.).  

-----Original Message-----
From: pauldotcom-bounces at mail.pauldotcom.com
[mailto:pauldotcom-bounces at mail.pauldotcom.com] On Behalf Of
genesiswave at gmail.com
Sent: Monday, December 21, 2009 10:17 AM
To: PaulDotCom Security Weekly Mailing List
Subject: Re: [Pauldotcom] CVE-2009-3555 and PCI Compliance

The automated scanners have a few problems. Not the least of which is that
they are a requirement for being PCI certified (but that is more of my own
view) I have had several customers fail their acan based on "open" ports
that were not open at all (138 and 139 on a Linux box without Samba
installed) The scans can catch things but from my experience and exposure to
the scans they are hitting on more false positives than they are hitting
actual errors (at least for our hosted clients who we provide management
for). If the false positives are as high as my experience leads me to
believe, it leads me to question how high a false negative rate these scans
have As far as the scan results for this particular issue, I'd recommend
going back to the vendor and push for their recommended solution for your
platform/OS Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Jack Daniel <jackadaniel at gmail.com>
Date: Mon, 21 Dec 2009 08:27:06
To: PaulDotCom Security Weekly Mailing List<pauldotcom at mail.pauldotcom.com>
Subject: Re: [Pauldotcom] CVE-2009-3555 and PCI Compliance

AAAAAAAUUUUGGGGHHH!

<RANT>
If anyone "fails" you on an assessment without providing guidance on
resolution/remediation/mitigation, your payment to them should "fail"
to appear.  Who was this, those (in my personal *opinion*) monkey sodomizing
rat bastards at Security Metrics?  Or just another Qualys scan pusher
without a clue or care?

I believe the appropriate questions are things like "what is exposed by
this", "what are the likelihood and impacts of compromise", "can we mitigate
a fundamental flaw in the protocol with additional processes", etc?

I'm still explaining to idiots like this why TCP 587 is listening on mail
servers.
</RANT>

As far as mitigation, maybe a patched proxy in front of the SSL/TLS
device(s) could handle it?  Or maybe nothing significant is actually exposed
by this?

<SHAMELESS SELF PROMOTION>
This kind of crap is what led me to get involved in an ongoing PCI DSS
conversation with a bunch of people- podcasts, articles, and talks to come.
I'll be on a panel at Shmoocon with some folks who actually know what
they're talking about, we'll be discussing the realities of PCI and its
impact on our industry.
</SHAMELESS SELF PROMOTION>

Who, me, too much caffeine? Nah.

Jack


--
______________________________________
Jack Daniel, Reluctant CISSP
http://twitter.com/jack_daniel
http://www.linkedin.com/in/jackadaniel
http://blog.uncommonsensesecurity.com




On Mon, Dec 21, 2009 at 5:09 AM, Monkey Daemon
<monkeywebdaemon at googlemail.com> wrote:
> Hi All,
>
> I've been speaking to a family member over the weekend who works in a
> similar line of work to myself and we got to talking about PCI
> Compliance.
>
> He's just had a quarterly scan performed and he failed it owing to the
> issues with Session Negotiation when using SSL/TLS. ?The problem he
> has is that he's running Linux and not only has his distro not
> released packages for OpenSSL 0.9.8l but the distro vendor is refusing
> to issue a patch stating that as its an issue with the underlying
> protocol there is no point.
>
> Does anyone have a fix to this other than "compile your own SSL with
> negotiation switched off and hope nothing breaks"?
>
> I'm now concerned that when our scan comes around early next year we
> will also fail.
>
> Cheers,
>
> MWD.
_______________________________________________
Pauldotcom mailing list
Pauldotcom at mail.pauldotcom.com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com
_______________________________________________
Pauldotcom mailing list
Pauldotcom at mail.pauldotcom.com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com