6 Replies Latest reply on Oct 30, 2014 3:21 PM by pgbollwerk

    ePO 5.1.0 - CVE-2011-3389 vulnerability - no patch?

    pgbollwerk

      This vulnerability is showing up on a PCI audit scan for our ePO server that handles our credit card payment server VLANs.

      I cannot find any reference to a patch for this, or even an acknowledgement that this is an issue with ePO.

      The vulnerability is showing up on ports 443, 8443 and 8444, which are used by the ePO versions of Apache and Tomcat.

       

      From our Tenable Nessus appliance:

       

      Description

      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 HKEY_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.

      Solution

      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 Microsoft KB2643584 for details.

      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

       

      Output
      • Negotiated cipher suite: AES256-SHA|TLSv1|Kx=RSA|Au=RSA|Enc=AES-CBC(256)|Mac=SHA1

         

        • 1. Re: ePO 5.1.0 - CVE-2011-3389 vulnerability - no patch?
          fitchsoccer342

          When I go here, https://technet.microsoft.com/library/security/ms12-006, there are links to download the patch for OS's up to win2k8r2.

          This isn't a vulnerability associated with ePO itself, rather the cryptographic protocol that provides the communication security. I mean it basically looks like you just need to disable SSL 3.0 & TLS 1.0 and use TLS 1.1 & TLS 1.2 which are not affected by that vulnerability. Try that and re-scan with Nessus.

          • 2. Re: ePO 5.1.0 - CVE-2011-3389 vulnerability - no patch?
            JoeBidgood

            5.1.0 definitely shouldn't be vulnerable to Beast: it uses Java 1.7.0_45, and Oracle patched this in 1.6.0_29 and later as far as I know.

            I think this is the important bit:

             

            "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."

             

            HTH -

             

            Joe

            • 3. Re: ePO 5.1.0 - CVE-2011-3389 vulnerability - no patch?
              pgbollwerk

              I appreciate the responses, but unfortunately, the patch for MS12-006 is already installed.

              Also, these registry entries already exist:

              [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ Protocols\TLS 1.1\Client]

              "DisabledByDefault"=dword:00000000

               

              [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ Protocols\TLS 1.1\Server]

              "DisabledByDefault"=dword:00000000


              This "fix it" solution has also already been applied:

              Fix it solution for TLS 1.1 on Windows-based servers

              MS12-006: Vulnerability in SSL/TLS could allow information disclosure: January 10, 2012


              Any other suggestions?

              • 4. Re: ePO 5.1.0 - CVE-2011-3389 vulnerability - no patch?
                pgbollwerk

                I think the reason these Microsoft fixes are not working is because ePO uses Apache and Tomcat on ports 443, 8443 and 8444. These are tied to OpenSSL, aren't they? (as opposed to IIS)

                This blog post seems to imply a need to edit and recompile code from OpenSSL...

                BEAST, OpenSSL and Apache | Arcticdog's Kennel

                 

                You have two options, Do one of the following:

                1. Change OpenSSL (this assumes v1.0.1c)
                  This has the side effect of making sure the countermeasure is enabled in any further apps you compile.Edit include/openssl/ssl.h and change:
                    #define SSL_OP_ALL 0x80000BFFL
                  to:
                    #define SSL_OP_ALL 0x800003FFL
                  Then recompile OpenSSL (not sure its necessary, but to be safe), and then recompile mod_ssl. Restart apache.
                2. Change ApacheEdit modules/ssl/ssl_engine_init.c and change (around line 486):
                    SSL_CTX_set_options(ctx, SSL_OP_ALL);
                  to:
                    SSL_CTX_set_options(ctx, SSL_OP_ALL & ~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS);
                  Recompile mod_ssl. Restart apache.
                • 5. Re: ePO 5.1.0 - CVE-2011-3389 vulnerability - no patch?
                  pgbollwerk

                  The recommendation from the auditor is to "disable SSLv2, SSLv3 and all CBC ciphers".

                   

                  I poked around in the Apache config that ePO creates and noticed these items in the ssl.conf:

                   

                  SSLProtocol +TLSv1


                  SSLCipherSuite DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-D ES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHAEXP1024-DHE-DSS-DES- CBC-SHA:EXP1024-DES-CBC-SHA:DES-CBC3-SHA


                  Based on this, I assume SSLv2 and SSLv3 are already disabled for Apache, but I do see some CBC ciphers listed. I am going to experiment with removing them and see if it breaks ePO and if this resolves the vulnerability on port 443.


                  UPDATE: I removed the CBC ciphers (but not CBC3, as those should be fine) and restarted the McAfee ePO server (Apache2.2) process. I then tested agent communication from a managed client and it appears to still work fine. Unfortunately, the vulnerability still shows. I may need to force TLSv1.1 and TLSv1.2


                  UPDATE 2: It looks like the Tomcat server.xml for McAfee ePO ONLY uses "TLS" (which will fall back to SSLv3 if you don't force TLSv1 and higher) and CBC cipher suites...


                  sslProtocol="TLS"

                  ciphers="

                                 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,

                                 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,

                                 SSL_RSA_WITH_3DES_EDE_CBC_SHA,

                                 SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA,

                                 TLS_DHE_DSS_WITH_AES_128_CBC_SHA,

                                 TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,

                                 TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,

                                 TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,

                                 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,

                                 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,

                                 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,

                                 TLS_DHE_DSS_WITH_AES_256_CBC_SHA,

                                 TLS_DHE_RSA_WITH_AES_128_CBC_SHA,

                                 TLS_DHE_RSA_WITH_AES_256_CBC_SHA,

                                 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,

                                 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,

                                 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,

                                 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,

                                 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,

                                 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,

                                 TLS_RSA_WITH_AES_128_CBC_SHA,

                                 TLS_RSA_WITH_AES_256_CBC_SHA,

                                 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA

                                 "

                   

                  Not sure what to do to resolve this other than contact McAfee.

                  • 6. Re: ePO 5.1.0 - CVE-2011-3389 vulnerability - no patch?
                    pgbollwerk

                    Well, I fixed all the vulnerabilities, but it breaks the agent communication.

                    This seems like a pretty clear issue with McAfee's software.

                    The specific part that breaks agent communication is when I edit the following line in the Apache ssl.conf file:

                    SSLProtocol All -SSLv2 -SSLv3 -TLSv1

                     

                    Note that the original line is:

                    SSLProtocol +TLSv1


                    This means that the agents CANNOT communicate using TLSv1.1 or TLSv1.2

                    McAfee should really fix this by either updating the protocols used, or stop using CBC ciphers.