Skip to content

Taming POODLE using Kaseya

So yet another SSL vulnerability was discovered, and this one is not something they can simply issue a patch for, as it takes advantage of the existing SSL 3.0 protocol.  The only fix is to basically turn the protocol off, so it can’t be used.

If you want full information about POODLE , you can read about it here:  https://technet.microsoft.com/library/security/3009008.aspx  or here: https://www.us-cert.gov/ncas/alerts/TA14-290A

This vulnerability affects both servers and client browsers, but we expect that the browser vendors will eventually release versions that disable SSL 3.0 by default, so we are focused on providing a fix for the servers.

The good news is that the fix is pretty easy…   Just some registry changes as documented by DigiCert.

To remediate this we created two scripts.    One is an Audit script that you can use to see how things are set.   The 2nd is the “Fix”.   This script will download the reg keys and update add them. The final step is that a reboot is needed for these changes to take effect.

The scripts can be downloaded here, and should be imported as a folder.

For our sister company Network Depot, this meant rebooting hundreds of servers, when most of them are not public facing.    So we brainstormed on how to ONLY show machines that are in fact using SSL (in general).     We created a SSL Binding Audit, and used a previously blogged about trick, to allow us to create a custom view, showing only those machines that have SSL bound (443 only).   NOTE:  We discovered that there were some VM Host machines that had this bound as well, so make sure you review your results.     We cut the number of servers needing an immediate reboot by 75%!

Here is a screenshot of the custom view:

SSL Binding Audit – Custom View settings

As always, please run your own tests, and let us know if you run into any problems, or think of a better way to do it!

 

Scroll To Top