What you need to know about Heartbleed
I have been asked a number of times over the past few days by clients and employees to outline how to check and review the heartbleed stuff, and so I decided to publish a breakdown to help everyone see it more clearly. The past couple days has marked a new turning point in cryptography, exploits and IT security. I can not remember a security issue so wide-spread and ugly as what has become known as heartbleed. It turns out that an exploit was discovered that has existed for the past couple years that poses a serious threat to anyone running OpenSSL.
OpenSSL is the backbone of internet banking, secure IM, and e-mail. It is embedded in routers, switches, desktops, servers, web servers, vpn devices and just about anything else that is meant to be private. The short conversation is that this exploit allows an attacker to steal the private key (very important for security) of an ssl certificate, dump memory from systems, steal passwords, compromise systems, siphon data and do all of this completely undetected. No logs, no detection, not even a hint.
The only detection method requires complete packet captures—dating back two plus years—that you have access to replay and look for a specific signature and function call. Otherwise, there is no detection for this problem. This issue has a cascading effect. To check your vulnerability use a VM scanner or get a copy of this python code and run it.
Nessus, Symantec, and Rapid 7 all have scanner signatures already deployed. If you have a vulnerable server the following needs to happen.
If you want Novacoast to scan your outside interfaces click on the link and fill in the details. We will contact you today and scan your sites and outside infrastructure.
What you can do today:
All certs using Open SSL 1.0.1 through 1.0.1f, RHEL 6, Ubuntu, and others are vulnerable.
1. Patch the vulnerability. There are patches available today for most everything. This is the simple part of the issue.
2. Check and replace the type of SSL cert in the applications on systems that were vulnerable. Apache, nginx, etc.
a. Wildcard certs *.domain.com
i. If a wildcard cert was part of a vulnerable system then all systems using that cert are part of the issue.
ii. Identify everywhere that cert is used. (this is a big undertaking) There are automation tools for this.
iii. Regenerate a new private key in a secure location.
iv. Regenerate certificate using CSR.
v. Install the new certificate everywhere the old cert was used.
b. Common name certs are only different in that they only have direct issues with the single system involved.
i. The exception is if passwords are shared between any systems.
3. Change all passwords on all systems that are connected to vulnerable systems.
a. Anywhere certificates are used all passwords should be changed (users, services, db, etc.).
b. If passwords are shared then connected systems should also be changed as well.
4. Have change management and prevention tools to protect further damage.
a. While prevention tools would not have blocked this attack it would prevent further compromise of additional services.
5. Setup and Monitor.
a. There are several options for how to do this. I am happy to cover this.
From a user perspective.
1. Change your passwords. Find a list of patched systems. If they are unknown or not patched give it a few days.
a. Review this list of patched systems here.
b. If you shared passwords between sites you should change all passwords that were part of any site.
c. Passwords should be unique.
d. Use a password safe to protect passwords.
e. More info on heartbleed can be found here.
Thank you, good luck, and please ask for any help you need.
Adam Gray
CTO Novacoast, Inc.