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.

The following advisory is being sent to inform you of an upcoming maintenance in the cabinet your server is housed in, CHI-2 CR10, cabinet ED.120.

Event Date: December 11th, 2013 - 7:00 pm until December 11th, 2013 -11:00 pm CDT (GMT -5) Event Location: CHI-2

Impact: 15-35 minutes downtime per server, barring unforeseen consequences.

Event: During this maintenance, we will need to bring each server offline in ED.120 and relocate to another suitable cabinet space in the same Data Center room. Expected downtime is only 15-35 minutes per server maximum, though may take longer if the server must run a file system check, updates, or configuration changes made prior to the maintenance prevent the server from coming back online immediately. We will ensure each server comes back online properly after the move.

If you would like your server(s) to be brought offline during another time frame before the scheduled maintenance, please submit a ticket and we will take care of your request.

Thank You,

CHILLOX Data Center Operations

We are now live at our new website http://www.chillox.net

Following are changes took place in CHILLOX web hosting services.

CONTROL PANEL:
The new URL for Control Panel is https://Control.Chillox.net/cp the old URL has been disabled.

SUPPORT:
New Support website can be visited at https://Support.Chillox.net please login to the Control Panel to submit a Sales, Support or Billing Ticket.

IMPORTANT:

• All support issues and billing questions require to submit a support ticket unless the issue is 911 Priority. If you contact us via Online Chat or Telephone call we will ask you to submit a ticket. This will give us the ability to track all client's support issues and provide the support on first-come-first basis.
• To submit a ticket all clients are now required to login to the Control Panel.
• Old (DNN4Less Support site) will stay online until end of this year. Clients may login and check their old tickets.
• New ticket submission has been disabled in Old Support site.
• Please DO NOT re-open a ticket in the old Support site as that will not be monitored.

DNS (Name Servers)
Old DNN4Less Name Servers will stay the same, for new domains and accounts Name Servers will be NS1.CHILLOX.NET and NS2.CHILLOX.NET

DEDICATED SMTP EMAIL ACCOUNTS:
There is no change in DNN4Less SMTP Relay service; all clients will be able to continue using relay.DNN4Less.com for their SMTP Service.

If you have any question please do no hesitate to submit a ticket.  

Keith Galicia
Assistant Support Supervisor
CHILLOX