Planning your response to the OpenSSL DROWN vulnerability

When a major security risk like the new OpenSSL DROWN vulnerability strikes, you have to plan your response. Generally, you should start outside (Internet-facing) and work your way inside, and prioritize those servers which expose vulnerable network services over those that simply have an older package installed.

For more information on the DROWN security vulnerability (CVE-2016-0800) please refer to this Vulnerability Article.

Identifying risk

To help you respond to DROWN, Red Hat Insights reviews subscribed systems for a number of factors: the version of OpenSSL installed, what local processes are using OpenSSL, if those processes are listening on a network port, if that port is bound to a route-able IP address, and if that IP address is Internet accessible.

Insights ranks your risk based on the likely exploitability of a service. While all versions of OpenSSL without a fix for the new CVE (CVE-2016-0800) are vulnerable to attack, any assets also vulnerable to a separate security flaw (CVE-2015-0293) are much more susceptible to attack. That information, combined with inspection of listening processes and ports, gives us multiple levels of risk:

• A service on a public IP address is vulnerable to an efficient DROWN attack based on a combination of flaws. If these services are not firewalled off from the Internet, address these first.

• A service on a private IP address is vulnerable to an efficient DROWN attack based on a combination of flaws. A private IP address could be internally accessible or it may be internet facing but behind a proxy, like a load balancer. If the private IP address is providing an SSL service directly through a proxy - without SSL termination - it is effectively also an Internet facing service. If SSL termination first happens at a proxy or if the address is only routed locally, these services are at risk only for internal attacks.

• A service on a public IP address (similar to the first scenario) but not vulnerable to the efficient DROWN attack.

• A service on a private IP address (similar to the second scenario) but not vulnerable to the efficient DROWN attack.

• A server with the version of OpenSSL vulnerable to DROWN, but no known services are listening on route-able IP address.

While we recommend patching all servers, we know it’s impractical to restart every host and application at once. Start from the outside and work your way inside, and focus remediation first on those servers that are vulnerable to the efficient variation of the DROWN attack.

Once you have adjusted a host, you can re-run # redhat-access-insights to force a re-check of the system and verify within the Insights dashboard that a system was remediated correctly.

For more information on using the Red Hat Insights service in your infrastructure please visit the Getting Started guide.

Executing your response plan with systems management tools

Once you’ve identified the key systems you need to fix first, there are a whole lot of tools in your toolbox.

• Satellite
  If you are a Satellite customer, make sure you sync your Satellite server to get the latest packages. Once you have the latest packages, your new deployments out of the Red Hat standard channels will have the fix; for any deployments out of custom channels, make sure to copy the updated package over to those channels. For existing systems, you need to deploy the package everywhere and restart each server or at least those network services which are vulnerable.

• Ansible / Ansible Tower
  If you use Ansible, you can automate the restart process easily. The Ansible team has released example playbooks, and an overview. of how to use it to quickly and safely automate the full remediation, including restart. If you are using Ansible Tower, you can centralize and track your response across your entire infrastructure.

• CloudForms
  If you are a CloudForms customer your appliances can audit your environments and validate that the patches have been applied. Similar to the Insights service, CloudForms can provide a policy based compliance check which can be used to verify software and configuration of servers and validate security requirements. First update your appliance to the latest version by logging into the appliance as the root user and running # yum update or following the steps in the CloudForms documentation.
  Please see the CloudForms blog for detailed information on how to determine vulnerability with CloudForms.

You can also use utilize Red Hat Access Labs to test your systems vulnerability for the DROWN attack.