What’s the Heartbleed bug? How does it work?
On April 7th, 2014, a security vulnerability in the OpenSSL encryption software was revealed, which affects millions of servers around the world. The bug allows users to send a specially-crafted “heartbeat” packet to an affected server, requesting more data than would normally be requested. Because of a coding error in the TLS feature of OpenSSL, the size of heartbeat data is not checked, so up to 64KB of OpenSSL’s memory contents in RAM is returned to the user:
(source: www.xkcd.com/1354)
What information is contained in the 64KB following this memory location can vary, but it has been seen in tests that just about any piece of information which is used or encrypted/transmitted by the SSL library (including the private decryption keys) can be revealed. Further exacerbating the problem, the OpenSSL software library is used by many other pieces of software to perform encryption for secure connections, which means that they may be vulnerable as well. Hardware manufacturers have announced that some of their equipment use vulnerable versions of OpenSSL, meaning they will need software/firmware updates.
Can I use a testing websites to test my server?
After this bug was revealed last week, multiple websites were created, which would allow you to enter your website address to test for the Heartbleed bug. However, if you believe your servers may be vulnerable, by submitting your server to a random website to be tested could be insecure: you cannot be sure if they are even testing your server properly, or if they have malicious intent. For all you know, these could tell you that you are not affected by the bug when you are, then exploit the bug constantly to steal information from the server.
What if I have many servers to test for the Heartbleed bug?
If you have more than one server to test, using web-based testing tools is also impractical. Network Administrators need to test all of the servers in their organization, and Hosting Providers may want to scan their entire networks to ensure that their customers are safe. Luckily, Heartbleed testing tools have been quickly developed to make this task manageable.
How can I test for the Heartbleed bug?
With these concerns in mind, here are some simple programs which can be used to test your own servers and devices. These tools are designed for Linux operating systems, and you can view the source code for them to see exactly what these programs do. Almost any Linux distribution should work, in our case, we signed up for a third-party virtual server running the newest version of Ubuntu Linux, which you can lease for less than $20.00/month. The “heartbleed-masstest” script can be used to scan your network, and gives a simple “yes or no” verdict for each of your servers’ IPs:
https://github.com/DOSarrest-Internet-Security/heartbleed-masstest
Where should I test from?
You should first test from a server that is external to your network, to see which servers may be vulnerable on the public Internet. These are the highest priority, as they could be being exploited at the moment. If you have private/internal IP ranges or firewalls implemented in your network, you should also test from a server internal to your network as well.
How do I fix the bug if my server is vulnerable?
If you find that one of your servers is vulnerable, you should update the version of OpenSSL on your server.
The vulnerable versions are:
- 1.0.1
- 1.0.1a
- 1.0.1b
- 1.0.1c
- 1.0.1d
- 1.0.1e
- 1.0.1f
If you have one of these version installed, you should upgrade to at least 1.0.1g, which includes a fix for the Heartbleed bug. Most Linux distributions have updated the OpenSSL package on their software repositories on the day the Heartbleed vulnerability was announced, and patched the affected older versions as well for users who do not want to upgrade to the newer version. If you compile SSL from source code, and need to keep one of these versions, you can use the -DOPENSSL_NO_HEARTBEATS compiler flag to disable the TLS feature.
Because there may be many programs running on your system which have the old version of OpenSSL loaded into memory, after you have upgraded OpenSSL and rebooted, you should run the test on your server again to verify that you are not vulnerable.
I found vulnerable servers, and patched them. Now what?
Because this bug has been present in OpenSSL for the last 2 years, any malicious users who knew about this bug could have been siphoning data off of your vulnerable servers since then. Heartbeat packets are not logged by the server, so there is no way to know if your vulnerable server has been exploited. As such, after patching your servers, you should:
- Generate a new private SSL key.
- Use your new private key to request a replacement SSL certificate from your SSL Cert Issuer.
- Install this new SSL cert on all systems and software which used your old certificate.
- Revoke/blacklist your old/compromised certificates with the SSL Certificate Issuer in case they have been stolen.
- Update all of your passwords which may have been entered over a secure SSL connection in the last two years for the affected servers.
- Notify and or force users on your system to update their passwords.
The effects of the Heartbleed bug continue to be felt, as more vulnerable systems and software continue to be announced. Using the script mentioned above, you can check your entire servers’ IPs, and verify that your servers are not vulnerable. It would also be advisable to perform security audits on your individual servers, and consider adding a HTTP/SSL protection service such as the one offered by DOSarrest, which have protected customers’ servers from this Heartbleed bug. At the very least, anybody who has a web server should be running an external penetration test to verify that their servers are not vulnerable.
We are offering to test any or our customer’s servers for the Heartbleed bug,
contact CR@dosarrest.com for more information.
Matthew Manuel
Systems Engineer
DOSarrest Internet Security LTD.
