Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 7194
  • Last Modified:

AES 5510 fails PCI Security Scan

Hi All,

I need some help on a failing PCI scan.   It's down to one error  - Protocol  TCP  Port 443 Program https and a score of 4.3.   The ASA 5510 is configured to negotiate with SSL V3.  The other choices I have to choose from are  Negotiate SSLV3, Negotiate TLS V1 and  TLS V1 only and the following algorithms  are listed top down order - RC4-SHA1, AES128-SHA1, AES256-SHA1, 3DES-SHA1, DHE-AES128-SHA1, DHE-AES256-SHA1.
The info about the failure follows.  I would really appreciate any help I can get on solving this.  Thank you.

Here is the information:
Description: 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: AES128-SHA|TLSv1|Kx=RSA|Au=RSA|Enc=AES(128)|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:P/I:N/A:N) CVE: CVE-2011-3389
1 Solution
is this to the ASA itself, or to an SSL application "behind" the ASA ?

if it is to the ASA itself, it would read as if you have not applied any access controls to accessing its management port.

the failure reads like the "beast" attack.
Although the suggestions they gave you are inappropriate for an ASA, or rather... more geared towards general purpose web servers;

"the following algorithms  are listed top down order - RC4-SHA1, AES128-SHA1, AES256-SHA1, 3DES-SHA1, DHE-AES128-SHA1, DHE-AES256-SHA1."

If you SSH into the ASA, and shut off all the CBC TLS 1.0  cipher suites other than RC4-SHA1,
for HTTPS the "vulnerability"  is gone.

If you manage the ASA exclusively from an up-to-date browser  with a workaround,  the vulnerability is gone.

If you apply an ACL to the ASA, choose to disable HTTPS entirely or, to accept HTTPS connections only from a smaller list of local  trusted LAN IP addresses,  with up-to-date browser for ASA management, the org scanning won't be able to  "scan" it;   any HTTPS vulnerability will be mitigated,  because there won't be an accessible "HTTPS service".

Of course, my recommendation would be to manage the ASA using SSH and disable HTTPS.

Obviously, you may not be able to  do that if you rely on the   ASDM  for ASA device management,  or you are utilizing a device functionality that relies on SSL access from remote mobile locations.
NewbieITGalAuthor Commented:

Passed the PCI security scan after setting the cipher to only  RC4-SHA1

Featured Post

Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now