Addressing SSLv3 POODLE vulnerability

[#1]

Version


This issue applies to all versions of Bit9 and Carbon Black.




Issue

The fallback to SSLv3 vulnerability "POODLE" was made public October 14th, 2014 by Google: http://googleonlinesecurity.blogspot.ie/2014/10/this-poodle-bites-exploiting-ssl-30.html.




This solution as well as the Bit9 blog post explain the remediation steps: https://blog.bit9.com/2014/10/15/bit9-carbon-black-poodle-sslv3-vulnerablity-status/





Solution

How can I immediately work around this vulnerability for my Bit9 Platform server?




POODLE can be completely addressed by ensuring that the Bit9 Platform server configuration does not allow the use of the SSL v3 protocol. You can disable SSLv3 on your Bit9 Platform server by executing the attached disablesslv3.reg file [sha256: 798497f49fbc677f5c3563f11cac0997b3bdabd2bf35ca80e5f63abc19865e44] and then rebooting the server. The reboot is required.




Note: The Bit9.com blog post will be updated to include screenshots showing how to make these edits manually in regedit.exe.




How can I immediately work around this vulnerability for my Carbon Black server?




POODLE can be completely addressed by ensuring that the Carbon Black server configuration does not allow the use of the SSL v3 protocol. This step will be required on each Carbon Black server in a Carbon Black deployment, including both master and minion nodes in a clustered deployment.

Carbon Black uses nginx as its SSL termination proxy. Therefore, addressing the POODLE vulnerability can be accomplished by updating nginx configuration to avoid use of

1. Edit the nginx configuration file:
   

   vim /etc/cb/nginx/conf.d/cb.conf

   Note: If using a cb-multihome.conf file that segments the Web UI and Sensor ports, update the cb-multhome.conf file and make the below change only to the server { } directive for the Web UI.
   
2. Add the following line within the server { } directive:
   

   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

3. Restart cb-enterprise services:
   For a standalone installation
   

   service cb-enterprise restart

For a clustered installation

          /usr/share/cb/cbcluster stop
          /usr/share/cb/cbcluster start

An example of an updated cb.conf file is below. The added directive is highlighted in bold.

server

{

# IMPORTANT: If listener configuration is updated here, make sure to

# also upate corresponding Nginx#### parameters in /etc/cb/cb.conf file

listen [::]:80 ipv6only=off;

listen [::]:443 ssl ipv6only=off;

include /var/run/cb/nginx.runtime.ssl_certificate.prop;

include /var/run/cb/nginx.runtime.ssl_certificate_key.prop;

ssl_client_certificate /etc/cb/certs/cb-client-ca.crt;

ssl_verify_client optional;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

# By default, serve HTML + CSS for the UI

root /var/www/cb/;

How can I confirm that my server has been updated correctly?

If your server is accessible from the internet, you can use Qualys SSL Lab’s excellent SSL test tool. In the Configuration / Protocols section, you should see SSL 3 listed as “No” (and SSL 2 should also be a “No” or you are vulnerable to other more severe vulnerabilities).




If your server is not externally accessible, you can still test it easily using openssl:

openssl s_client -connect [YourServer]:443 -ssl3

If you successfully connect, then your server is still vulnerable. If you get a handshake failure or the connection aborts (returning you to your command shell/console/terminal), then you are not vulnerable.




Important Note(s)

Please refer to the Bit9.com blog post which includes these remediation steps for both the Bit9 Platform server and Carbon Black Enterprise server:

https://blog.bit9.com/2014/10/15/bit9-carbon-black-poodle-sslv3-vulnerablity-status/