SSL/TLS Protocol Vulnerability PCI Scan

[Deoxymono]

Hello,

VPS server is currently failing PCI scan due a SSL/TLS Protocol Vulnerability.

Server info: Parallels Plesk Panel v10.4.4 | CentOS 5

-------------
SCAN FAILURE

Protocol: TCP | Port: 443 | Program: https | Score: 4.3

Summary: SSL/TLS Protocol Initialization Vector Implementation Information Disclosure Vulnerability

Synoposis: It may be possible to obtain sensitive information from the remote host with SSL/TLS-enabled services. Impact: A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow information disclosure if an attacker intercepts encrypted traffic served from an affected system. TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected. This script tries to establish an SSL/TLS remote connection using an affected SSL version and cipher suite, and then solicits return data. If returned application data is not fragmented with an empty or one-byte record, it is likely vulnerable. OpenSSL uses empty fragments as a countermeasure unless the 'SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS' option is specified when OpenSSL is initialized. Microsoft implemented one-byte fragments as a countermeasure, and the setting can be controlled via the registry key H KEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\SecurityProviders \\SCHANNEL\\SendExtraRecord. Therefore, if multiple applications use the same SSL/TLS implementation, some may be vulnerable while others may not, depending on whether or not a countermeasure has been enabled. Note that this script detects the vulnerability in the SSLv3/TLSv1 protocol implemented in the server. It does not detect the BEAST attack where it exploits the vulnerability at HTTPS client-side (i.e., Internet browser). The detection at server-side does not necessarily mean your server is vulnerable to the BEAST attack because the attack exploits the vulnerability at client-side, and both SSL/TLS clients and servers can independently employ the split record countermeasure. See also : http://www.openssl.org/~bodo/tls-cbc.txt http://vnhacker.blogspot.com/2011/09/beast.html http://technet.microsoft.com/en-us/security/bulletin/ms12-006 http://support.microsoft.com/kb/2643584 http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspx Data Received: Negotiated cipher suite: AES256-SHA|TLSv1|Kx=RSA|Au=RSA|Enc=AES(256)|Mac=SHA1

Resolution: Configure SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure SSL/TLS servers to only support cipher suites that do not use block ciphers. Apply patches if available. Note that additional configuration may be required after the installation of the MS12-006 security update in order to enable the split-record countermeasure. See http://support.microsoft.com/kb/2643584 for details. Risk Factor: Medium/ CVSS2 Base Score: 4.3 (AV:N/AC:M/Au:N/C/I:N/A:N) CVE: CVE-2011-3389

-------------

It actually gave the exact same failing for ports 25 (SMTP), 465 (URD), 110 (POP3), 993 (IMAPS), 143 (IMAP) and 995 (POP3S) as well as the https listed above.

Is there any fixes for this?

N.B Just to confirm I have been through the steps documented here: http://download1.parallels.com/Plesk/PP10/10.4.4/Doc/en-US/online/plesk-pci-compliance-guide/

 

[Deoxymono]

Right figured out this is referring to the Beast attack which exploits vulnerabilities with block ciphers so switching them off should mitigate this.

However I had trouble getting my cipher changes to be applied to server. First I edited: /etc/httpd/conf.d/ssl.conf however changes to the ciphers didn't take effect. So I then added them to the end of /etc/httpd/conf/httpd.conf as well and that seemed to do the trick.

Used https://www.ssllabs.com/ssltest/ to check Beast attack vulnerability and it is now confirmed as not vulnerable.

Cipher config I used was:

SSLProtocol -ALL +SSLv3 +TLSv1
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH
SSLInsecureRenegotiation off

I hope this helps someone... as getting an answer on this forum seems to be pretty rare!

 

[Deoxymono]

OK scan failed again. It seems Security Metrics do not recognise "honorcipherorder" therefore you have to create a long list of not allowed ciphers instead.

Thanks to some help on another forum my cipher list now reads:

SSLCipherSuite RC4-SHA:HIGH:!ADH:!AES256-SHA:!ECDHE-RSA-AES256-SHA384:!AES128-SHA:!DES-CBC3-SHA:!DES-CBC3-MD5:!IDEA-CBC-SHA:!RC4-MD5:!IDEA-CBC-MD5:!RC2-CBC-MD5:!MD5:!aNULL:!EDH:!AESGCM

Currently scanning again, but have been advised it should now pass.

 

[HostaHost]

That may not work either. They're failing several more ciphers now. Try this explicit list rather than adding in all and trying to take away:

RC4-SHA AES256-SHA CAMELLIA256-SHA PSK-AES256-CBC-SHA DES-CBC3-SHA PSK-3DES-EDE-CBC-SHA KRB5-DES-CBC3-SHA AES128-SHA CAMELLIA128-SHA PSK-AES128-CBC-SHA

You'll also need to download and install a manually patched version of the lighttpd server since the one bundled in Plesk 9 and 10 has a renegotiation vulnerability:

http://forum.parallels.com/showthread.php?t=261475

Of course they're still going to fail you because of the Plesk courier version anyway (no current solution from Parallels):

http://forum.parallels.com/showthread.php?t=262127

And they're also going to fail you if clear text SMTP auth is enabled (no current solution from Parallels).

 

[Deoxymono]

Just to confirm it did pass with the ciphers I used. Thank you for the post anyway Hostasaurus.

 

[RalphPrice]

PCI Compliance CVE-2011-3389 (BEAST)

I have had no luck with Centos 5.5 Plesk 11 Server with the advice above. PCI scan still fails.

The PCI scanning company TrustWave comes up with the following:

The SSL protocol encrypts data by using CBC mode with chained initialization vectors. This allows an attacker, which is has gotten access to an HTTPS session via man-in-the-middle (MITM) attacks or other means, to obtain plain text HTTP headers via a blockwise chosen-boundary attack (BCBA) in conjunction with Javascript code that uses the HTML5 WebSocket API, the Java URLConnection API, or the Silverlight WebClient API. This vulnerability is more commonly referred to as Browser Exploit Against SSL/TLS or "BEAST".

Affected users should disable all block-based cipher suites in the server's SSL configuration and only support RC4 ciphers, which are not vulnerable to fully address this vulnerability. This vulnerability was addressed in TLS version 1.1/1.2, however, support for these newer TLS versions is not widely supported at the time of this writing, making it difficult to disable earlier versions. Additionally, affected users can also configure SSL to prefer RC4 ciphers over block-based ciphers to limit, but not eliminate, exposure. Affected users that implement prioritization techniques for mitigation as described above should appeal this vulnerability and include details of the SSL configuration.

It does not like the following Ciphers on a variety of ports which is what you would expect

TLSv1

AES256-SHA
AES128-SHA
DES-CBC3-SHA
RC4-SHA
RC4-MD5
EDH-RSA-DES-CBC3-SHA
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA


SSLv3

DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA
RC4-SHA
RC4-MD5
DES-CBC-SHA
DES-CBC3-SHA
EDH-RSA-DES-CBC3-SHA
EDH-RSA-DES-CBC-SHA
AES128-SHA
AES256-SHA


I have applied the CipherList as suggested to /etc/httpd/conf.d/ssl.conf and /etc/httpd/conf/httpd.conf and restarted web server

#
# Next Line Added by Ralph Price for PCI Compliance 4th December 2012
SSLCipherSuite RC4-SHA:HIGH:!ADH:!AES256-SHA:!ECDHE-RSA-AES256-SHA384:!AES128-SHA:!DES-CBC3-SHA:!DES-CBC3-MD5:!IDEA-CBC-SHA:!RC4-MD5:!IDEA-CBC-MD5:!RC2-CBC-MD5:!MD5:!aNULL:!EDH:!AESGCM

I have of course run the utility suggested by parallels that creates the ciphers.lst file though I do not know what this actually does. Should this also be edited?

Thanks for any suggestions

 

[Deoxymono]

Have to tried running the analyser here: https://www.ssllabs.com/ssltest/ to determine whether your cipher changes are taking effect?

 

[RalphPrice]

Thanks for the suggestion, I ran the ssltest utility

It reports:

Cipher Suites (sorted by strength; server has no preference)

TLS_RSA_WITH_RC4_128_SHA (0x5)

 

[RalphP]

The cipher list updated in /etc/httpd/conf.d/ssl.conf and /etc/httpd/conf/httpd.conf either:

1. Has taken effect but is not recognised by The TrustWave PCI Compliance scan. I may try and dispute to see what they say.

2. Is not updating the server for some reason. Is there anything that would prevent this? Some other configuration file I have missed or something about the Parallels patch for PCI that may have caused a problem?

Any suggestions thanks ...