Businesses need to inform users about Heartbleed exposure

Businesses need to inform users about Heartbleed exposure

Summary: "This one matters," says the SANS Institute, calling for 'global and immediate action' to deal with Heartbleed — including better vendor communication and better software development practices.

SHARE:
5

Poor software development practices, and vendors who fail to communicate, came under fire at a webcast briefing session on the Heartbleed OpenSSL security flaw conducted by the SANS Institute's Internet Storm Centre (ISC) Thursday morning Australian time (Wednesday evening US time).

This was the second Heartbleed briefing held by SANS in two days, and this time they announced it via a "FLASH" edition of their NewsBites email newsletter. "FLASH NewsBites are issued only when a security event demands global and immediate action. The HeartBleed Open SSL vulnerability fits that description," they wrote.

SANS ISC had earlier moved to INFOCON Yellow. This security posture indicates that they're currently tracking a significant new threat, where the impact is either unknown or expected to be minor to the infrastructure, but where local impact could be significant. Under INFOCON Yellow, users are advised to take immediate specific action to contain the impact.

"The big problem with the vulnerability isn't just that your passwords can be compromised, it's that the certificates that protect your passwords — and all of your encrypted information — can also be compromised. That's a huge, huge liability. And it turns out that if an attacker has captured traffic at some point in the past, they can now take those certificates and decrypt that traffic," Williams said.

SANS had some good news. It turns out that OpenSSL version 1.0.0 is not vulnerable to HeartBleed — which means that large enterprise networks, VPN concentrators and systems built with hardware and software on a slower development cycle is less likely to be affected that first feared.

Also good news was that while an attacker can repeatedly request 64 kilobyte chunks of server memory from their target without being detected, it appears that they tend to be the same regions of memory. "At least there's a silver lining to this very, very dark cloud," said SANS instructor and malware researcher Jake Williams, a principal consultant at CSRgroup Computer Security Consultants.

However these are precisely the regions of server memory that tend to contain critical data such as encryption keys and SSL certificates, usernames and passwords, and session identifiers — and, according to Williams, pointers to programming structures.

"This may help defeat other exploit protection, things like ASLR, address space layout randomisation, which traditionally makes some vulnerabilities not exploitable. If we have a memory disclosure bug, we can take some of these vulnerabilities that would otherwise be a one-in-a-million shot and turn them into a guaranteed shot for remote code execution," Williams said.

"Mind you, this involves leaking some of this data. Unlike leaking the private key, leaking this data is only good as long as that process is still running. When the server reboots, we're out."

One of the most important messages from the SANS briefing wasn't about the technical aspects of Heartbleed, however, but communication. Williams didn't pull any punches. "If you're not vulnerable, you need to communicate this prominently and immediately to your customers," he said.

"If you're a vendor out there and you have not published something — and I don't mean like hidden someplace on your website, like, 'We're looking into this' — if your response so far to your customers is in crickets, get off your butt. Get out of the webcast here and go communicate with your customers," he said.

Vendors — and, for that matter, service providers — need to explain why they know they're not vulnerable, such as the confirmed fact that they weren't using the vulnerable version of OpenSSL.

"If you are ever vulnerable, you need to communicate this — and, again, very prominently, not hiding it someplace where even Google can't find it. You need to communicate this to your customers and say, 'Hey, sorry, we were vulnerable'," Williams said.

"This isn't a black eye, right? Everybody was vulnerable. It's not like you screwed up in your code, you used best practices, you just happened to use a library that everybody thought was secure, and it was a little bit less than secure."

ZDNet sought comment from Australia's biggest banks, as the most likely targets of people who may look to exploit Heartbleed as a means to obtain private banking details, and the results were mixed.

A spokesperson for the Commonwealth Bank admitted that the bank had patched its server, but said that the Netbank server, where customers view their bank accounts and transfer money, had not been affected.

"CBA customers can rest assured that the Bank is patched against the Heartbleed bug. Customers do not need to change their passwords. They can continue to bank with confidence in NetBank and our other channels," the spokesperson said.

Westpac would only say its online banking service wasn't susceptible to the security hole, while the National Australia Bank (NAB) was more specific about what security measures it uses.

"NAB does use SSL to protect its transactional data and customer information. This particular exposure does not impact NAB or its customers, due to the Enterprise architecture we have in place to protect our systems," the spokesperson said.

"NAB has multiple layers of technology and protection and we never allow a single layer of vulnerability to expose our services and customers. Our customers do not need to change their Internet Banking passwords as a result of the Heartbleed vulnerability."

ANZ Bank said its internet banking and goMoney mobile app were not impacted by the OpenSSL vulnerability, and customers did not need to change their passwords.

"While customers do not need to change their Internet Banking passwords as result of Heartbleed, we do recommend they regularly update passwords and keep them secure."

While the internet is scrambling to patch and inform users of their exposure today, SANS Institute's Williams was scathing of the OpenSSL development process. In the Institute's training on exploit writing, he says, "We talk about never ever ever ever — ever — trusting user-supplied input. But the folks at OpenSSL, they said, 'Hey, rock on, man. We can do this'."

Even the timelines for code development were less that ideal.

"People are going to laugh at this, but it is not a joke," William said. The buggy OpenSSL code was committed a "very short time" before midnight on 31 December 2011. "The guess at this point is that someone who may have been having a little too much to drink said 'Hey, good to go, commit the code', and we've been living with it for the last two years. The code didn't go operational, as it were, published into a build, until March 2012."

Overall, though, the message from the SANS Institute remains the same. For most services you connect to over the open internet — or over any untrusted network, such as hotel Wi-Fi — and which you thought were secure, you should change your password as soon as the service provider has confirmed that any vulnerability to Heartbleed has been fixed.

You should also work with your business partners to ensure that their vulnerable servers have been patched, and that new SSL encryption keys are generated and certificates re-issued, otherwise you're no more secure.

Topics: Security, Banking, Australia

About

Stilgherrian is a freelance journalist, commentator and podcaster interested in big-picture internet issues, especially security, cybercrime and hoovering up bulldust.

He studied computing science and linguistics before a wide-ranging media career and a stint at running an IT business. He can write iptables firewall rules, set a rabbit trap, clear a jam in an IBM model 026 card punch and mix a mean whiskey sour.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

5 comments
Log in or register to join the discussion
  • what other "layers of technology and protection"?

    Good article, thanks! The statements from the banks that were affected are mostly vague. I'm curious why they think, if they needed the patch, their other "layers of technology and protection" protected users passwords? Is that a legitimate stance? Also I would be interested if the banks (or other entities) that were vulnerable have also changed their SSL certificates?
    impala_sc
    • Other layers of protection ...

      Other layers of protection would include at least one that would protect against this bug. That would to be use ONLY enterprise versions of software. And enterprise version of OpenSSL would not be affected because enterprise versions typically require code to be at least three to five years old, in other words field tested and proven for at least that amount of time simply to preclude these sorts of bugs. That would translate to SuSE Linux Enterprise Server, Red Hat Enterprise Linux or Oracle Unbreakable Linux and other enterprise server distros. These are the typical operating systems that would be used by the larger Linux shops out there. Thus only shops using more bleeding edge consumer oriented offerings would likely be affected by this problem.
      George Mitchell
      • All well and good, but...

        That is why I prefaced that question with "if they needed the patch". Also, apparently RHEL6.5 is affected.
        impala_sc
        • Apparently there are other factors as well ...

          According to some vendors, there systems are not vulnerable "because of the way OpenSSL is called". That would seem to indicate that there are environmental variables or some other such thing that would prevent this problem. Others have indicated that they already employ exotic external network firewall equipment that is able to identify queries that are malicious. I would assume that most high profile sites are well protected by multiple strategies. I suspect it will be the secondary tier of sites that will have the problems. At this point I certainly see no evidence of security breeches, but I'm sure that along the way there will be those that fail to apply the patch in a timely manner and get bitten as a result. I certainly don't think it is the end of the world. Perhaps in the long run a scare like this will even increase security. One can only hope.
          George Mitchell
  • Agree

    Yes, I definitely agree here. That is why Sticky Password (my password manager of choice) have said publicly about the breach on their blog: http://blogen.stickypassword.com/sticky-password-and-the-heartbleed-bug/
    JohnSavory