Link

Cyber-security in 2014: What we learned from the Heartbleed bug

Cyber-security in 2014: What we learned from the Heartbleed bug:

Parsons warned that the fallout from Heartbleed may not be over for web users.

We still don’t know just how much information was stolen or accessed as a result of the bug. Stolen login credentials and user information is likely to be leaked by hackers, putting users at risk for additional hacks.

The problem is hackers could leak this information at any time.

“If logins and passwords were successfully extracted – and I’m willing to say 99.9 per cent of people haven’t changed all of their passwords – people still could be affected,” he said.

“Always expect at some point, possibly through no fault of your own, you will be compromised,” Parsons warned.

“Then think, ‘What would I do if my personal information was leaked?’ Thinking before these things happen can help you come up with a recovery strategy.”

 

Link

Four weeks on, huge swaths of the Internet remain vulnerable to Heartbleed

Four weeks on, huge swaths of the Internet remain vulnerable to Heartbleed:

With the media off (most) companies’ backs there’s just no way/reason that these remaining companies are going to patch the heartbleed vulnerability. One can only hope that civil suits are launched against these remaining companies to show via the market that patching is a requirement for contemporary digitally-enabled businesses.

Testing for “reverse” Heartbleed

Testing for “reverse” Heartbleed:

Importantly, even if the server that you are querying (e.g. Tumblr.com) is patched against this OpenSSL vulnerability the servers behind the front-end of the server may not be. As a result, payment gateways, agents responsible for fetching URLs, some identity federation protocols, and so forth may also be vulnerable. In Meldium’s tests, who have they announced was vulnerable?

  • An unnamed top 5 social network (we’re waiting for confirmation of their fix) that fetched our URL to generate a preview. The memory we extracted from their agent included results from internal API calls and snippets of python source code.
  • Reddit, which can use a URL to suggest a name for a new post, used a vulnerable agent that they’ve now patched. The memory we were able to extract from this agent was less sensitive, but we didn’t get as many samples because they patched so quickly (nice work!).
  • We registered a webhook to our malicious URL at rubygems.org to notify us whenever a gem was published. Within a few minutes, we captured chunks of S3 API calls that the Rubygems servers were making. After the disclosure, they quickly updated OpenSSL and are now protected (really nice work, especially from an all-volunteer staff!).

This is just a very, very small snippet of vulnerable parties. And given how many backend systems will simply not be updated for fear of breaking compatibility (e.g. in the case of payment gateways) this will be a long-term vulnerability.

SSL: the solution to a problem that is persistently generating problems unsolvable by SSL itself.

Aside

How Heartbleed transformed HTTPS security into the stuff of absurdist theater

I think the link between absurdist theatre and SSL certificate revocation checking is a (bit) tenuous, but nevertheless Dan Goodin’s article over at Ars Technica does a good job in describing (in less technical language than Adam Langley’s post) why having your browser check for revoked SSL certificates really isn’t all that effective.

Link

Heartbleed Internet Security Flaw Used in Attack

It’s a statement from Mandiant and so some mindfulness should be taken when reading their comments. (The same is true when parsing statements from other for-profit security companies.) Still, that Heartbleed is not only weaponized (that happened almost immediately after it was integrated into Metasploit) but is showing up in the wild prominently enough to warrant a response from Mandiant demonstrates why Heartbleed is going to be a problem for years going forward. For a good, if technical, discussion of why the hurt is just going to continue (like all things that involve breaking SSL…) see Adam Langley’s recent post titled “No, Don’t Enable Revocation Checking.”

Also: even if you don’t read Adam’s post you can follow the lesson he provides in the title of his technical post. If in the aftermath of the Heartbleed vulnerability you enabled Revocation Checking in Chrome then disable it, ASAP.

Source: Heartbleed Internet Security Flaw Used in Attack

Link

Heartbleed may lead to more security audits, advanced security services

Missed this when it went up, but posting because I think it touches on something that is important to track as things move forward: despite experts inside and outside of industry recognizing the need for more audits of critical packages like OpenSSL, will resources actually be devoted to enable such work?

Source: Heartbleed may lead to more security audits, advanced security services

Link

Heartbleed bug shows governments slow to react

Source: Heartbleed bug shows governments slow to react

Link

Heartbleed Ripped a Hole in the Internet | VICE Canada

First time that I’ve been quoted (extensively) in Vice!

Source: Heartbleed Ripped a Hole in the Internet | VICE Canada