How Companies Are Reacting to the Heartbleed Security Bug
Milagli / Shutterstock
The revelation earlier this week of Heartbleed, a serious and scary security vulnerability affecting as many as two-thirds of the world’s Web servers, has left companies scrambling to assess their systems and consumers wondering what they can do to avoid having their information compromised.
The short answer is not much except to wait for sites affected to get their systems patched and then change all your passwords. But that’s not quite the whole story.
You can check whether a site you use regularly, say your banking or credit card site, is affected. This tool from the security company Qualys lets you check if a site has been patched before you use it and avoid sites that fail until they get their systems patched. At least Twitter and Facebook were safe.
Meanwhile, companies that were affected began to notify their users. One example that popped into my inbox came from IFTTT, the Web automation service. In an email to its users, the company announced that it had patched its systems, but also taken the additional steps of logging all of its users out
“Though we have no evidence of malicious behavior, we’ve taken the extra precaution of logging you out of IFTTT on the Web and mobile. We encourage you to change your password not only on IFTTT, but everywhere, as many of the services you love were affected,” the email said.
A similar message was sent out to users of Wunderlist, the free to-do list tool. “As soon as we were made aware of Heartbleed, we protected your data by preemptively turning off our Sync Service, eliminating any potential security breaches by stopping all communication to our servers,” the message said. After that, the company updated its OpenSSL software, renewed its SSL certificates, and then logged out all users to make sure that all customers were reconnected via secure connections.
That appeared to be the standard response to the the bug: Patch the system, force users to reconnect and urge them to change passwords.
The problem now is what Donald Rumsfeld might have called a “known unknown” — that is, it’s impossible to know if a system was ever attacked using this vulnerability in the two years and change that it has existed. But at least you know you don’t know.
The best thing to do is assume that systems that were vulnerable were attacked, said Tatu Ylönen, inventor of the SSH (secure shell) protocol and CEO and founder of SSH Communications Security. “Any passwords transmitted under SSL encryption may have been compromised and obtained by anyone who can record traffic to the site,” including spy outfits like the National Security Agency, he said. Attackers who knew about the vulnerability may have used private keys obtained via the vulnerability to read old data.
Then there’s the issue of third-party software, he said. Vendors will have to push out new versions for customers to install and then generate new encryption keys and certificates. “Thousands of enterprise applications have been compromised, including business applications, financial applications, payment applications, banking applications, and security applications,” he said. “The cost of remediating the issue is substantial, amounting to hundreds or thousands of dollars per server or application, including new certificates and labor. The total labor and certificate renewal cost worldwide resulting from this bug could exceed a billion dollars.”
And even when all that work is done, there’s still no way to tell what data may have been taken or if someone has ever attacked your systems, said Nathaniel Couper-Noles, principal security consultant at Neohapsis, a security firm. “The best short term fix — patching or upgrading the software — may prevent future breaches, but the horse may already be out of the barn if passwords or SSL keys were compromised before the patch was in place. It may take a considerable amount of effort and money to re-establish a nominal security level.”