I’m sure many of the people reading this blog post have heard about the recent exploit released Monday labeled CVE-2014-0160 better known to the Internet as Heartbleed.

Heartbleed is an exploit on OpenSSL version 1.0.1 through 1.0.1f that allows an attacker to pull arbitrary data out of a server’s memory to retrieve various information. How it works is in OpenSSL 1.0.1 where a feature was implemented named heartbeat that allowed a client to send a string of up to 65KB of data to a server that would be sent back as a heartbeat to make sure the handshake was alive. The problem with how heartbeat was implemented was that OpenSSL did not verify the requested length matched the provided length of data. This means that an attacker can send a heartbeat to a server 1 byte long stating it was 65 KB and retrieve the next 66559 bytes of data after that 1 byte of data in memory. This data can have anything, due to how servers function, so a lot of data has been leaked over this week.

Before I go any further, I want to state that we have checked all of CHILLOX ’s internal servers against the exploit once announced and, due to the version of OpenSSL we were running at the time, our servers were not susceptible to the attack, so no data was leaked from our service due to this exploit.

So, going back to what this does: let’s first look at a command on Linux named “free,” which outputs the memory usage on a server:

$ free -m

This is the output of my virtual machine in megabytes, which, granted, is pretty small, but the important part are the columns. “Total” is the total amount of memory and swap my machine has, “used” is what is currently allocated to processes, “free” is unused memory that can be allocated, “shared” is memory shared across processes (but to my understanding is not used anymore), “buffers” is data that is stored for a process temporarily, and “cached” is memory that was once used by a process but was released back to the pool with the data from the process stored.

The important takeaway from heartbleed and this command is the cached column. As a server is actually used, you will see free memory down to minimal numbers – sometimes even 128MB, but cached might be upwards of 16GB. That’s 16GB of released data that can be reallocated however it was once-used; data thrown away that could potentially be used by the application again, which would speed it up on the second run. The problem with heartbleed is when I send a packet that pulls just under 65KB of data, where does it come from on a heavily utilized system? It comes from cached, as that will be where the system will first allocate memory to my request. This means that I pulled just under 65KB of data from any random process that gave the memory back to the pool.

This 65KB of data can be anything on a server. While I personally have only tested the exploit internally against a lab environment, there have been reports of users able to obtain logins and passwords to websites in plaintext, session ids, and other various hacks. This exploit is so large and encompassing that not even the big names were safe from it. If you wish to protect yourself against this attack, there are quite a few options you can do. Your line of action, regardless of if a site were susceptible, would be to first refresh your sessions on any site by first logging out and, once logged back in, reset every single one of your passwords. Before you do this, you should test the site to make sure that it is not exploitable against heartbleed. You can run a test from Qualys SSL Labs, which has the ability to check a domain for the exploit. Once the test completes at the top you will see an alert that states if it is exploitable or not. If the site is exploitable, it is highly recommended that you do not log back into the site until the exploit is patched. Once patched you can then resume with changing your logins.

If you operate a server that you find exploitable, the repercussions are a little more drastic and action needs to be taken. First you must update OpenSSL to 1.0.1g and restart any service using OpenSSL. If you are unsure of which services to restart, a server reboot would be the best approach. Once patched, any SSL certificate on your server needs to be revoked and replaced. Due to the nature of cached memory, it is uncertain if the data leaked to a potential hacker contains your private key. After revoking and replacing your certificate, you need to clear out any open sessions on your sites to force everyone to re-authenticate, thus mitigating any leaked session data. Unfortunately, due to the nature of cache, it is uncertain how much user data is leaked so it is best to request all users of your application to reset their password or force one. If you are a client of CHILLOX’s and wish to have testing done or need assistance with fixing heartbleed, feel free to contact our support team, which will assist you.