On Monday, security researchers at Google and Codenomicon reported a very serious vulnerability in OpenSSL, the world’s most popular encryption library used on as many as 2/3 of the internet’s web servers! This very serious flaw requires immediate attention by all companies that have encrypted websites with SSL / TLS. Lunarline patched our sites yesterday. Have you? Read on for more information about what to do.
What’s The Risk?
This flaw is an information disclosure vulnerability. It lets any attacker send a special encrypted request to any web server running the vulnerable OpenSSL software, and that webserver will send back 64KB of data from it’s own memory. What might this data contain? Well, it’s impossible to say, because it will be very particular to the circumstances on that server at the very moment that an attacker sends this request. However, as researchers began investigating the effects of this flaw on Tuesday, they quickly found that several very popular websites were disclosing sensitive data such as passwords, session IDs, and even private TLS keys! Attackers can send thousands of these requests repeatedly to unveil more 64kB blocks of memory – like scratching off a lottery card – until they uncover something valuable to them.
Researchers have given this flaw a visceral (and unsettling) nickname: heartbleed. This odd name is derived from the technical nature of the flaw. The flaw exists in a feature of TLS called heartbeat, which is a feature used for keeping idle connections from timing out, and as an information disclosure, it leaks sensitive data. The flaw also has a more benign name: CVE-2014-0160.
Note: this is not a remote code execution vulnerability! You do not need to worry about your server being compromised by any persistent malware, unless you are using OpenSSL in a very non-standard way.
What Should You Do?
The first step is to test all of your web properties where you are using TLS. You can easily check if your properties are vulnerable by using this excellent verification tool created by a talented Italian security researcher named Filippo Valsorda, who is about to become a household name. (Well, maybe only in a geeky households like ours!) If you don’t like using the online tool, Filippo has also released a command line tool, but it’s a little tricky to install.
If your sites are vulnerable, you should prioritize remediation based on the risk to your properties, paying particular attention to the “C” in the good old “CIA” triad: confidentiality. Due to the nature of this flaw, it primarily affects confidentiality, so focus your remediation efforts on servers with high confidentiality impact first.
You should consider the following 3 steps for a full remediation. Not all organizations or information systems will need all 3 of these steps, so we are presenting these in order of comprehensiveness. At a minimum, start with #1, then if you have more time or greater risk exposure, proceed with steps #2 and/or #3 until you have mitigated the risk appropriately for your organization.
- Patch all vulnerable versions of OpenSSL immediately.
- Revoke all existing SSL/TLS certificates and re-issue them with new private keys.
- Expire all sessions on the affected websites and require all users to reset their passwords.
Lunarline has chosen to perform all 3 of these steps on our 3 main public web properties (lunarline.com, scapsync.com, and schoolofcybersecurity.com). Although steps #2 and #3 may be considered paranoid by some, we viewed these as necessary steps for a vulnerability that has been exploitable without a trace for over 2 years. Also, it was a good exercise for our incident response team.
Finally, if you run a security operations center, you should update your intrusion detection (IDS) rules to start tracking exploitation of this flaw. Some researchers have already posted Snort rules for CVE-2014-0160.
If you’re interested in learning more, here are some links to essays written by the researchers who discovered the flaw as well as a couple of our favorite hackers and cryptographers.
- The researchers who discovered the flaw
- Matthew Green, a cryptographer at Johns Hopkins University
- Sean Cassidy’s technical analysis of the flaw at a source code level
We hope you found this exposition useful. If you are a Lunarline client, please reach out to your contacts at Lunarline if you have any followup questions. Otherwise, feel free to contact us through the comments section below.