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:
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.
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.
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.
I appreciate the responses, but unfortunately, the patch for MS12-006 is already installed.
Also, these registry entries already exist:
This "fix it" solution has also already been applied:
Any other suggestions?
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...
You have two options, Do one of the following:
#define SSL_OP_ALL 0x80000BFFL
#define SSL_OP_ALL 0x800003FFLThen recompile OpenSSL (not sure its necessary, but to be safe), and then recompile mod_ssl. Restart apache.
modules/ssl/ssl_engine_init.cand change (around line 486):
SSL_CTX_set_options(ctx, SSL_OP_ALL & ~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS);Recompile mod_ssl. Restart apache.
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:
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...
Not sure what to do to resolve this other than contact McAfee.
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:
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.
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."