Experts Discuss The Heartbleed OpenSSL Bug
"On the scale of 1 to 10, this is an 11," wrote security expert Bruce Schneier in a blog post this week. He was referring to Heartbleed, the devastating two-year-old bug that was only revealed Monday. Join Co.Design senior writer Mark Wilson for a live discussion with security expert Wayne Jackson and RedMonk analyst Donnie Berkholz about the implications of this vulnerability on Wednesday, April 9th at 3pm ET.
The discussion will begin at 3pm ET on Wednesday, April 9th (scroll to the end of this page to submit your questions to the chat). Until then, be sure to read Fast Company writer Chris Gayomali's explainer on the Heartbleed OpenSSL bug. Here are the basics:
WHAT IS HEARTBLEED?
It's a bug in OpenSSL encryption, a software library that Google, Facebook, Yahoo, Amazon, and a very big chunk of world's biggest websites use to secure the transmission of private information. The average user is probably unfamiliar with OpenSSL, but it is represented in your URL bar by the little lock symbol, next to HTTPS. Essentially, the exploit gifts hackers and cybercriminals a skeleton key to a hidden world of private data. They can waltz in, reach into a grab bag of secure information (emails, IMs, passwords, etc.), and walk away without a trace.
HOW WIDESPREAD IS IT?
According to Schneier, about half a million websites have been made vulnerable to attack. Although the exact extent of the damage is unclear, security experts say this is exactly the kind of easy vulnerability hackers have a field day with. "It affects two-thirds of the Internet's infrastructure," Wayne Jackson, security expert and CEO of Sonatype tells Fast Company. "I don't think this is all that different from bugs that we see that get reported. It's just that this one is foundational."
HOW IS THE PRIVATE DATA GATHERED?
Heartbleed allows hackers to reach into the exchange of private computer memory handled by OpenSSL, allowing them to pull out information en masse. What gets pulled out is randomized: Sometimes you'll get something benign, like a timestamp. Worst case is they'll get something like the encryption key itself. It's like a private-data piñata.
-
Hello everyone! Thanks for joining us today. We'll be starting in just a few minutes.
-
Be sure to get your questions in now if you'd like them to make it to our discussion!
-
Alright, we're ready to get started. I'm here with security expert Wayne Jackson and RedMonk analyst Donnie Berkholz. Thanks for joining us today!
-
We're obviously here talking about the Heartbleed OpenSSL Bug. (Read background on it here if you haven't.) And my first question may be the most obvious one:
-
In short, YES! Who knows how long this vulnerability has been know to the black hat community but I'm guessing a while.
-
I'm not the only one with that concern - Bruce Schneier declared it
"Catastrophic" is the right word. On the scale of 1 to 10, this is an 11." -
Some of the most worrisome aspects of this, to my mind, are what's happened since its public announcement on Monday. While many companies were quick to respond and fix this huge security hole, a significant percentage of laggards remain insecure today. That means that not just black hats who were already "in the know" but any script kiddie is now capable of exploiting those sites.
-
It's about as bad as I can imagine - an easily exploitable flaw in a library that is supposed to be making communications *more* secure that allows hacker to, among other things, steal digital certificates and credentials without leaving a trace!? And, oh by the way, it is by far the most popular SSL implementation used by roughly 2/3 of the sites on the web.
-
Errata Security showed that 600,000 sites out of 28 million remained vulnerable, for example. While a small percentage, it's still a large absolute number.
-
So Donnie, you actually dug through the top 1000 most popular websites, and found, what, that almost half still haven't patched the SSL problem with an updated version yet? Anyone we know on that list?
-
Donnie makes a great point. One of the huge problems in the industry is the informational advantage that the bad guys have. The path of disclosure (combined with sample exploit code) is just way more efficient for the bad guys than the good.
-
From the top 10,000 websites on a popular ranking called Alexa, I was able to confirm that around 15% of sites reachable by SSL (how this security hole is reached) were still vulnerable yesterday, and nearly a third of those remain vulnerable today. A few examples people might recognize are toshiba.com, inc.com, and twitpic.com.
-
Coincidentally, since that list's most recent update this morning, inc.com is fixed. So good for you!
-
Wayne, so what were you saying about how the bad guys have an advantage over the good guys? If the black hat community knows about an exploit--and it's fairly public in some circles--why can't private businesses with IT staffs, etc, defend against that exploit?
-
For instance, I read that this bug could have been known about for two years.
-
Disclosures like this (though not necessarily as bad) are made constantly. For folks on security teams, having the context to know whether to care and/or take action is often lacking. Very few organizations have an inventory of what versions of what components in
which applications have been deployed so prioritization is tough. For the bad guys, on the other hand, they only have to know that some number of people out there are affected and that the using the exploits can have an interesting ROI. -
Pinterest was one of the slower "major" sites to respond, along with Yahoo. Both of them were still vulnerable yesterday afternoon but were fixed by this morning. Fortunately most shopping and financial sites were fixed extremely quickly, and those are where much of the risk lies in this hole.
-
So basically, the bad guys can use an attack like "one size fits some."
-
How did exploiting this bug actually work? In the stupidest terms you can describe it.
-
I found this video describes it in terms I understood:
info.elastica.net -
Here's the video:
OpenSSL Heartbeat (Heartbleed) Vulnerability (CVE-2014-0160) and its High-Level Mechanics from Elastica Inc on Vimeo.
-
This might be a little in the weeds but two core OpenSSL services, TLS and DTLS were implemented such that Heartbeat Extension packets can be manipulated to trigger a buffer over-read. That over-read allows memory to be 'scraped' in 64k chunks, as demonstrated by reading private keys.
-
Haha, no offense, but I'm sticking with the video, Wayne.
-
Do we wait to change passwords for server updates as The Guardian suggested or do we change them right away?
-
Nearly every major website has now been updated, since it's now 2 days post-announcement. So for the vast majority of cases, it should be safe to update your passwords now. If you want to specifically check whether a "secure" server you're connected to is actually secure, here's one option.
-
This is also a good reinforcing event for why we should be following sound password practices - using different passwords for different sites and changing passwords frequently, for example.
-
Donnie, Wayne, have the two of you changed your passwords yet?
-
I made a point of not logging into any finance or shopping sites since the public announcement, and I am not as concerned about prior knowledge by black-hat hackers or the NSA, so I have not.
-
It all depends on the risk profile you're willing to accept, and the consequences if things go wrong.
-
Hah! Actually my strategy has been to change the obviously critical ones right away (online banking, for example) and change the others as I go to use the site. A little less than best practice but that's my pattern so far.
-
Here's a great question--actually from the editor of Fastcompany.com!
-
How does a company figure out what data has been copied out of their servers? And what kinds of information could be included in those 64kb chunks, apart from the obvious credit card info?
-
Sadly, for most organizations, there will be almost no way to know (because the attack leaves no trace) unless all traffic has been recorded and there is an ability to perform historical forensics. As with most breaches (Target being a high profile example), awareness of compromise most often comes via affected users.
-
And Donnie--pretty much any data you entered online could have been game for theft, correct?
-
You can fit a lot of information into 64KB — that's enough for many thousands of characters. It's far more than enough to hold basically any piece of personal information, whether it's a credit card, social security number, or even large portions of documents. Anything that's in the memory on the computer is fair game, including IMs, emails, etc.
-
Which is worse, the undetected security bug in a small vendor's product (like say hacking into security cameras www.theregister.co.uk) or a widespread hole in a foundational technology like we're seeing with OpenSSL?
-
From my point of view, it all depends on the business and financial implications of the hole. A security hole in itself is of no value, it's about what you do with it. So if the overall results vs risk that a black hat can get over the lifecycle of a vulnerability are larger with a small unreported hole, because it exposes something in ATMs for example, it could be better for the black hat to stick with the minor, "safe" hole over the long term. Whereas with a major hole, hackers have basically one-time access to a large set of data, and they can grab a bunch and try to profit off of it, but lose access soon afterwards.
-
The problem with these foundational defects is that they linger so long in the ecosystem. The big sites will, and most have, remediated this issue but thousands of sites will almost certainly be vulnerable for years. We do a lot of work monitoring the open source ecosystem and, as an example, another vulnerable version of an encryption library (BouncyCastle) that is five years old and long since patched is still used by thousands of organizations.
-
So if I'm a business owner, and I have a website that's managed by a dozen people and companies around the globe, how do I ready myself for the next Heartbleed-style bug? Or is it just not possible?
-
One of the most important things that you can do is to keep a running inventory of the applications that you have and the components of which they are comprised (their 'bill of materials'). Having that, you will be able to much more quickly determine whether or not you are affected by a new disclosure and whether you should take any action in response.
-
Here's a FANTASTIC question from the audience, that I believe was asked entirely in one breath:
-
I know this sounds crazy but someday are we just going to wake up and everyone's private information is going to be out in the open for everyone?
-
That's an intriguing question. I could definitely envision a future where everyone's private information will be for sale, whether it's through that person directly or through the black hat who stole it and is selling it on an underground site. I don't see who would be motivated to open up everyone's private information without making a profit off of it, though.
-
In short, I doubt it (but only *doubt*). Though, I do think we need to take precautions that assume that it could happen. Apologies in advance for sounding like I'm a shill for Lifelock but I subscribe and have found it useful. I also avoid uninsured accounts and review all of my bank and credit card statements.
-
Alright, and we have one last question to take from the audience:
-
Clearly this issue has highlighted issues in how we assess and address security exploits. How do you suggest we improve diagnosis and evaluation in the future?
-
For one, I think we need to recognize that the way software is made has changed dramatically over the last few years. Modern applications are very modular, more assembled than written, and beyond keeping a record of what parts (like OpenSSL) have been used, we need to encourage developers to know the quality of the parts that they're using from the beginning. As I noted earlier, we see organizations using open source components with known, patched security defects with surprising frequency.
-
This exploit was a particularly difficult one to learn from, because it was so untraceable in action — even after the fact. One major area of improvement from my point of view was in the initial publication. It was pushed forward by 2 days, which resulted in quite a bit of confusion from vendors trying to coordinate updates. The fact that some 95% of the top 10,000 websites are secure within just a couple of days is actually quite impressive.
-
That's a great point, and it's time for us to wrap up. Thanks to you both for joining us for the chat today!
