As you probably have heard by now, Heartbleed is the name of a new critical vulnerability in OpenSSL, the de facto open source library used in many applications to implement SSL and TLS. According to the Heartbleed website, a coding error in OpenSSL was introduced in December 2011 which allows remote attackers to read memory that could lead to divulging a server’s private key or other private in memory information. As described on the Heartbleed website, “ This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.”
Given the length of time the vulnerable code has been available it’s likely your server is vulnerable if you are using any of the OpenSSL 1.0.1 branches. CloudPassage customers are able to determine if their servers are vulnerable by using the software vulnerability feature of Halo. Furthermore, by making use of a CloudPassage-developed tool, coupled with our API, customers can obtain a consolidated list of all vulnerable servers.
Below I’ll be presenting a way to make use of a CloudPassage tool to obtain a consolidated list of all your vulnerable servers. Next, I’ll demonstrate a short snippet using Chef that will install the latest OpenSSL package and restart nginx.
While it sounds like the noise made by a cartoon character, OOTT is a Ruby program that collects information about your Halo-managed systems and presents HTML views of each group of machines (and one final report summarizing all of them). OOTT stands for “One Of These Things”. For a simple aspect of a system (such as “Account tjames exists”), it shows you how many systems have it:
OOTT outputs pages that are organized from highest priority to lowest, so you know where to start. The top half of the report holds the server aspects where they disagree. The bottom half holds the ones where they all agree. Inside both of those we start with critical+bad, then bad, indeterminate, and finally good.
The same tool can be used to discover all the Halo protected servers which are vulnerable to HeartBleed ( CVE-2014-0160 ). For example, here is a sample output you might see:
Once you have gotten the output, you can click the number to expand the list of servers that are registering as vulnerable.
The real benefit of a report like this shows up when you manage more than a few systems. OOTT does the work of summarizing a large number of server aspects such as presenting a consolidated list of all HeartBleed vulnerable servers.
For a more comprehensive review of OOTT, visit this blog: http://blog.cloudpassage.com/2013/04/16/one-of-these-things-is-not-like-the-others/
Giving it a try
OOTT and its associated readme and library are available at the CloudPassage Toolbox on Github. The install takes just a few minutes and requires Ruby and a few Ruby support libraries.
Using Chef to Automate Update OpenSSL Installation
At CloudPassage, we are big users of Chef to orchestrate all our server configurations. A quick way to ensure all your servers always have the latest version of the openssl package is to create a recipe that tells Chef to always upgrade the package.
An example Chef recipe snippet for this directive is below.
package "openssl" do
Even after the new OpenSSL package is installed you’ll want to make sure you restart services that use the library. For example, if you need to restart nginx on a bunch of servers, you can run a Chef knife command such as:
knife ssh -C 1 "chef_environment: AND recipes:*" "sudo /etc/init.d/nginx restart; sleep 60"
If you follow the above steps, you will have a comprehensive picture of the security state of all of your hosts in relation to the Heartbleed vulnerability. And you can take the necessary patching steps to remove the vulnerability.